Processing time

Harry_Worth

New Member
Hi all,
Just a thought - do all processes take the same time ie would:
A/ ValueA = ValueB then main
be slower than
B/ Goto Main
Or would they both take the same time or be quicker?
 

inglewoodpete

Senior Member
Due to the way PICAXE source code is 'tokenised', it is difficult to determine when code will run faster or slower. Generally, you can expect a decision (like If ValueA = ValueB Then ...) to take longer than simply Goto Main.

Code that is downloaded into a PICAXE chip is not compiled like may other microcontroller systems. The PICAXE has a permanent 'operating system' in its flash memory that interprets tokenised code that is downloaded into the chip. These code 'tokens' are either 5-bits wide (M2 chips) or 6-bits wide (X2 chips). When your PICAXE code is 'run', the firmware extracts each token and performs the task that is required. Since the tokens are stored in 8-bit bytes, extracting each one will result in a range of different times to execute it, depending on were the token is actually stored on a particular download. The result is very compact storage of code but slower and potentially variable execution speed.
 

AllyCat

Senior Member
Hi,

The "Base PIC" microcontroller typically executes "Machine Code" (or Assembler) Instruction Cycles at a rate of 1 per microsecond each (with a 4 MHz clock). Nearly all of these base instructions take a single Instruction Cycle, except when a "jump" (GOTO) is involved, which takes 2 ICs.

However, the very considerable "overhead" of the PICaxe Basic interpreter is such that a PICaxe GOTO takes approximately 800 ICs (i.e. 0.8 ms) and a "Conditional Goto" (e.g. IF b1 = b2 THEN GOTO .... ) takes about 1200 ICs (i.e. 1.2 ms) to do the jump. The IF <not true> THEN ... condition gives a "Fall Through", which doesn't need a jump and takes about 800 ICs. The simplest instructions (e.g. HIGH <pin>) take about 400 ICs whilst some of the more complex commands can take (many) milliseconds.

Note that the IF ...... ENDIF construction involves a jump (or "skip") when the condition is "Not True", that can help equalise the execution delays for the two alternative paths, for example : IF time > 59 THEN : time = 0 : ENDIF will always take around 1200 Instruction Cycles.

Cheers, Alan.
 

AllyCat

Senior Member
Hi,

That thread contains much useful background information, but unfortunately many of the original "numbers" were made almost obsolete with the introduction of the M2 family, which runs significantly slower (at 4 MHz) than the previous chips. I've posted several versions of a program which can measure the execution times of almost all PICaxe instructions on a Real Chip (not in the simulator), the most recent version being HERE.

I keep my own Speadsheet of typical measurements, but there are so many variations that it's probably impossible to create a "General Purpose" Timing List. For example, the 14/20M2 chips can be significantly slower than the 08M2 (and possibly the 18M2) but faster than the X2 family (at the same clock speed). Then there is an enormous number of available commands, particularly bearing in mind that instructions such as b1 = b2 + 1 , b1 = b1 + 1 and b1 = 1 + b1 all have significantly different execution times. :( But there is almost no difference between b1 = b2 + b3 and w1 = w2 + w3 or between b1 = b1 + 1 and INC b1! Then, even when you understand the basic structure of the commands there can be some "surprises", for example SWAP , RETURN and PWMDUTY can take far longer than might be expected, whilst RANDOM is remarkably quick. ;)

Cheers, Alan.
 

hippy

Technical Support
Staff member
As noted, because of tokenisation, "GOTO main" in one place may not take the same time to execute as "GOTO main" in another.

Arguably the only real rules of thumb are that shorter code is usually faster than longer code which does the same thing, code which does more in one command is usually faster than splitting that across multiple-commands, multiply, divide and modulo will usually take longer than additions and bitwise operations. But it's not always necessarily so.

The best course is to not worry about timing unless one has a good reason to do so.
 

Harry_Worth

New Member
Due to the way PICAXE source code is 'tokenised', it is difficult to determine when code will run faster or slower. Generally, you can expect a decision (like If ValueA = ValueB Then ...) to take longer than simply Goto Main.

