Writing Maintainable Picaxe Code
- Thread starter Tom2000
- Start date
BeanieBots
Moderator
Not really, all perfectly doable with PICAXE BASIC but an inline assembler would be nice
You don't need an inline assembler to push and pop.
Some compilers have this built into the sub/procedure call syntax anyway.
A simple variable assign in any language compiles perfectly as well.
But I guess it impresses the girls.
And if you want speed then you insert the code in place rather than going off to a lable.
Some compilers have this built into the sub/procedure call syntax anyway.
A simple variable assign in any language compiles perfectly as well.
But I guess it impresses the girls.
And if you want speed then you insert the code in place rather than going off to a lable.
Jeremy Leach
Senior Member
Just to throw in the mix ...a while ago I added this topic on push/pop to the code section http://www.picaxeforum.co.uk/showthread.php?t=10328
When I started coding for Picaxe chips I found the overlaying of b0 with w0 and bit0 etc rather confusing. So to ensure that I didn't reuse the same storage for different variables while I learned the arrangements I made a little template, below offered for free. To use a register I simply remove the apostrophe and insert the variable name and a description. Then I know what I have remaining. Not rocket science, but then reliable programming shouldn't be.
------
'REGISTER VARIABLES
'Symbol Vname = w0 'w0 = (b1:b0) used for:
'Symbol Vname = b0 'overlays w0 used for:
'Symbol Vname = b1 'overlays w0 used for:
'Symbol Flag_name = bit15 'overlays w0 used for:
'Symbol Flag_name = bit14 'overlays w0 used for:
'Symbol Flag_name = bit13 'overlays w0 used for:
'Symbol Flag_name = bit12 'overlays w0 used for:
'Symbol Flag_name = bit11 'overlays w0 used for:
'Symbol Flag_name = bit10 'overlays w0 used for:
'Symbol Flag_name = bit9 'overlays w0 used for:
'Symbol Flag_name = bit8 'overlays w0 used for:
'Symbol Flag_name = bit7 'overlays w0 used for:
'Symbol Flag_name = bit6 'overlays w0 used for:
'Symbol Flag_name = bit5 'overlays w0 used for:
'Symbol Flag_name = bit4 'overlays w0 used for:
'Symbol Flag_name = bit3 'overlays w0 used for:
'Symbol Flag_name = bit2 'overlays w0 used for:
'Symbol Flag_name = bit1 'overlays w0 used for:
'Symbol Flag_name = bit0 'overlays w0 used for:
'Symbol Vname = w1 'w1 = (b3:b2) used for:
'Symbol Vname = b2 'overlays w1 used for:
'Symbol Vname = b3 'overlays w1 used for:
'Symbol Vname = w2 'w2 = (b5:b4) used for:
'Symbol Vname = b4 'overlays w2 used for:
'Symbol Vname = b5 'overlays w2 used for:
'Symbol Vname = w3 'w3 = (b7:b6) used for:
'Symbol Vname = b6 'overlays w3 used for:
'Symbol Vname = b7 'overlays w3 used for:
'Symbol Vname = w4 'w4 = (b9:b8) used for:
'Symbol Vname = b8 'overlays w4 used for:
'Symbol Vname = b9 'overlays w4 used for:
'Symbol Vname = w5 'w5=(b11:b10) used for:
'Symbol Vname = b10 'overlays w5 used for:
'Symbol Vname = b11 'overlays w5 used for:
'Symbol Vname = w6 'w6=(b13:b12) used for:
'Symbol Vname = b12 'overlays w6 used for:
'Symbol Vname = b13 'overlays w6 used for:
------
'REGISTER VARIABLES
'Symbol Vname = w0 'w0 = (b1:b0) used for:
'Symbol Vname = b0 'overlays w0 used for:
'Symbol Vname = b1 'overlays w0 used for:
'Symbol Flag_name = bit15 'overlays w0 used for:
'Symbol Flag_name = bit14 'overlays w0 used for:
'Symbol Flag_name = bit13 'overlays w0 used for:
'Symbol Flag_name = bit12 'overlays w0 used for:
'Symbol Flag_name = bit11 'overlays w0 used for:
'Symbol Flag_name = bit10 'overlays w0 used for:
'Symbol Flag_name = bit9 'overlays w0 used for:
'Symbol Flag_name = bit8 'overlays w0 used for:
'Symbol Flag_name = bit7 'overlays w0 used for:
'Symbol Flag_name = bit6 'overlays w0 used for:
'Symbol Flag_name = bit5 'overlays w0 used for:
'Symbol Flag_name = bit4 'overlays w0 used for:
'Symbol Flag_name = bit3 'overlays w0 used for:
'Symbol Flag_name = bit2 'overlays w0 used for:
'Symbol Flag_name = bit1 'overlays w0 used for:
'Symbol Flag_name = bit0 'overlays w0 used for:
'Symbol Vname = w1 'w1 = (b3:b2) used for:
'Symbol Vname = b2 'overlays w1 used for:
'Symbol Vname = b3 'overlays w1 used for:
'Symbol Vname = w2 'w2 = (b5:b4) used for:
'Symbol Vname = b4 'overlays w2 used for:
'Symbol Vname = b5 'overlays w2 used for:
'Symbol Vname = w3 'w3 = (b7:b6) used for:
'Symbol Vname = b6 'overlays w3 used for:
'Symbol Vname = b7 'overlays w3 used for:
'Symbol Vname = w4 'w4 = (b9:b8) used for:
'Symbol Vname = b8 'overlays w4 used for:
'Symbol Vname = b9 'overlays w4 used for:
'Symbol Vname = w5 'w5=(b11:b10) used for:
'Symbol Vname = b10 'overlays w5 used for:
'Symbol Vname = b11 'overlays w5 used for:
'Symbol Vname = w6 'w6=(b13:b12) used for:
'Symbol Vname = b12 'overlays w6 used for:
'Symbol Vname = b13 'overlays w6 used for:
Rickharris
Senior Member
When I taught PICAX use at school as part of the process we looked at using flow charting as a way to clarify our thoughts - At the time I published this on the instructables web site.
Using flow charting came from my days as a process control developer. The company I worked for were finding software hard to control and get right. I suggested this was because from the start they didn't understand what they were trying to do and neither did the customer.
I developed flow charting as a way to get all of the facts together in a format that the customer and the programming team could understand and agree.
We could then control project changes and breakup the development process so a team could address it efficiently.
A handy by-product was we more or less automatically produced documentation for each module as it was developed. This became invaluable when at a later date the Fedral Drug Administration USA demanded all pharmaceutical software had to be validated (audited) to PROOVE it was reliable and did what it was supposed to do.
Most people see flow charting and the like as a pain in the A$$ BUT, overall, getting it right in the first place shortens the development time and, when dealing with a product you can't see, touch, weigh or measure easily, it makes it so much more likely you will get something that actually works.
Using flow charting came from my days as a process control developer. The company I worked for were finding software hard to control and get right. I suggested this was because from the start they didn't understand what they were trying to do and neither did the customer.
I developed flow charting as a way to get all of the facts together in a format that the customer and the programming team could understand and agree.
We could then control project changes and breakup the development process so a team could address it efficiently.
A handy by-product was we more or less automatically produced documentation for each module as it was developed. This became invaluable when at a later date the Fedral Drug Administration USA demanded all pharmaceutical software had to be validated (audited) to PROOVE it was reliable and did what it was supposed to do.
Most people see flow charting and the like as a pain in the A$$ BUT, overall, getting it right in the first place shortens the development time and, when dealing with a product you can't see, touch, weigh or measure easily, it makes it so much more likely you will get something that actually works.
Indeed. Flowcharting is the bridge between verbose written specifications and the actual code implementation, much like an architect's drawing is the bridge between a customer's brief and a house being built.
Where a plan may show, "We'll have a window here", a flowchart may show, "We'll read a temperature here". The specification can be compared to the flowchart to see if it does all that is required, the flowchart can be compared to the specification to ensure everything implemented does as intended. Creating a drawing or flowchart may also ( and quite often ) show up weaknesses or oversights in the original specification; "You have a shed, but no doors", "You read a temperature but never use it".
When a plan or flowchart is complete, matches all the customer wants, it's a clearer view of things than the original specification, which was usually written for non-experts rather than builders or coders to understand. Actually building the thing should then be a simple and routine matter of converting the plan or flowchart into reality.
Where a plan may show, "We'll have a window here", a flowchart may show, "We'll read a temperature here". The specification can be compared to the flowchart to see if it does all that is required, the flowchart can be compared to the specification to ensure everything implemented does as intended. Creating a drawing or flowchart may also ( and quite often ) show up weaknesses or oversights in the original specification; "You have a shed, but no doors", "You read a temperature but never use it".
When a plan or flowchart is complete, matches all the customer wants, it's a clearer view of things than the original specification, which was usually written for non-experts rather than builders or coders to understand. Actually building the thing should then be a simple and routine matter of converting the plan or flowchart into reality.
Let's bump this excellent thread, so it does not completely wanish..
The current picaxe project I'm working on has quite a complex and long winded code, and with my usual methods of not-so-organized codewriting I again ran into the problem of keeping track which variable is used where. It only recently dawned on me what "stack" really means in programming and how it's being implemented for example in C-compilers. So this sparked an idea, because picaxe lacks local variables in functions, it could be possible to implement a stack and local variables with the scratchpad.
As it turns out, hippy described the process on the earlier page, but it just didn't dawn on me what good it would do when I was reading this thread earlier. I've just started to implement it, and it seems to make the programming quite much more readable. Performance wise it might not be the best solution, but in this case I can spare processing power.
The current picaxe project I'm working on has quite a complex and long winded code, and with my usual methods of not-so-organized codewriting I again ran into the problem of keeping track which variable is used where. It only recently dawned on me what "stack" really means in programming and how it's being implemented for example in C-compilers. So this sparked an idea, because picaxe lacks local variables in functions, it could be possible to implement a stack and local variables with the scratchpad.
As it turns out, hippy described the process on the earlier page, but it just didn't dawn on me what good it would do when I was reading this thread earlier. I've just started to implement it, and it seems to make the programming quite much more readable. Performance wise it might not be the best solution, but in this case I can spare processing power.
For people who have had formal training in programming all this is common sense ('second nature'). Having said that, there is some good info here.
Quite a lot of stuff that should be taught to pupils if teachers were aware.
Yes, you can do what you like as long as you realise that scratchpad usage is not real stack or real local variables. By all means refer to it as a software stack if you want. I would think you are treating it more as an array rather than a stack.
I'd leave all the flashy stuff to compilers
Quite a lot of stuff that should be taught to pupils if teachers were aware.
Yes, you can do what you like as long as you realise that scratchpad usage is not real stack or real local variables. By all means refer to it as a software stack if you want. I would think you are treating it more as an array rather than a stack.
I'd leave all the flashy stuff to compilers
fernando_g
Senior Member
my two yen:
Comment also the functionality of the hardware pins. To exactly what each input or output is connected to, and describe, or provide part# for the device.
Also include a schematic reference number (and by the same token, in the schematic include the name and revision of the .BAS file)
Comment also the functionality of the hardware pins. To exactly what each input or output is connected to, and describe, or provide part# for the device.
Also include a schematic reference number (and by the same token, in the schematic include the name and revision of the .BAS file)
On hardware pin allocation, though some don't like it, that's where ASCII art comes into its own as it can be included within the source code.
In test programs I write I find it very handy to have a complete pinout at the top which shows what connects to where when I come back to it on an AXE090 board. Saves having to go through the code finding Symbols or worse still looking at each command to see what they use.
When using pins it's usually best to define them with a Symbol then they can easily be changed in one line without hunting through the code for all occurances. It doesn't help all the time, especially if "pin=" and so on are used but does help in a lot of cases.
In test programs I write I find it very handy to have a complete pinout at the top which shows what connects to where when I come back to it on an AXE090 board. Saves having to go through the code finding Symbols or worse still looking at each command to see what they use.
When using pins it's usually best to define them with a Symbol then they can easily be changed in one line without hunting through the code for all occurances. It doesn't help all the time, especially if "pin=" and so on are used but does help in a lot of cases.
Write a TUTORIAL and post it somewhere safe and accessible.
Many people ranted on about Tutorials recently.
Sadly, like the tutorials themselves, the urge faded into history...
So, instead of bumping threads which carry 60% dross, cut'n'paste the good bits into a pretty PDF and plonk it somewhere.
The you can dump the b-anal bits and have a nice polished document which can be downloaded by punters.
Many people ranted on about Tutorials recently.
Sadly, like the tutorials themselves, the urge faded into history...
So, instead of bumping threads which carry 60% dross, cut'n'paste the good bits into a pretty PDF and plonk it somewhere.
The you can dump the b-anal bits and have a nice polished document which can be downloaded by punters.
Source translation
Every autumn (in Oz) I return to the PIC program for my underfloor heating controller (one of these years I might get it working well enough to leave it alone). This autumn I've been fantasising about what language features would reduce this from a seemingly intractable task, to simply a big one. In particular I think the two main things would be to be able to pass parameters to subroutines and to have local variables.
These two things have been a recurring theme in this thread, and others have discussed a few ways of dealing with them. What makes these methods difficult for people to use is that they require extreme discipline, and they also complicate the code to an extent -- ie. make it harder to read and write by putting in a lot of additional 'boilerplate'
I'm not here to request an actual change to the PICAXE BASIC language (although that would be great). Nor am I offering to actually build what I'm about to suggest (that would take me longer than finishing my damn heating controller). But I would like to share my musings and see what others think.
At first I was thinking that perhaps the way to make my code more readable and reusable would be to use parameters and local variables in my pseudo code and then sort out the stack-pushing and variable allocation when I put all the required routines into my main program. Really I would be acting like a compiler, or a source translator, translating from my pseudo code into PICAXE BASIC. But then I started to think about how this process could be automated...
What would be needed is to parse the pseudo code 'language', keep track of the scope of each variable so that we know when it is no longer needed and copy parameters and results to and from the stack (or block of variables, depending on the implementation). The simplest approach would be to use PICAXE BASIC with a few extra features, as this would make the rest of the translation trivial. Of course the generated code would not be as efficient or tidy as that produced directly by a programmer, but that's the trade-off for making it easier to write complex programs.
So far so good, but who here is a compiler writer? Not me. Well it turns out there are some very powerful tools around now to help programmers write their own compilers, or even source translators. Antlr (http://www.antlr.org/) is one such tool. Antlr can automate most of the drudgery of building a compiler, but it doesn't do everything for you. You need a representation of the syntax of the language (in EBNF), for example. But given that it can produce a parser and a lexer (which would be awesome if you knew what to do with those things).
Anyway, I've read enough to know it's pretty cool, but not something I realistically have enough time to learn how to use. Or rather, there would still be a lot of work to take the lexer, parser and/or abstract syntax tree and figure out how to emit PICAXE BASIC that manages all my variables for me.
So, does anybody share my dream, and are there any compiler writers out there?
Every autumn (in Oz) I return to the PIC program for my underfloor heating controller (one of these years I might get it working well enough to leave it alone). This autumn I've been fantasising about what language features would reduce this from a seemingly intractable task, to simply a big one. In particular I think the two main things would be to be able to pass parameters to subroutines and to have local variables.
These two things have been a recurring theme in this thread, and others have discussed a few ways of dealing with them. What makes these methods difficult for people to use is that they require extreme discipline, and they also complicate the code to an extent -- ie. make it harder to read and write by putting in a lot of additional 'boilerplate'
I'm not here to request an actual change to the PICAXE BASIC language (although that would be great). Nor am I offering to actually build what I'm about to suggest (that would take me longer than finishing my damn heating controller). But I would like to share my musings and see what others think.
At first I was thinking that perhaps the way to make my code more readable and reusable would be to use parameters and local variables in my pseudo code and then sort out the stack-pushing and variable allocation when I put all the required routines into my main program. Really I would be acting like a compiler, or a source translator, translating from my pseudo code into PICAXE BASIC. But then I started to think about how this process could be automated...
What would be needed is to parse the pseudo code 'language', keep track of the scope of each variable so that we know when it is no longer needed and copy parameters and results to and from the stack (or block of variables, depending on the implementation). The simplest approach would be to use PICAXE BASIC with a few extra features, as this would make the rest of the translation trivial. Of course the generated code would not be as efficient or tidy as that produced directly by a programmer, but that's the trade-off for making it easier to write complex programs.
So far so good, but who here is a compiler writer? Not me. Well it turns out there are some very powerful tools around now to help programmers write their own compilers, or even source translators. Antlr (http://www.antlr.org/) is one such tool. Antlr can automate most of the drudgery of building a compiler, but it doesn't do everything for you. You need a representation of the syntax of the language (in EBNF), for example. But given that it can produce a parser and a lexer (which would be awesome if you knew what to do with those things).
Anyway, I've read enough to know it's pretty cool, but not something I realistically have enough time to learn how to use. Or rather, there would still be a lot of work to take the lexer, parser and/or abstract syntax tree and figure out how to emit PICAXE BASIC that manages all my variables for me.
So, does anybody share my dream, and are there any compiler writers out there?
The features you mention are essential for a reusable and reliable language.
I notice that functions have just been added to MMbasic, they call it a "modern" feature which I suppose is technically true, although available in many languages for maybe 30 years.
As I guess there's no way to get Picaxe basic upgraded I think a "pre compiler" is a good idea. I'm not the one to write it though
One issue may be flash size, if this compiler blows out the code too much it would not be usable.
I notice that functions have just been added to MMbasic, they call it a "modern" feature which I suppose is technically true, although available in many languages for maybe 30 years.
As I guess there's no way to get Picaxe basic upgraded I think a "pre compiler" is a good idea. I'm not the one to write it though
One issue may be flash size, if this compiler blows out the code too much it would not be usable.
BeanieBots
Moderator
One quick and easy thing I do when running out of variables and want locals is to simply write two subroutines. One to push all (often just the first five or so) variables and another to pop them.
These get called at the start and end of each subroutine respectively.
Symbol defs can be placed anywhere in code, so each subroutine can have its own variables and documented variable use.
With a little discipline you end up with portable subroutines but with a slight speed overhead.
These get called at the start and end of each subroutine respectively.
Symbol defs can be placed anywhere in code, so each subroutine can have its own variables and documented variable use.
With a little discipline you end up with portable subroutines but with a slight speed overhead.
westaust55
Moderator
forum member mrburnette has also posted a scheme (similar to the concept mentioned by BeanieBots) with code example for saving variables to RAM not assigned to PICAXE variables and retrieving later. See here: http://www.picaxeforum.co.uk/showthread.php?19803-Expanding-PICAXE-named-variables-via-RAM-bank-switching
mrburnette
Senior Member
One man's heaven is another man's hell
Consider, when Microsoft drove DOS to Windows95, the implemented VM, virtual memory - what is commonly known as a swapfile. The architecture was necessary because the OS was object-oriented and the inheritance requirements required substantial increases in RAM over DOS.
BASIC is not tied to a monoptic concept, BASIC can be object oriented; just look at Microsoft's VB/VBA/.NET flavors. Unfortunately, nothing is free.
@burgo:
I do not wish to sound 'smug', I am not and actually am a rather humble creature who realizes that I have a tremendous amount of wasted space in my brain and allowed less time on earth than is necessary to completely fill the brain and connect the neurons. That being said, I have not encountered a problem with a program that is suitable for a PICAXE that has challenged me with confined resources. I generally complete my code and have significant code and variable space remaining. An NO, I am not that great of a coder; what I probably do differently is that I try and step away for what would be considered constraints in the uC and look for methods to extend and embellish the existing device - be it a 08M2 or a 20X2 (my favorite 2 devices.) Sometimes, this means sitting down with graph paper and drawing (I am a trained engineer, so I use as much graph paper as toilet paper) and working through the concepts and implementations BEFORE I go off coding. Another trick, is I keep the HP mini close by and use the Program Editor Simulator to test and refine bright sparks into working concepts and concepts into algorithms. Yea, algorithms generally require that you do your math homework... this is how Magic Morse was born.
So, I emphasize but I honestly do not think that RevEd could have produced a better device for the target market they serve. There is room for improvement, but like all things, it is an evolutionary process which must work within their business model.
I have used microprocessors starting with the 6502 and 6800 and assembly language and coding in a text editor. My, how the world has changed! But, in the golden old days of computing, an enormous amount of pride was taken for creating efficient and small code. When working with the uC and any language it is important to stay on track with the design goals and implementation toolkit. It may well be that your frustration is that you are a victim of your own scope-creep and every year are wanting to recreate the wheel. At some point, you may need to change the underlying/hosting hardware. If you have outgrown the PICAXE try two PICAXES! The PICAXE is not the only uC on the market. You may even outgrow the uC platform and may need to go to a microprocessor controller running a high level language - OR, find an old notebook and run Linux.
There is a very good reason that "programming" has been called an art.
Good luck,
- Ray
From Wikipedia:
Also, from Wikipedia:
Why so long between BASIC and Simula/Smalltalk? RAM... Random Access Memory is the enabler of language evolution. The concept of PUBLIC, PRIVATE, and STATIC, locks, semaphores, attributes are all RAM-hungry concepts. Consider a BASIC integer: In the PICAXE it is either a byte or a double-byte (word). Essentially, this is a basic idea that for the beginner in the language is often a stumbling block. But, in this forum, I have seen some very cleaver 32-bit routines which are not for the faint-of-heart. I will go out on a ledge and state that in-my-opinion, language advancement from concept to product is tied to RAM availabilities of the processor.
Consider, when Microsoft drove DOS to Windows95, the implemented VM, virtual memory - what is commonly known as a swapfile. The architecture was necessary because the OS was object-oriented and the inheritance requirements required substantial increases in RAM over DOS.
BASIC is not tied to a monoptic concept, BASIC can be object oriented; just look at Microsoft's VB/VBA/.NET flavors. Unfortunately, nothing is free.
@burgo:
I do not wish to sound 'smug', I am not and actually am a rather humble creature who realizes that I have a tremendous amount of wasted space in my brain and allowed less time on earth than is necessary to completely fill the brain and connect the neurons. That being said, I have not encountered a problem with a program that is suitable for a PICAXE that has challenged me with confined resources. I generally complete my code and have significant code and variable space remaining. An NO, I am not that great of a coder; what I probably do differently is that I try and step away for what would be considered constraints in the uC and look for methods to extend and embellish the existing device - be it a 08M2 or a 20X2 (my favorite 2 devices.) Sometimes, this means sitting down with graph paper and drawing (I am a trained engineer, so I use as much graph paper as toilet paper) and working through the concepts and implementations BEFORE I go off coding. Another trick, is I keep the HP mini close by and use the Program Editor Simulator to test and refine bright sparks into working concepts and concepts into algorithms. Yea, algorithms generally require that you do your math homework... this is how Magic Morse was born.
So, I emphasize but I honestly do not think that RevEd could have produced a better device for the target market they serve. There is room for improvement, but like all things, it is an evolutionary process which must work within their business model.
I have used microprocessors starting with the 6502 and 6800 and assembly language and coding in a text editor. My, how the world has changed! But, in the golden old days of computing, an enormous amount of pride was taken for creating efficient and small code. When working with the uC and any language it is important to stay on track with the design goals and implementation toolkit. It may well be that your frustration is that you are a victim of your own scope-creep and every year are wanting to recreate the wheel. At some point, you may need to change the underlying/hosting hardware. If you have outgrown the PICAXE try two PICAXES! The PICAXE is not the only uC on the market. You may even outgrow the uC platform and may need to go to a microprocessor controller running a high level language - OR, find an old notebook and run Linux.
There is a very good reason that "programming" has been called an art.
Good luck,
- Ray
I've included the push/pop within the sub. Always using a dedicated area of scratchpad (I'm using 28X2 and 40X2 chips) and planning the program flow to *not* re-enter the sub, I have sufficient space to push as many variables as needed. Most recently, I used this to read a block of data from FRAM (via I2C) and write it to a uM-FPU floating point chip (also via I2C). I think the new uM-FPU64 has I2C master capabilities, so the newer FPU may be able read the data directly from the FRAM - one more thing on my to do list...
John
mrburnette
Senior Member
I think, so I am... err, another post, me thinks. I can not argue that, it is hypothetical. But a preprocessor cannot make any particular PICAXE a superstar because the PICAXE has RevEd firmware in the chip. The chip architecture and limited resources can only provide so much Ump and there is nothing a preprocessor can do to enhance that fact.
The current "compiler" is a kind of preprocessor anyway and this capability could be enhanced (in a macro-kind of way) but to what avail? Opinion: The best preprocessor is the human brain.
Additionally, would a significant amount of effort on RevEd's part translate into expanded sales in their target market? Likely not. Hey, you and I and papof2 and even the whole of the forum may buy a few chips, but it will not recover the investment. Like it or not, we do not define the target market. Ever hear the joke about the manager that ran into engineering and screamed, "Marketing has a new slogan, they need a product!"
I'm beginning to wonder if I am the only person on the planet that does not have a problem with maintaining PICAXE code! I'm not all that prolific, but geewiz I do seem to have quiet a number of completed and partially completed projects that have PICAXE source code. But, the day that I do have an issue with keeping my old brain on the straight path, I'll move over to Arduino full time... or maybe PIC C... but there is also OTHER
What I really believe, seriously, is that "maintainability" can be done with the PICAXE current tools. I also believe that "maintainability" just is not on RevEd's radar at the moment and I cannot think of why it should be. It's BASIC for crying out loud.
- Ray
Last edited:
I should have made myself more clear.
Rev Ed already *has* a preprocessor, the symbol command is a rudimentary form.
I was thinking of adding C's macro expansion and conditional compilation, the #define, #define with arguments (i.e., #define square(x) (x*x)). # ifdef, #ifndef... and so on.
http://en.wikipedia.org/wiki/C_preprocessor
Rev Ed already *has* a preprocessor, the symbol command is a rudimentary form.
I was thinking of adding C's macro expansion and conditional compilation, the #define, #define with arguments (i.e., #define square(x) (x*x)). # ifdef, #ifndef... and so on.
http://en.wikipedia.org/wiki/C_preprocessor
mrburnette
Senior Member
Oh, it would not have mattered, I'm having one of my devil's advocate days!
I am in full agreement with the concept of adding such sweetness as macro expansion and more intelligent conditional compilation but such features enlarge the code base for RevEd and does nothing (significant) to enhance their target audience in education.
I am constantly amazed, seriously, at how well the PICAXE performs outside of education. It is a remarkable littl' device that is a true chameleon. I am a fanatic about recommending PICAXE to folks that want to get into uC and programming embedded systems. I try to drive business to Peter (Anderson) because I want to see him stay busy filling orders in his quasi-retirement.
But, I am a realist which is why I have a little pile of naked PICs and raw AVRs laying around on the anti-static mat. I (personally) would rather RevEd spend their time porting the firmware from the current PICs to the newer, more powerful chips that are coming down the Microchip production lines than reworking the current compiler. Just my priorities.
- Ray
Last edited:
Object Oriented languages, including OO BASIC, have their appeal, but they are not the be all and end all. If you want to see the epitome of BASIC, have a look at VAX BASIC from DEC. Both long gone now, but in my humble opinion there never was a better language created. Perhaps VMS was a great helper, but there was nothing you could not accomplish with VAX BASIC. I remember writing single programs in excess of 35K lines and they were very readable, maintainable, re-useable and so efficient that compiled, the only way to beat it was assembly. So, BASIC can be an awesome language, but I think REV ED would have to move to a real compiled language to make this happen. Then they need not burden the PIC with an entire interpreter, just a tiny loader.
Borland's Turbo Basic (DOS based, still available as Power Basic now that Borland is gone) compiled to native 80x86 code and ran incredibly fast. If Rev Ed should create something with similar abilities, they would probably have a fantastic commercial compiler.
Not sure I agree. Yes, it has deviated hither and yon, but the original topic was the using PICAXE BASIC to write maintainable code. Others have merely suggested alternative ways to skin that cat by changing the PICAXE BASIC programming model or looking at other alternatives. Open discussion in it's best and most rewarding form is organic and ... open.
After all, this is a log, and the original post still stands. Readers can take from the discussion what they will.
It's not like we started to talk about pea-shooters.
I remember it well.
There are already quite a few PIC compilers out there, so would another really be a commerial sucess ?
And as you can produce zillions of programmed PICs from one compiler, the quantity of compliers sold is small.
So the price is high.
So would schools buy it ?
Good for you
You probably started simple and worked your way up so that you were well aware of both your capabilities and the capabilities of the system. The reason I haven't finished this particular project yet is probably because I didn't. This is my first PIC project, and yes I probably bit off more than I could easily chew. But it really would be off-topic if we started discussing my own character flaws. Let's just say I'm not perfect, and I'm old enough to know it
BASIC was the very first language I learned (on the Commodore VIC 20 -- 3k RAM), and I wish I knew now what I knew then. Now I know dozens of languages and I guess I find it difficult being forced to go back to the very austere BASIC that is PICAXE BASIC.
Also note when I bumped this thread I said I really wasn't suggesting that RevEd make any changes to the language. I was actually hoping there might be a closet antlr user here in PIC land who would think, "That's I good idea. I could do that." But I guess those compiler types don't often mess around with hardware (sigh).
Anyway, my own options are to:
. reduce the scope of my project,
. shift most of the logic to my new Linux-based NAS,
. discipline myself to use one of the variable management schemes that have been mentioned here,
. write my own pre-compiler, or
. put the whole thing off for another year ;-)
Or some combination of the above.
Cheers,
Burgo.
mrburnette
Senior Member
@Burgo,
Suggestion, if you are not using code blocks in your source code for Program Editor which makes use of the { and } symbols, you should consider this since it will format and help you with documenting sections of code. The ability to collapse all sections and expand only the ones upon which you are working is very helpful to stay focused to the task-at-hand. Use #rem & #remend to insert notes and reminders. Also, the PE supports a split-screen view, so that helps too.
But, because PICAXE is interpreted BASIC, some of your very good suggestions would require the consumption of significant chip RAM and require major changes in firmware to support the concepts. This is not to say such concepts do not have value, but as you know you can migrate to a true compiler and language that supports libraries and variable encapsulation, variable passing to sub and functions, etc.
- Ray
Example of code blocks in use: blog
May I suggest that we are not discussing a microprocessor with external RAM & ROM, but a micro controller with internal RAM & EEPROM. It is true that there are compilers for uC that will provide public and private variables and true functions, but these are "real compilers.". The PICAXE compiler is not the same kind of compiler because it compiles the source to a pre-digested code that is later interpreted by the firmware in the PICAXE. Unfortunately, the firmware uses uC chip resources and provides a quasi-virtual environment for your code that is, your code is isolated and abstracted from the hardware.
Suggestion, if you are not using code blocks in your source code for Program Editor which makes use of the { and } symbols, you should consider this since it will format and help you with documenting sections of code. The ability to collapse all sections and expand only the ones upon which you are working is very helpful to stay focused to the task-at-hand. Use #rem & #remend to insert notes and reminders. Also, the PE supports a split-screen view, so that helps too.
But, because PICAXE is interpreted BASIC, some of your very good suggestions would require the consumption of significant chip RAM and require major changes in firmware to support the concepts. This is not to say such concepts do not have value, but as you know you can migrate to a true compiler and language that supports libraries and variable encapsulation, variable passing to sub and functions, etc.
- Ray
Example of code blocks in use: blog
Last edited:
Hi Ray,
I didn't know about { }, I will definitely be using that.
This wouldn't affect the firmware at all, although it could certainly increase the amount of RAM used over a hand-optimised solution. This is probably only something you would consider using on a large program, which necessarily means a larger RAM device. ie. 28X or 40X. As has been noted by others, the fact that these devices allow large programs is what makes them harder to program with PIC BASIC (at least for mortals).
By the way, I would be happy to use C (even though I never use C), but that would require me to get a PIC programmer AND completely redesign my hardware, which I really don't want to do, and let's face it, would kind of be admitting defeat ;-)
I didn't know about { }, I will definitely be using that.
What I was (vaguely) suggesting was a meta-language which would be converted into straight PICAXE BASIC by a source translator. The meta-language I suggested could, for simplicity, consist of a limited number of extensions to PICAXE BASIC.
This wouldn't affect the firmware at all, although it could certainly increase the amount of RAM used over a hand-optimised solution. This is probably only something you would consider using on a large program, which necessarily means a larger RAM device. ie. 28X or 40X. As has been noted by others, the fact that these devices allow large programs is what makes them harder to program with PIC BASIC (at least for mortals).
By the way, I would be happy to use C (even though I never use C), but that would require me to get a PIC programmer AND completely redesign my hardware, which I really don't want to do, and let's face it, would kind of be admitting defeat ;-)
mrburnette
Senior Member
Never give up!
OK, I'm beginning to get your drift, I think. Probably what you are wanting is macro expansion with a PE scripting capability. Most scripting languages have the ability to parse text strings and intrinsically have internal variables which permit the ability to store, transform, and manipulate strings. It is a tall order, but I understand your comments of a "pre-processor" better now.
Did you know that in PE, after you do a syntax check, you can double-click on the variables displayed in the right-hand Variables/Constants/Variables window and that PE will automatically move your through your code (search) on each double-click? It is not 'self-documenting' but useful. Perhaps an enhancement would be that if the programmer used code-tags "{}" then an option in PE would provide a subordinate display under the variables showing the modules? Perhaps, a reverse view, modules with a list of variables?
More than a pre-processor, I think you are driving me to think that you want a self-documenting report coming out of PE? You do not want to change the language and you do not want to change the firmware, you just want a more productive environment. Is this correct? If so, there was a thread going around a couple months back about PE enhancements... maybe you can get in on the tail-end.
- Ray
My next fun project - after I get my GPS -> USB superclock going, is to use something like this:
http://www-prima.inrialpes.fr/Ravi/cparse.html
And use it to generate RevEd BASIC code.
It will probably be horrible inefficent and slow on the PickAxe, but by golly, it will have subroutines with scope!
http://www-prima.inrialpes.fr/Ravi/cparse.html
And use it to generate RevEd BASIC code.
It will probably be horrible inefficent and slow on the PickAxe, but by golly, it will have subroutines with scope!
mrburnette
Senior Member
Unfortunately, the firmware "wiring" inside the PICAXE currently cannot support scoped variables. It is not a PE compiler problem but an architectural issue with limited resources and interpreted BASIC code. Undoubtedly, the day will come when uC components will have sufficient resources for RevEd to perform such magic, but we are not there yet with the current instruction set that is supported within the PICAXE firmware. RevEd "may" be able to pull off such magic with a minimal instruction set, but what fun would that be?
I seem to say this often, but here I go again, "It is all about the marketplace that RevEd caters and their business model for cash flow and sustainability..." If you want these features, they are available today with true compilers and naked uC.... some of the compilers are 'free' but most require a license to unlock their full potential. All have a steeper learning curve that PICAXE BASIC (IMO.) I say this from personal experience as I also do some projects around ATmel and raw PIC devices and have done assembly in the past.
- Ray
While the underlying PicAxe Basic won't have scoped variables, the higher level C that I am going to parse *will*. Much like the fact that machine code does not support scoped variables but any compiled language that runs on it *does*. (Exactly like it, in fact.)
Like I said, it ain't gonna be pretty, but it should work. I should get arrays out of it, too! But I will draw the line at floating point.
Like I said, it ain't gonna be pretty, but it should work. I should get arrays out of it, too! But I will draw the line at floating point.
Ha ha. I hate to let the machines beat me.
Hmm, not really. What I was suggesting is really very much like what KeithRB has suggested, except he is talking about converting C into RevEd BASIC. I was talking about allowing a few extra language features (think of it as a dialect of PIC BASIC) such as scoped variables and parameters to subroutines, which would be converted into standard RevEd BASIC by a source translator. This 'pre-processor' would work out how to allocate the required variables in the limited PIC memory, and take care of copying parameter values around. The result would be ordinary PICAXE BASIC code which has been generated by the source translator from your own code.
Of course you might run out of program space, or you might run out of variable space, but that might happen anyway, and it would leave the door open for improvements to the memory management strategy used by the source translator to balance those requirements.
Man, if we keep talking about this I might even have to try it. Does anybody have the EBNF for RevEd BASIC?