Picaxe Code Timings

Hello all, im new here and i just got some starter packs to get started on PICAXE programming, my dad was the one who bought them and he has asked me to find out some information for him here.

Thanks all

Very roughly, 250uS for each command.
Depends on variable values and position in program.
Debug is VERY slow. 32mS from memory.
Bytes used also depends on position in code but 6 bytes per is typical.

Have a read of this:-
http://www.picaxeforum.co.uk/showthread.php?t=10821
to save having to go through it all again.

Hi OCM770,

Welcome to the PICAXE Forum!

This a volunteer group from all over the globe that is eager to answer your question and help you solve a problem. This forum has many members ranging from new comers to very experienced engineers. It is the most active forum for PICAXE microcontrollers.
Some members give quite brief answers while others give extensive details. But, remember all answer to the best of their knowledge.

Topics range form assistance with specific PICAXE programming/hardware problems through to suggestions on possible hardware to use and the occasional non PICAXE discussion.

Please read the "READ Me First!", then check the FAQ, and do a forum search as solution to your problem may already have been posted.
For example, not being able to download a program from your PC to a PICAXE has been covered many times.

For students, we do not do your homework nor school project, and we do expect a willingness on your part to first solve the problem.
We will help you over specific hardware and/or programming problems or give you some general guidance, but we will not design your entire project.

For commercial requests -- remember that you get what you pay for and should follow the Rev_Ed technical staff's response.
There are some unpaid members who are prepared to help you over specific hardware and/or programming problems or give you some general guidance, but use this information at your own risk, and we will not design your entire project/module.

Unfortunately the forum cannot afford a crystal ball, so the more information you give us, the better we can respond.
"My PICAXE doesn't work!" is not very helpful.
A description of what you are trying to achieve, what is going wrong together with your program code, schematics and clear photos are very helpful.

Note that PICAXE chips have different commands so, for example
telling us exactly which PICAXE you have means we can better recommend the best program command to use.

To get a better response we suggest that you please cut and paste the following text to start your response and then remove unwanted options and/or fill in the blanks. While this may take a few minutes it can save several posts back and forth to get to the bottom of the problem. The more information that you provide the quicker your problem may be solved.

These include:
Describe the symptoms and describe clearly what checks you have already done to try and solve the problem.

Post the entire program code or a major section, not just the few lines where you think is where the problem is.
This will help us better look for possible errors such as duplicate use of variables, missing subroutine RETURN commands,
and similar “hiccups”. Please put your code in the main body of the post and enclose it within program start [code ] and end [/code ] tags.
We suggest that you read the sticky README FIRST thread at the top of the forum for more details if this is not clear.

Please upload your circuit diagram. This in conjunction with knowing the board for your PICAXE chip will help us check if your circuit
has any problem or to remove that from consideration.

Sketch you circuit in MSPaint or in a PCB cad program and save as a .jpg file tpe or possibly even in Excel and save as a pdf file
if you have pdf creator software (this is available free on the internet).

If possible, please upload a photograph clearly showing your project.
Even a good photo from a mobile phone can help.
The photo needs to be clear enough that we can identify component and exactly were each wire terminates.
This will help us cross check your wiring against the circuit diagram.

Please give us an internet link to the datasheet for any special chips or non Rev Ed parts so that we can study
these to help you better.

Remember that being polite and a few thank you's to those who helped will get you further with additional/subsequent information.

Please cut and paste the following and fill in as much information as possible:


**************************************************

Project Purpose (Describe what your project is intended to do):

Project Type: (school / commercial / hobby):

PICAXE experience level (new / a bit / intermediate / expert / guru):

General Electronics experience level (new / a bit / intermediate / expert / guru):

The type of PICAXE chip you are using (08M / 14M / 18X, etc):

Type of board (breadboard / AXE20 / AXE21 / AXE022 / AXE023 / CHI030 / CHI035 / CHI040 / by PH Anderson / Homemade / Other):

Program cable (Serial / USB / AXE26 / AXE27 / homemade):

The problem(s) I am having is:

My program code:

Photographs:

Datasheet links:

**************************************************

Myc
_______________

I will likely be starting to measure times to execute each picaxe command after christmas, when I've bought an intelligent oscilloscope. I was thinking of doing this to enhance picaxe VSM further.
'ocm770', Are you thinking of doing the same?

The 'high' and 'low' commands take less time to execute than the other commands, or do they?

If you read the link I posted and the links within that, it has already been done. No need to use a scope. Use another PICAXE.
Put the command in a loop
High before the command, low after it. Measure the pulse, sertxd to PC screen.
Then do it again with a "pause 1" just before the loop to see the effects of moving it in memory.

