Timing measurements

[Odessa]

This thread is for informational purposes only.....

Some time ago I had inquired here regarding execution times for simple commands like 'High 0' or 'Low 0' and seem to remember having been told that these commands take approx. 1 mSec to execute on an 08M.

I did some measuring this evening on an 08M at 4 MHz and obtained the following very consistent results at room temp (about 90F in my office right now):

~250 uSec going from high to low & vice-versa on Out 0;
~ 550 uSec for ADC 8-bit conversions, regardless of channel

This timing remained the same with supply voltage at 5V or 3V, and applying a soldering iron to the top of the plastic package (surprisingly) did not noticeably affect the timing.

I will probably test 10-bit conversions also, in case anyone is interested I could post the results here. And, while I have the test setup, if anyone is interested in any other rudimentary timing measurements, I could also run those; if so, let me know in this thread....

Odessa.

 

[BeanieBots]

Not sure where you got 1mS from but ~250uS @ 4MHz has been the accepted 'general' figure for several years.
You should also notice that timing is also affected by code location.

You've not stated how you have timed the commands, but assuming you have a loop of some kind, try putting a pause statement (or any other command) before and outside the loop. It WILL affect the timing.

Temperature and voltage WILL affect timing but only when running with an internal oscillator. The amount of affect will vary between individual PICAXEs.

One test I've never seen done is the effect of interrupts and background tasks. Try doing doing some tests with and without interrupts enabled. Also try it with servo commands running and with/without background tasks enabled.

 

[westaust55]

Timing measurements - AGAIN !

In one of your past threads, Beaniebots in Nov 2008 gave you (and OCM770) a typical timing of 250us per instruction. See:
http://www.picaxeforum.co.uk/showthread.php?p=83288
which you reiterated in post 9 of the same thread.

Beaniebots also did a lot more timings for various comamnds aeons ago.
See post 3 at:
http://www.picaxeforum.co.uk/showthread.php?t=1128&highlight=timing

 

[Odessa]

Beanibots, I will run a few tests using interrupts and background tasks and post the results here, although, I am not using two Picaxes with the PulseIn command, since I am only looking for rough approximations now. I will post visually measured scope data.

Westaust, YES, you are correct! 250 uSec was mentioned and I confirmed that; not sure why I had 1 mSec in mind.....Thanks.

Odessa.

 

[hippy]

Have a read through the previous posts on instruction timings so you aren't simply wasting your time repeating what others have already done ( though there's no reason not to do it for your own inquisitiveness or confirmation ). Pay attention to the issue of code placement and how the test program itself can affect the readings if you want to get anywhere near representative values.

 

[Odessa]

Here are some additional, mostly surprising conclusions from brief tests on the 08M @ 4 MHz & Vsupply = 5V; room temp ~= 90F:

* 8 & 10 bit conversions take the same amount of time, ~ 550 uSec.

* Running PWMout in the background on channel 2 has no effect whatsoever on timing.

* Even having an interrupt enabled does not change the timing at all. This seems to indicate that the code which checks for an interrupt at the beginning of most instruction cycles runs whether an interrupt exists in the code or not, or whether it is set or not; it only effects the interrupt if a) one exists; b) it is set; and c) the interrupt conditions exist.

Code used to obtain the above data is below. The first part is used to measure between low to high transitions & vice-versa; the second part introduces A/D conversions in between those transitions. Timing of the transitions in the second part is checked against the different variables in the test. PWMOut & SetInt can be selectively commented out when desired.

Odessa
_______________________________

Dirs=%00011011 'Set inputs & outputs
PWMOut 2,99,200
SetInt %00000100,%00000100

Start:

#Rem
For b13=1 to 20 '~250 uSec high and low pulses; 5 each
High 0
Low 0
High 0
Low 0
High 0
Low 0
High 0
Low 0
High 0
Low 0
Next b13 '~1.15 mSec between bursts of 5
#EndRem


