Scope Giving Odd Results Reading PauseuS

CDRIVE

Senior Member
I was testing my new (renewed) VSM on M2 parts but I'm getting very odd results with this basic code. The Scope indicates high sate = 200uS and low state = 300uS. I doubt that the picaxe is at fault. As you can see the frequency 50KHz (1/T) and the duty cycle which should be 50% are grossly in error. Are there any reported bugs with the Scope or the PauseuS command.

Code:
' Chipset: Picaxe 08M2
' Project: PauseuS Accuracy Test

Start:

    High b.2      
    Pauseus 1     ' keep pin High for 10uS
    Low b.2         
    Pauseus 1     ' keep pin Low for 10uS
    
GoTo Start
 

CDRIVE

Senior Member
Please see

http://www.picaxe.com/BASIC-Commands/Time-Delays/pauseus/

high, pauseus = 2 commands = 2 command overheads
low, pauseus, goto = 3 commands = 3 command overheads
This is a quote from your link..
Pause for some time.

The duration of the pause is as accurate as the resonator time-base, and presumes a 4MHz resonator (8MHz on X2 parts). The pauseus command creates a time delay (in multiples of 10 microseconds at 4MHz). As it takes a discrete amount of time to execute the command, small time delays may be inaccurate due to this 'overhead processing' time. This inaccuracy decreases as the delay gets longer.
I took the term "may be inaccurate" to mean +- 10 to 20 uS not hundreds of uS.

I'm curious why the VSM Scope wouldn't suffer from the same overhead and even greater multitasking - multi-threading issues that the Picaxe does. After all Picaxe VSM is running under Windows which is always doing other stuff. Are you saying that if I run this on a physical 08M2 and measure with one of my real scopes I'll get the same results?

Thanks,
Chris
 
Last edited:

Technical

Technical Support
Staff member
Are you saying that if I run this on a physical 08M2 and measure with one of my real scopes I'll get the same results?
Yes, you won't get a 50% duty rate on a real chip either (as you seem to expect from the original post). Try it and see. The pauseus itself is accurate, but you also have to account for each command overhead processing time in the loop as well.

VSM approximates the command overhead and so won't be exactly the same as the real chip, but a real chip will not give 50% duty either because you have a 2-3 command ratio and the time delay in this example is tiny (so the command overhead is much more significant).

Obviously this only matters at tiny time delays (in proportion relative to the overhead), repeat the experiment at say 100ms as opposed to 10us and the command overhead then becomes insignificant in relation to to the delay.
 

CDRIVE

Senior Member
Yes, you won't get a 50% duty rate on a real chip either (as you seem to expect from the original post). Try it and see. The pauseus itself is accurate, but you also have to account for each command overhead processing time in the loop as well.

VSM approximates the command overhead and so won't be exactly the same as the real chip, but a real chip will not give 50% duty either because you have a 2-3 command ratio and the time delay in this example is tiny (so the command overhead is much more significant).

Obviously this only matters at tiny time delays (in proportion relative to the overhead), repeat the experiment at say 100ms as opposed to 10us and the command overhead then becomes insignificant in relation to to the delay.
All very informative but it really begs the question: What use is PauseuS if not for uS delays? After all if I'm forced to work with mS I might as well use the "Pause" command.

Cheers,
Chris
 

Technical

Technical Support
Staff member
To create delays shorter than 1ms. There is a big difference between 10us and 1ms. e.g. for a 500us delay you may need to make a slight adjustment for the command processing (by using a smaller number that the expected 50 in the pauseus command) but you can still do it, something that would not be possible with pause itself.
 

CDRIVE

Senior Member
Yes, I can see it's use in that instance but find it unusable for delays less than hundreds of uS. After all I removed the two instances of PauseuS from my .bas file and I get..
t high=100uS
t low= 200uS.

Cheers,
Chris
 

hippy

Senior Member
What you are seeing are the approximated command overheads due to the PICAXE being an interpreter. You can reduce those times by running the chip at a higher frequency but there will always be some overhead which limits the maximum frequency that bit-bashing output pins can generate.
 

CDRIVE

Senior Member
Yes, after my last test the Picaxe Basic plus the bootloader overhead was really obvious to see. I guess for really fast requirements it's hard to beat a blank PIC and ASM code.

Thanks to both of you for the help.

Chris
 

66661

New Member
Hello to all for first time, I am just learning about picaxe.

My interest in picaxe is trying to use them for a pulse generator for a PI metal detector
which requires pulses of 100uS and 25-50uS.

I just tried the above example with a real 08m2 chip and a real CRO, the code was supposed to be on for 100uS and off for 100uS @ default 4MHZ chip clock
and the pulses I got were ON for almost 400 uS and OFF for almost 700 uS, which is no where near 100uS, I understand there is some delay
for command overheads, but I did not expect this much extra time.

Should I run the chip @ 32MHZ to get a more accurate 100 uS pulse timing.
Any comments appreciated so I can learn.

Here is my code



' Chipset: Picaxe 08M2
' Project: PauseuS Accuracy Test

main:

High c.2 ;pin 5
Pauseus 10 ' 10 x 10 uS=keep pin High for 100uS
Low c.2
Pauseus 10 ' 10 x 10 uS keep pin Low for 100uS

GoTo main
 

hippy

Senior Member
Should I run the chip @ 32MHZ to get a more accurate 100 uS pulse timing.
Welcome to the PICAXE Forum.

Running at 32MHz ( 64MHz where available ) will reduce the interpreter overhead which will allow more leeway in adjusting PAUSEUS times to achieve the desired results.

A better solution than HIGH-PAUSE-LOW-PAUSE-GOTO can be TOGGLE-PAUSE-GOTO as that only requires one timing adjustment while keeping high and low periods the same.

PWMOUT will offer a better alternative to bit-banged toggling or pulsing in cases where the desired PWM frequency can be generated.
 

66661

New Member
Hi Hippy, thank you for the welcome and the reply

Thanks for the info on the toggle command and I will up the clock speed to 32mhz and retest.

For the toggle code on a 08m2 something like this ?

main:
toggle c.2 ; toggle chip leg 5
Pauseus 10 ; wait 100 uS
goto main ; loop back to start of code and repeat
 
Top