Pic PWM Toy

[HeyTom]

I was looking at using PWM for low speed digital to analog conversion.
Since real life is usually a little different than what the math says, I wanted to make a test circuit.

I don't have a function generator, but I do have a pic16f88 and an lcd.



Pressing the rotary encoder switches from period to duty cycle.  Pressing the other button cycles through pic clock speed (0.5 Mhz,  1Mhz, 2Mhz, 4Mhz, 8Mhz)  This will give you from about 30Hz to maybe 2mhz.
I tested the low end by driving a servo, and I tested in the 10-20Khz range for DAC. 

The LCD is pretty slow, I'd like to speed up the responsiveness.  Here's the code and schematic:

[dannyf]

I would encourage you to change the pwm - related code into a few pieces, like enablying the module, enabling output, setting frequency and duty cycle: so the code can be easily reused for future projects.

[Rufus]

The LCD is pretty slow, I'd like to speed up the responsiveness.  Here's the code and schematic:

I wrote a 'frame buffered' driver for HD44780 type LCDs with 4 bit interface. A processing function (preferably called from a timer interrupt) continually writes the frame buffer to the LCD. On a PIC18 refreshing a 16x2 LCD at 15Hz takes about 0.03 MIPS. You can change the frame buffer contents as fast as you are able, the LCD gets updated about as fast as the glass can respond. Downside is there is no support for a visible cursor.

[HeyTom]

Rufus, I'm curious:

1) How long do you wait between each nibble? 

2) Do you bother with the busy flag?

I'd really like to see your frame buffer code.

[dannyf]

I am not sure if using a timer to trigger a write to the lcd is a great solution. Those lcds are fairly slow: I would estimate that it takes 5 - 10 instructions to write a byte. x 32 bytes = 200 - 300 instructions, or 200 - 300us on a 1MIPS mcu.

That's a lot of time.

As to implementation, you can construct a display buffer (say 16x2), updated in the main by your code. In the timer isr, you write that buffer to the two lines as you would in a regular display module.

[Rufus]

Rufus, I'm curious:

1) How long do you wait between each nibble? 

2) Do you bother with the busy flag?

I'd really like to see your frame buffer code.

It writes one nibble per call to the processing function and requires you to call it slower than about every 50us to allow the LCD to complete its processing. It doesn't read the LCD at all. The R/nW line can be tied low.

I attach the code. It was last built for a PIC24 and XC16. You will have to change the delay macros to suit XC8 and the LCD pin macros. Not sure if PICs without LAT registers will have RMW issues. I suggest calling the process function from a timer interrupt at about 1kHz, or integrate it in the interrupt code.

If you do implement it on an PIC16 flip a pin at the start and end of the processing function so you can scope the run time. I would be interested in the results. I think on a PIC18 running at 10MIPS with XC8 pro the average run time was 2.3uS (with the LCD_DATA_LAT optimization).

[HeyTom]

I'll see if I can give it shot this week.  I checked what I have and I can see I need to adjust the variable I use for different oscillator speeds, because the numbers below should really all be the same.
These are times for one line update. 

1Mhz:  154 ms
2Mhz:  136 ms
4Mhz:  123 ms
8Mhz:  118 ms

They are good enough for now, but I think I can lower the times -- gotta re-check the datasheet.

[Rufus]

These are times for one line update. 

1Mhz:  154 ms
2Mhz:  136 ms
4Mhz:  123 ms
8Mhz:  118 ms

I take it that means you got it running on the PIC16.

Don't really understand what line update time means. Calling the driver process function at a fixed rate will consume a percentage of available processor power. Calling at 1kHz on a PIC18 at 10MIPS it was about 0.23%. I am interested in how much worse it is on a PIC16 and it obviously scales with the processor clock speed.