Timing Error with 12F629

[Dick Ivers]

I am trying to create a continuous pwm waveform by setting an output pin high then low for specific time periods. Yes, I know there is a PIC12F683 that would do this for me using onboard hardware pwm. However, my p.c. boards are designed for the 12F629 which is absent this feature.

I want a 5000 hz pwm frequency, and to run for 40 seconds. This should equate to 200,000 cycles. My code is designed to count this many cycles and then stop. However, when testing the actual hardware the run time is about 93 seconds. This is an huge error so something is seriously wrong.

I will post the code when I figure out how to do that (It's very short). In the meantime looking for troubleshooting ideas.

[Dick Ivers]

Code as follows:

i var byte
time var byte
counter var word

time = 40 '(40 second run time)

for i = 1 to 10
counter = 0
while counter < time*500 '(40*500*10 = 200,000)
GPIO.4 = 1 '(75% duty cyle)
pauseus 150 '(pwm = 5000 hz (.000200 sec. period))
GPIO.4 = 0
pauseus 50
counter = counter+1
wend
next

[Archilochus]

HI Dick,
Have you checked the oscillator DEFINES, etc?

Arch

[Dick Ivers]

Hi Arch,

I forgot to mention that the 12F629 is running with the internal 4 mhz oscillator. Set by configuration: @device intrc_osc_noclkout.

Dick

[Bruce]

Hi Dick,

94 seconds is about right. If you run this through MPLAB with a breakpoint
set on NEXT, you'll see it takes 9.4 seconds total just to reach NEXT.

Run through 10-times, and you end up with around 94 seconds to complete
your 10 pass loop.

You're forgetting to add-in the over-head for PBP commands.

for i = 1 to 10
counter = 0
while counter < time*500 '(40*500*10 = 200,000)
GPIO.4 = 1 '(75% duty cyle) 
pauseus 150 '(pwm = 5000 hz (.000200 sec. period))
GPIO.4 = 0
pauseus 50
counter = counter+1
wend
next ' <-- Takes 9.4 seconds to get here the first time

Try it with these changes for around 40.0366 S.

Time = 29
while counter < time*493

[Dick Ivers]

Dear Bruce,

Thanks for your response and your astute trouble-shoot of the problem. The suggested fix does work.

I had a suspicion that code execution time was the culprit, but had no way of checking for the overhead time. I am surprised that it adds to so much error. I gotta get some tools to do that kind of debugging. Isn't MPLAB an assembly language code development suite?

Thanks,

Dick