Hello OCM770 (and your Dad !). Good general guidance already given. A lot of helpful people here and we're an inquisitive bunch ....so I'll start by asking: Why do you want to know the execution times? Is this just to get a 'feel' for picaxes and how fast they run, or is it something more specific?

Pushing the limits to the challenge.

I am the person that originally requested the execution times and memory requirements.

The 08M only has about 256 Bytes available for program memory. Certain applications push the limits of this available memory, and other applications, both for the 08M and the other picaxes, push timing limitations, even when boosting internal clock speed. When addressing designs like these, knowing execution times and memory requirements can make the difference between using an 08M or a more expensive device. In large volume applications, that can mean a lot of money.

Even if the limits aren't pushed, though, it is always interesting to be creative in the software development, and the more you know about it, the more creative you can be. Besides creativity, though, development optimization is something that should always be under consideration when writing code, both in terms of total time required to execute a given set of instructions to achieve a desired result, as well as the amount of program memory required for that same purpose. If you can achieve an objective in half the time with half the memory at the cost of a little brainpower during the design phase of a project, the end result is all the more rewarding....

Odessa

Hi, You could be right - As a project manager I had nightmares with "smart" software engineers who squeezed every byte out of the system because they could.

Whilst the cost of hardware is so relatively low and larger and large pics available often with better and larger instruction sets squeezing is not often needed or advisable as clarity may well be preferable.

As a by the by searching the forums will often elucidate earlier posts on most subjects.

BeanieBots, thanks for your general answer. 250 uSec sure seems like a LOT at 4 MHz; that is 1000 clock cycles per Basic instrucion - really a huge amount.

What about the PauseUS command, which is supposed to enable pauses in increments of 10 uSec? If it IS able to effect a pause of 10 uSec minimum, what is so special about the structure of that command that it can execute 25 times faster, in general, than the other commands?

Next, the reference to '1000' above reminds me that the Picaxe manual, I believe in Part II, indicates there are roughly 1000 lines of assembly code for every line of Basic code. That seems way too high to me; is it accurate? If so, and per your answer in this thread, it would take one clock cycle per assembly instruction, and that seems like not enough!!

Don't most binary instrucitons take one clock cycle, or two, nominally?

Finally, you indicate 6 bytes per instruction is typical, but the manual states about 80 lines of Basic code; for 256 bytes of program memory, that works out to between 3 & 4 bytes each. Where's the discrepancy??

Thanks, Odessa.

RickHarris, thanks for your reply. Yes, fortunately memory, etc. is becoming relatively inexpensive, and yes, clarity is important. Fortunately, comments in the basic programs are free memory-wise, and necessary time-wise, so it pays to pay attention to that too.

In general, though: Better, Cheaper, Faster, Lighter, & Lower Power is what wins new designs; many portable designs now have a premium on space & weight, so besides traditional cost and battery life concerns, the smaller the parts count and associated part packages, the more attractive the overall design....

Odessa

The reason PICAXE is slow is because it is interpreted BASIC. The basic instructions need to be unpacked first. This allows much more to be squeezed into the very limited space.

Your figures don't sound right but I'll let somebody who knows more than me confirm one way or the other.

As an aside, there are four members here so far that have join dates listed as Jan '70. That must be an artifact of the site, as I don't believe MicroChip even existed back then.....or else, that would make you guys, as senior members and/or moderators, at least near sextogenarians....

Odessa

Those who joined in 1970 were members of the "old" forum. That was about a year ago. However, I have been playing with electronics since around then

@ Odessa

Some ageism creeping in there?

Do you have something against your parents/grandparents/greatgrandparents being around so long?

As recently noted, Hippy has attained the big 50!

I think there is some confusion between the speed of machine code and interpreted BASIC.

The native language of a PIC microcontroller and any microprocessor for that matter is machine code.

Some people use the term assembler in lieu of machine code but with assemblers they use mnemonics which are pseudo text codes that are easier for us humans to understand and turns them into binary values for the microprosessor to use. So, assemblers generate machine code for micro-processors to use.

With many micro-processors, yes, it equates roughly to 1 instruction per clock cycle so a 4MHz processor will execute approx 4 million instructions per second.

In the case of the PIC's as used for PICAXE's, one instruction cycle consists of four oscillator periods, so for an oscillator frequency of 4 MHz, this gives a normal instruction execution time of 1 μs. All instructions are executed within a single instruction cycle, unless a conditional test is true, or the program counter is changed as a result of an instruction. When this occurs, the execution takes two instruction cycles.



The PICAXE is programmed in BASIC which is an interpreted language. To save space, the Program editor (as with most BASIC interpreter systems) tokenises you program and instructions are stored by say one 8-bit byte rather than for example the PAUSE command occupying 5 bytes. Rev Ed has further compressed things so some codes and variable space my not require a full byte.

