What's in a PicAxe?

whiteoaks7

New Member
Forgive me if this is an old question, if it is perhaps someone can direct me to an answer... The question goes like this - once upon a time I used to program PICs using Assembler. This was a masochistic passtime but I was paid for it! The PICs were destined for automated test gear and had to be rigorously controlled in both hardware and software to prevent the manufacturer making revisions that would invalidate all sorts of things. When I was free to choose hardware for my own projects I wanted to get away from Assembler (I flirted briefly with C - very briefly :) then found the PicAxe. Since I was used to PICs this was a logical progression.

But now I've got to wondering, just what is the PicAxe architecture like? The hardware is defined and is a PIC which implies that the embedded software is different. So what happens to the program I write, how does it become machine code? I read references to a compiler. The code written in Assembler for a PIC is assembled into machine code then loaded into the PIC hardware. Does the PicAxe compiler create machine code directly or some intermediate code that the PicAxe then operates on (I've written compilers that have done both). If, on the other hand, the Basic code is loaded into the PicAxe then it's not compiled but interpreted - I'm guessing this doesn't happen because it would be awfullllllllly slow. So, is the PicAxe a PIC with extended software - there must be something going on because of the differences between the PIC and PicAxe functions available. If so, is the PicAxe embedded software in any way revision controlled and do we get to know when revisions change? Educate me please... :)
 

Captain Haddock

Senior Member
I was under the impression they were just a bubble of plastic filled with magic smoke that no longer function once the smoke is released, now you go letting me down with talk of technology and science, dissapointed or what.....
:)
 

g6ejd

Senior Member
If you have written a compiler; then in the nicest possible way, I can't help but wonder why you are asking these questions, because I think you should instinctively know the answers.

Like you, I don't know exactly the software architecture used, but my guess is as follows in answer to your questions:

Q. How does it become machine code? It doesn't.
Q. Does the PicAxe (programme editor) compiler create machine code directly? No
Q. Does the PicAxe (programme editor) compiler create some intermediate code that the PicAxe then operates on? Yes
Q. If, on the other hand, the Basic code is loaded into the PicAxe then it's not compiled but interpreted - I'm guessing this doesn't happen because it would be awfullllllllly slow? Not necessarily so, as you can see with a PICAXE.
 

inglewoodpete

Senior Member
If, on the other hand, the Basic code is loaded into the PicAxe then it's not compiled but interpreted - I'm guessing this doesn't happen because it would be awfullllllllly slow.
Interpreted, yes. But the "compiler" tokenises your code to improve efficiency. On your speed concern, I have found that there very few tasks that the modern PICAXE can't do.
 

westaust55

Moderator
If you have a read through the document I posted here: http://www.picaxeforum.co.uk/showthread.php?17782-PICAXE-program-Size-Optimisations-and-Speed
that will give you some insight to the tokenised and compressed BASIC files as downloaded into the PICAXE chips.

A read of this thread to the end may also provide you with some further clarifying information:
http://www.picaxeforum.co.uk/showthread.php?12874-What-is-the-bootstrap-program


EDIT:
The fact that the downloaded code is compacted as well as tokenised does incur some time delay to extract tokens and values which may cross byte boundaries. The “efficiency” is with respect to program memory use.
 

hippy