For b13=1 to 20 '~800 uSec high and low pulses; 5 each
High 0
ReadADC10 1,b13
Low 0
ReadADC 2,b13
High 0
ReadADC 4,b13
Low 0
ReadADC10 1,b13
High 0
ReadADC 2,b13
Low 0
ReadADC 4,b13
High 0
ReadADC10 1,b13
Low 0
ReadADC 2,b13
High 0
ReadADC 4,b13
Low 0
Next b13 '~1.7 mSec between bursts of 5
'#EndRem

Goto Start

Interrupt:
Return

 

[BeanieBots]

Interesting finds indeed. Thanks for sharing.
I too found that ADC resolution had no effect.
Similarly for the DS18B20 but I beleive newer firmware is more intelligent and polls for end of conversion so time will vary significantly with actual reading. Something to try out later.

 

[hippy]

If you look at the PICmicro datasheets the ADC is a '16-bit' result ( with the result in two possible formats ). Conversion time is the same regardlesss, and loading a variable with an 8-bit or 10-bit result is likely to take the same time in either case.

Differences in timing, if there are any, are likely to be in the order of microseconds and those won't be detected unless using a PULSIN on a PICAXE running far faster than its normal 4MHz which gives a PULSIN resolution of 10us.

If attempting to measure to the microsecond, oscillator accuracy comes in to play. That being measured may be running slow, that measuring running fast; 2% error on each side is 4% error in total.

 

[Odessa]

"Not sure where you got 1mS from but ~250uS @ 4MHz has been the accepted 'general' figure for several years"

Hi BeaniBots, re-reading part of the user manuals, HERE is where I got it, from page 99 of Manual 1 (V6.8):

The PICAXE-08/18/18A/18M/18X microcontrollers have an internal 4MHz
resonator, and the PICAXE-28/40 family use an external 4MHz ceramic resonator.
This means the microcontroller processes 1 million assembler commands a
second, which equates to roughly about 1000 BASIC commands per second.

 

[hippy]

That's a fair point

The manual gives a rough idea as to what the performance of any arbitrary program will be which will usually include simple and complicated commands, some which take longer than others.

Simplest commands, "HIGH 0", have an approximate timing of 250us at 4MHz and that's become the defacto 'base unit of measurement' for most timing experiments. We could claim programs therefore execute about 4,000 commands per second but most programmers won't see such performance.

A common benchmark for Basic interpreters is something like ...

Do
Toggle 0
Loop

Then measure the frequency or pulse time, determine speed from that. Again that gives a more maximal result than is usually achieved in practice in an arbitrary, practical program.

When promoting any chip with benchmarks it's tempting to choose the best figure available - and not unheard of for some to tweak their implementations so the same benchmark runs faster on their system rather than others - but we've chosen a general average which we believe reflects a better reality.

 

[Odessa]

Hi Hippy:

I have found in practice that approximating the timing of a lengthy string of commands (I have never used 'Sound', or 'Serin', those that are claimed to use more memory) can be done fairly well by taking the # of commands and multiplying by that 250 uSec period for a simple toggle, and by 1.5X (i.e. ~ approx average of 375 uSec/command line).

Although there are some commands I have not used, my programs are fairly complex and push the limits of the 256 byte availability of the smaller devices. Many of my projects so far have required fairly accurate timing over several hours, up to 24 or so.

 

[hippy]

Your x 1.5 is probably a good guide. If one breaks every Basic statement into component parts you get ...

<command> <data> <data> .... <data>

"HIGH 0" is two parts, so 125us per part. "LET b0 = b0 + 1" is six parts ...

<LET> <b0> <=> <b0> <+> <1>

So a reasonable guestimate would be 6 x 125us = 750us. I don't know how well that matches reality off-hand but you can see it approaching 1000us, 1ms or 1000 commands a second. This is all rule of thumb guesstimation though so good for making a general prediction but not necessarily making accurate predictions.