I've restarted the discussion from http://www.rev-ed.co.uk/picaxe/forum/topic.asp?topic_id=2480 here as I'm sure it will be topical and better not left to add to an archive.
I'd proposed to do some command timing measurements, and hadn't realised BeanieBots had done the same already ...
http://www.rev-ed.co.uk/picaxe/forum/Topic.asp?topic_id=1157
Rather than two 28X's, I am using an 08(4.3) to bechmark and measuring with an 18X(8.5) using PULSIN and an LCD to show min, max and average for the same instruction run ten times on the 08.
The basic program ...
- LOW 1
- MainLoop:
- TOGGLE 1 ' Pin 1 goes high, start timing
- TOGGLE 1 ' Pin 1 goes low, stop timing
- PAUSE 10
- GOTO MainLoop
Gives a 220uS timing for a high pulse. Dropping ten commands between the toggle, subtracting 220uS and dividing by 10 gives the command time, taking out the variations caused by token positioning.
A control test of 'PAUSE 10' gives 9.7mS, so that's 3% out from perfect which is probably the oscillator tolerances of the 08 and 18X combined ( all tests done at 20'C, 5V ). 'PAUSE 20' gives 19.2mS, 4% error.
Oddly though, all my other timings are coming out about half of what BeanieBots obtained earlier using two 28X's. I'm not making any accusations because tehre are reasons why there could be this discrepency, but it is intriguing. I can't find anything which has my programs running at twice the speed they ought to be ( the 08 can't and I explicitly use 'SETFREQ M4'/'CALIBFREQ 0' on teh 18X every loop ). My figures also seem to be broadly in line with what Joerg found.
Some interesting findings anyway ( the measurements could be 10% out )...
HIGH 0 ' 230uS
LOW 0 ' 226uS
TOGGLE 0 ' 227uS
HIGH 4 ' 255uS
LOW 4 ' 254uS
TOGGLE 4 ' 254uS
The inceased speed of using pins 0 and 1 ( due to token size differences ) can be clearly seen, and token-sizing effects can also when it comes to variable assignment ...
b0=0 ' 329uS
b0=2 ' 355uS
b0=16 ' 397uS
b0=$FFFF ' 480uS
The 'cost' of mathematical operations is quite interesting ...
b0=0+0 ' 629uS ( the +0 adds 300uS )
b0=0-0 ' 616uS ( the -0 adds 287uS )
b0=0*1 ' 777uS
b0=$FFFF*$FFFF ' 1156uS
That really highlights how hard it is to predict timing because it's affected greatly by what numbers are being used, however ...
w0=w0*w0 ' with w0=0, 645uS
w0=w0*w0 ' with w0=$FFFF, 650uS
which would indicate that there's little optimisation done in handling the multiplication in firmware.
Other timings so far ...
GOTO label ' 266uS
GOSUB label ' 330uS
RETURN ' 510uS
These will be affected by which PICAXE is used - memory size, 16/256 GOSUB's.
Timing a 'HIGH 0' on an 08(4.3), 18(2.1) and 18X(8.5) all gave comparable readings. I don't have any 28X hardware wired up to compare with, but it could be that the PICAXE runs about twice as fast as we previously thought it did.
I'd proposed to do some command timing measurements, and hadn't realised BeanieBots had done the same already ...
http://www.rev-ed.co.uk/picaxe/forum/Topic.asp?topic_id=1157
Rather than two 28X's, I am using an 08(4.3) to bechmark and measuring with an 18X(8.5) using PULSIN and an LCD to show min, max and average for the same instruction run ten times on the 08.
The basic program ...
- LOW 1
- MainLoop:
- TOGGLE 1 ' Pin 1 goes high, start timing
- TOGGLE 1 ' Pin 1 goes low, stop timing
- PAUSE 10
- GOTO MainLoop
Gives a 220uS timing for a high pulse. Dropping ten commands between the toggle, subtracting 220uS and dividing by 10 gives the command time, taking out the variations caused by token positioning.
A control test of 'PAUSE 10' gives 9.7mS, so that's 3% out from perfect which is probably the oscillator tolerances of the 08 and 18X combined ( all tests done at 20'C, 5V ). 'PAUSE 20' gives 19.2mS, 4% error.
Oddly though, all my other timings are coming out about half of what BeanieBots obtained earlier using two 28X's. I'm not making any accusations because tehre are reasons why there could be this discrepency, but it is intriguing. I can't find anything which has my programs running at twice the speed they ought to be ( the 08 can't and I explicitly use 'SETFREQ M4'/'CALIBFREQ 0' on teh 18X every loop ). My figures also seem to be broadly in line with what Joerg found.
Some interesting findings anyway ( the measurements could be 10% out )...
HIGH 0 ' 230uS
LOW 0 ' 226uS
TOGGLE 0 ' 227uS
HIGH 4 ' 255uS
LOW 4 ' 254uS
TOGGLE 4 ' 254uS
The inceased speed of using pins 0 and 1 ( due to token size differences ) can be clearly seen, and token-sizing effects can also when it comes to variable assignment ...
b0=0 ' 329uS
b0=2 ' 355uS
b0=16 ' 397uS
b0=$FFFF ' 480uS
The 'cost' of mathematical operations is quite interesting ...
b0=0+0 ' 629uS ( the +0 adds 300uS )
b0=0-0 ' 616uS ( the -0 adds 287uS )
b0=0*1 ' 777uS
b0=$FFFF*$FFFF ' 1156uS
That really highlights how hard it is to predict timing because it's affected greatly by what numbers are being used, however ...
w0=w0*w0 ' with w0=0, 645uS
w0=w0*w0 ' with w0=$FFFF, 650uS
which would indicate that there's little optimisation done in handling the multiplication in firmware.
Other timings so far ...
GOTO label ' 266uS
GOSUB label ' 330uS
RETURN ' 510uS
These will be affected by which PICAXE is used - memory size, 16/256 GOSUB's.
Timing a 'HIGH 0' on an 08(4.3), 18(2.1) and 18X(8.5) all gave comparable readings. I don't have any 28X hardware wired up to compare with, but it could be that the PICAXE runs about twice as fast as we previously thought it did.