Technical Support
Staff member
Does the PicAxe compiler create machine code directly or some intermediate code that the PicAxe then operates on (I've written compilers that have done both). If, on the other hand, the Basic code is loaded into the PicAxe then it's not compiled but interpreted - I'm guessing this doesn't happen because it would be awfullllllllly slow.
A traditional interpreted Basic will convert the entire source to a tokenised form and keep it all in program memory, primarily so it can fit in a small memory while an interactive LIST command can show the entire source code as originally written.

PICAXE Basic compiles into tokens which represent only the entities needed for the command to be executed which can be considered intermediate code which is then interpreted.
 

mrburnette

Senior Member
Ohh.. the shame of it... programming since 1968, 62 languages, and now (holds hand to forehead in a tragic gesture) I'm writing interpreted Basic!
Well, we're only a few years apart in the programming area, and while I am double-digit in language counts, I am no where near 62! However, in defense of the PICAXE architecture, it is an evolutionary form of the old BASIC Stamp design; kind of on steroids. Amazingly, the chips perform remarkably well, are economical, and the system is well-documented and supported largely by this diverse member forum. You can get your hands around a weekend PICAXE project easily, multitasking at the design while watching some brain-sucking TV program. There are a multitude of ways to increase efficiency, assuming you are up to venturing from the most common 20 commands.

I am vocal often in the area of architecture, but I am always supportive of the effort made by RevEd and their continued backward-compatibility. The PICAXE is kind of like a Swiss-Army knife... it is many things all rolled into one. You certainly cannot go wrong for the price of the chips and workable prototypes are easily created. I have often (cough, cough) used the PICAXE for a prototype and then converted the design into C/C++ or perhaps an algorithm into assembler .S files.


- Ray
 

whiteoaks7

New Member
Hang on guys, it's beginning to sound as if I'm knocking the PicAxe and everything about it, definitely not! I started by saying I moved to PicAxe to escape the masochism of Assembler and I stick by that. I am, however, surprised to find an embedded interpreter rather than a compiler which would be a better option in both speed and size terms. Surprised yes, but not to the extent of reversing my move to PicAxes.

I do tend to 'collect' languages though actually the 62 languages count includes dialects (including interpreted BASICs for the 80's microcomputers) so I'm pushing the stat a little; but doesn't include PicAxe Basic so it's 63 now :) I started with 803 Autocode, Algol (lovely), Cobol and Fortran (yuk and yuk) lots of Honeywell mainframe stuff .... Prolog (luvit), Flex, 6502, Z80, 8085 and 6809 assemblers, Forth .... ADA (!!!!) Pascal and the 'visuals' Visual Basic in all it's forms, Visual Prolog (another: !!!) and the Zylog language. Never did much in 'C' or its derivitives nor Java, but some HTML (does that count as a language). These days just VB (6 or Net), PIC Assembler and now PicAxe Basic and just enough HTML to keep the website up. Sounds a lot but only an average of one per year :-(
 

John West

Senior Member
I've spent my time in the field of programming languages learning just enough to perform patches and apply band-aids to the code of others, or to make it do what I want, not what they wanted. That adds up to 4 or 5 languages and 2 or 3 versions of each. But my goal all along has been to get something done with as little wasted time and effort as possible.

That has led me to the PICAXE chip series, and I think I've finally found what I was looking for, a programming language that lets me get things done that I want done, quickly and easily.
 

Technical

Technical Support
Staff member
I am, however, surprised to find an embedded interpreter rather than a compiler which would be a better option in both speed and size terms. Surprised yes, but not to the extent of reversing my move to PicAxes.
A little silicon history very easily explains that.

Originally none of the PICs, especially the little 8 pin chips like the 12F629/12F683 (the original 8 pin PICAXE's) had any low voltage reprogrammable program memory at all. The *only* memory available that could be self reprogrammed in those chips was 128/256 bytes of EEPROM memory.
So the *only* way the PICAXE chip concept could be produced was to have all the firmware pre-programmed in the (user unchangeable) program memory, with the user's tokenised 'BASIC' highly optimised and squeezed bit by bit into the EEPROM.

Obviously silicon technology has changed over the years, but many people still often forget with this type of discussion that it was still only 18 months ago that any 8 pin chip with reprogrammable flash memory (as now used in the much larger memory capacity 08M2) became available.
 

mrburnette

Senior Member
@whiteoaks7:

From a historical perspective, you should find this of interest:
Assembler-The-PIC-Source-Book

then for comparison purposes (code size):
PICAXE-amp-Arduino-%28code-size-comparisons-just-for-fun%29

Obviously, the Arduino environment is not pure C/C++ since there is a significant overhead in their "portability libraries" ... however, the comparisons are fair in that the byte sizes compared are the consumption of user-flash storage.

- Ray

PS: you're going to like the PICAXE... they tend to grow on you (well, the truth is that you tend to order several versions and several of each since they are like 555 timers... always finding uses for 'em.)

I believe the proper terminology for HTML is "script", but I would consider it an interpretative language since it must run within a 'container' (browser/other HTML rendering engine) to perform the programmer's intent.
 

chipwich

Member
PS: you're going to like the PICAXE... they tend to grow on you (well, the truth is that you tend to order several versions and several of each since they are like 555 timers... always finding uses for 'em.)
At some point, pretty much all designs can be emulated by a system-on-a-chip. As the cost of PICAXE chips goes down and capabilities go up, there's less need to have a variety of other ICs; It's easier to stock a few PICAXE models and just reprogram them to emulate anything else you might need. I wouldn't even consider using 7400 logic (does anyone still use it?!?), 555/556, etc. when I could use a PICAXE.

I think replacements for legacy IC parts are now manufactured by simulating functionality rather than keeping the original designs. Perhaps someone else can comment.
 

John West

Senior Member
I keep a very good selection of TTL and CMOS logic (and 555's) around for repairing old equipment. However, I also have several different PICAXE chips handy as well. The more options one has, the better the choices made. However, the magic smoke will sometimes still get out.
 

premelec

Senior Member
@MrB... Ray thanks for that reference to Scott Edwards' assembly listings for BASIC - that's good learning and also indicates the reason I don't do assembly :)

@Chipwich... There are sometimes reasons to use other chips - e.g. 15 volts on a 555 to drive a MOSFET gate without a voltage up-converter.
However one of the great things about electronic design is there are so many ways to do the same thing :)
 

chipwich

Member
@Chipwich... There are sometimes reasons to use other chips - e.g. 15 volts on a 555 to drive a MOSFET gate without a voltage up-converter.
However one of the great things about electronic design is there are so many ways to do the same thing :)
That's only because the on-chip DC-to-DC converter isn't working... yet. 8^)
 
Top