But when we come to execute a BASIC program, the inbuilt interpreter (within the PICAXE chip) must first read the tokenised code, and then execute many machine code instructions to achieve this action.

In a form of pseudo code, if we have the BASIC command:

Only as a rough guide in machine code as to what we must get the PICAXE processor to:
1. get the token and determine that it is a FOR command
2. make a flag as to which variable (b0) is to be used as the counter
3. take the next value (1) and store that in another location as a starting point
4. take the next value (255) and store than in another location as an end value
5. put the start value into variable b0
6. start a loop
7. load the accumulator with b0
8. add 1 to the accumulator
9. save the accumulator in variable b1
10. load the accumulator from variable b0
11. add 1 (or the STEP value) to the accumulator
12. save the accumulator back into variable b0
13. test is the accumulator value is greater than then end value
14. branch back to start of the loop if accumulator is less than end value – so back to step 7
15. go load the next BASIC command read to interpret.

As you can see, there are many steps here (and this is very rough) to represent a simple FOR…NEXT command. In between times, there are overheads like checking for interrupts, handling PWM signals, etc that all take time as well.

So at the end of the day, one BASIC command can occupy 20, 50 or maybe around 100+ machine code instructions plus the overheads of reading the BASIC code and setting up to action the BASIC so before we know it BASIC commands can occupy anything from 100 to 1000 microseconds each.

Beaniebots has already done some BASIC command timing. Unless you are in need of some critical timing requirement, I suggest you accept that BASIC is slower and just use it.

Command execution times will vary according to the position of where the tokens are stored. My understanding is that the PICAXE tokens are NOT 8 bits long, so 'flow' from 1 byte to the next when stored in the EEPROM or flash. Consequently, there can be varying cycles per command, depending on command and position.

For an 08M and 14M at 4MHz, I have found that the PulsOut command has an overhead of around 470uS, so a 30uS pulse on an output pin will actually take 500uS to complete. The overhead of a subroutine call takes about 890uS while copying a byte from 1 register to another takes about 390uS. Setting a single bit in a byte register takes about 350uS. etc etc

How did I find this out? I had a time critical application to develop and so I sat down for hours with a PICAXE, PE and CRO and worked it all out (I actually ran the PICAXE at 8MHz, not 4MHz). There are often many ways to do the same thing (eg looping) and some are far more efficient than others....