Code that is downloaded into a PICAXE chip is not compiled like may other microcontroller systems. The PICAXE has a permanent 'operating system' in its flash memory that interprets tokenised code that is downloaded into the chip. These code 'tokens' are either 5-bits wide (M2 chips) or 6-bits wide (X2 chips). When your PICAXE code is 'run', the firmware extracts each token and performs the task that is required. Since the tokens are stored in 8-bit bytes, extracting each one will result in a range of different times to execute it, depending on were the token is actually stored on a particular download. The result is very compact storage of code but slower and potentially variable execution speed.
Many thanks, that's sort of what I was expecting. I'm driving a small stepper motor and its response to input via an ADC is a little slow.
I'm probably going to try an X processor to see if it gives what I need. In the first instance I'm trying tp make my script a little more efficient short as it is.
 

AllyCat

Senior Member
Hi,

It depends what the ADC is required to do and the function of the motor, but IMHO Stepper Motors are a particular area where it's important to use an "appropriate" code structure and command set (and driver hardware). That might need a skilled eye to look over the program, but unless attempting something too "ambitious", I would not normally expect to (need to) raise the clock frequency much above 4 MHz. ;)

Cheers, Alan.
 
Last edited:

tmfkam

Senior Member
I had thought that most PICs (including the 16F1829 'range' PicAxe M2 devices are based on) had a 4 Clock Instruction Cycle?

Giving a 32MHz clock operation device an Instruction Cycle of 32/4 = 8MHz.

I've been working with timers recently and that is what I based my pre-load value calculations on. They're working, but I could have got mixed up. Again!
 

AllyCat

Senior Member
Hi,
I had thought that most PICs (including the 16F1829 'range' PicAxe M2 devices are based on) had a 4 Clock Instruction Cycle?
Yes that's correct, but nobody (except me) normally discusses the PIC Instruction cycle rate, only the "headline" SETFREQ value (M4 or M8, etc.). However, most of the internal timers, and it happens the X2's external crystal resonator when used, do operate at the PIC's Instruction Cycle frequency.

Cheers, Alan.
 
Last edited:

Harry_Worth

New Member
Hi,

It depends what the ADC is required to do and the function of the motor, but IMHO Stepper Motors are a particular area where it's important to use an "appropriate" code structure and command set (and driver hardware). That might need a skilled eye to look over the program, but unless attempting something too "ambitious", I would not normally expect to (need to) raise the clock frequency much above 4 MHz. ;)

Cheers, Alan.
Thanks for the input.
The driving of the stepper is via a dedicated IC driver which only wants step plus direction. The motor tracks a constantly varying input voltage. I've set my processor to 32Mhz which improves things a lot. The 64Mhz of the X series may do it but when I was planning on just an 08M it seems a bit of overkill.

All I have to do is read a value into the ADC and decide whether to go CW or ACW but this is tested every single step. This is probably where my issue lies. Brute processing speed is being dictated by my crude code.
 

rq3

Senior Member
Thanks for the input.
The driving of the stepper is via a dedicated IC driver which only wants step plus direction. The motor tracks a constantly varying input voltage. I've set my processor to 32Mhz which improves things a lot. The 64Mhz of the X series may do it but when I was planning on just an 08M it seems a bit of overkill.

All I have to do is read a value into the ADC and decide whether to go CW or ACW but this is tested every single step. This is probably where my issue lies. Brute processing speed is being dictated by my crude code.
Here's a video of a Picaxe 20M2 reading a barometric pressure sensor, driving a stepper motor, detecting touch switches, and updating an OLED display:
 

AllyCat

Senior Member
Hi,
The driving of the stepper is via a dedicated IC driver which only wants step plus direction.
So the simple solution is to use a PICaxe PWM Output to clock the Stepper driver and use the Program to update the direction and the PWM period (speed) asynchronously as required. Then it should be sufficient (and probably better) to use the PICaxe at its default (4 MHz) frequency. There are (at least) two potential "disadvantages" in using a higher frequency: The minimum available PWM (i.e. stepping) frequency would be higher and (I believe) the ADC runs from its own (fixed) clock, which may be non-optimum at the highest Program speeds.

Cheers, Alan.
 
Top