Westaust, a small correction - the 8-bit Microchip microcontrollers (on which the Picaxe's are based) - need 4 clock cycles per instruction (except for branches, which I believe take twice as long). So at 4 MHz they execute 1 million machine code instructions per second. The Atmel AVR devices have a different architecture, they can indeed execute one command per clock cycle, but their max. clock frequency is lower.

Second, I assume you meant "100 to 1000 microseconds", mor "...milliseconds", right?

How much faster a program written machine code (or compiled from a high-level language like C) really is compared to the Picaxe depends a lot on the specific task. Toggling a pin - huge, max. toggle rate less maybe 1 kHz on a Picaxe, but well over 100 kHz in machine code (at 4 MHz clock). Reading the ADC - maybe a factor of 10 to 20. Sending data over the serial port - much less than 10, and at the same data rate almost identical.

I had a rather complex program (controlling a time domain reflectometer) which did a lot of the latter two (ADC abd serial), actual gain in porting it to compiled C on a PIC16F886 was less than a factor of 4. I have to admit that in this case the Picaxe code was highly optimized and the hardware design was geared towards making things easy for the Picaxe. I am also looking into porting my scope design to a bare PIC, but since the speed there is mostly limited by the serial data rate (the Picaxe already sources data as fast as it can send it with hserout) the gain is equivalent to the possible increase in the data rate (current design 19.2 kbaud with 28X1 and 38.4 kbaud with 28X2, max. standard rate 112 kbaud, so best case speedup less than factor 3 compared to 28X2).

Wolfgang

Odessa said:

What about the PauseUS command, which is supposed to enable pauses in increments of 10 uSec? If it IS able to effect a pause of 10 uSec minimum, what is so special about the structure of that command that it can execute 25 times faster, in general, than the other commands?

Click to expand...

As described in Manual 2 there is an overhead time associated with the PauseUS command as with other PICAXE commands so it cannot effect a 10us delay in itself. The actual pause time can however be adjusted in 10us interval lengths.

womai said:

Westaust, a small correction - the 8-bit Microchip microcontrollers (on which the Picaxe's are based) - need 4 clock cycles per instruction (except for branches, which I believe take twice as long). So at 4 MHz they execute 1 million machine code instructions per second. The Atmel AVR devices have a different architecture, they can indeed execute one command per clock cycle, but their max. clock frequency is lower.

Second, I assume you meant "100 to 1000 microseconds", mor "...milliseconds", right?

How much faster a program written machine code (or compiled from a high-level language like C) really is compared to the Picaxe depends a lot on the specific task. Toggling a pin - huge, max. toggle rate less maybe 1 kHz on a Picaxe, but well over 100 kHz in machine code (at 4 MHz clock). Reading the ADC - maybe a factor of 10 to 20. Sending data over the serial port - much less than 10, and at the same data rate almost identical.

Wolfgang

Click to expand...

Thanks for the corrections Womai - those fiendishly flailing fingers again
I have corrected my earlier post so that it reads better/correctly.

I have previously written a lot directly in machine code, Assembler and in BASIC on 8-bit microcprocessors, but other languages only on larger machines. Know/acknowledge where your are coming from as I have often read that C can be quite large when compiled - aka "bloat-ware".

I think if picaxes were incredibly fast and had masses of code space we wouldn't have half as much fun trying to push the boundaries by ingenious code etc Enjoy the limitations while they last .... before we get quantum microcontrollers ! Plus just think how clunky the bloatware on PCs can be.

Very true Jeremy.

Those who don't want to reminisce can stop here:

Back about 30 years ago (wow only seems like yesterday ) I took a commercial a 6502 machine code word processor (not Apple or Commodore either - had a "better" machine with 16 colour graphics back in 1979), then reworked the WP and squeezed it into a 2k byte EPROM. Sure only 1 font size, no embedded pictures, but margins, tabs, contents pages, bold, italics and underline plus paragraph and page markers were all there along with many keyboard shortcuts.

On a 1990's Psion palmtop I could have 300+ page documents in just a couple of kbytes.

Then look at MS Word - needs 100's of MB to install and just creating an empty document (open then saveas - nothing more) takes around 23kbytes.

Thanks, guys, the discussion has been quite informative regarding command timing issues for the Picaxes.

Here, we had created a quasi-RTC using an 08 with three loops, two nested, for hours, minutes, seconds, and using the Pause command. We measured against an external clock over a relatively long time period compared to what it takes to send debug memory information back to the screen. We were able to adjust the RTC performance by altering the # of milliseconds in the Pause command, and were able to get pretty close to RTC performance, at least over a few day period at room temperature and using a regulated Vdd.

That clock worked great on the one 08 we ran it on, and we knew it ran 0.7% slow, however, I had not considered that if we moved the code to a different section of program memory all that could change. So, there arises a question: would it be fair to assume that the tuned quasi-RTC performance will not change as long as any future code changes come AFTER the RTC loops (i.e. further down the Basic program)? Or, another way to ask this same question is: Can or will changes in the Basic code made after the RTC 'module' shift the position of that module in program memory?

Odessa

The execution time of code towards the start of the program will not itself change if anything is added or changed after it, for example ...

The time Output Pin 1 is high will remain 'locked' as long as nothing is added before the "Low 1". The rate Output Pin 1 is activated depends on what is added before or changed after "Low 1".

Don't forget that the execution times of any PICAXE using an internal oscillator depends on voltage, temperature and manufacturer tolerance.

I don't know the answer to your exact question, but I would suspect that anything written AFTER your code would NOT affect it's timing.
However, if you were to use that code in any way (ie break out of the earlier loop), then obviously the timing would be affected and your clock would need to be re-callibrated. So, it doesn't really matter if it does or not. Either way if extra code is added (and actually used) then timing is affected.

EDIT: crossed with hippy's more detailed reply

"The execution time of code towards the start of the program will not itself change if anything is added or changed after it ..."

Ok, that's what I thought, except your example didn't include any branching from AFTER the RTC module to BEFORE it; if such branching were added after the module once the clock was tuned, could THAT affect a reorganization or relocation of the code prior to and including the RTC code in program memory?

Odessa

Changing anything before a tuned section can affect the timing of that section. Therefore always put tuned sections at the start of code ( with a jump around them as in the example) and, once tuned, do not alter any code in or before the tuned section.

As long as all code up to the end of the tuned section remains unchanged its timing will remain the same.

Ok, Hippy, thanks!

Odessa....

[ Discussion on Forum Etiquette moved to existing thread ]

So the Picaxe carries it’s own interpreter. No wonder there’s such limited space and it runs so slowly. Hmm. That’s gonna complicate the inline assembler a little. I figured it was compiled by the editor before burning it to the chip. Why have an interpreter onboard? What’s the advantage?

It's code space. I think on balance you can get more 'lines of basic code' on a pic chip by having it interpreted rather than compiled. There will be some break-even point I'm sure, but don't know (i.e a tiny basic program would be better compiled, without the overhead of the interpreter). I'll let the experts give the detail though ...

It's the only way to do it for the low pin count PICAXE chips, other than requiring the PICAXE developer to also buy a hardware programming module and it would require a more complicated and more difficult to use 'download interface'.

Still don’t see it. But I’ll take your word for it.