Picaxe Basic to C++

johndk

Senior Member
Here's a question for the more seasoned PicAxers:

Assuming a good working knowledge of C++, how difficult is it to convert a program from PicAxe Basic?

I'm thinking of doing this for a number of reasons, some of which are assumptions on my part because I have not yet tried to program a naked PIC.

1. I'm assuming there are no slot restrictions using native PIC coding. For larger programs, slots a pain to work with. But more importantly, they require a lot of repetitious code and so waste a lot of program space.
2. Loading PicAxe code is excruciatingly slow. And to make it worse, each slot has to be loaded individually. I'm assuming compiled code will load much quicker in the native format.
3. I eventually need to field-upgrade my firmware and would like to develop a way to do that via my LoRa connection to each processor. I don't believe that would be possible using PicAxe Basic. I'm hoping I can use the protected program area to make that possible in native mode.
4. I know I can run with less overhead, which would help me conserve battery. My battery drain is already very low, but I'd like to try for more.

I'd love to hear some insights from any who have tinkered with this.
 

bpowell

Senior Member
I dabble in raw PIC use as well as PICAXE...here are some of my inputs:

1: Slots - these don't exist on RAW PIC...this is a feature of PICAXE...you have the entire available flash memory to use as you please.
2: As for code loading speed...I can't really speak to this. typically, I use the In-Circuit Serial Programmer (ICSP) to flash a small serial bootloader onto a PIC, and then I use serial from there to upload application code...the serial transfer time can be fast or slow...but never so slow that it causes me grief...maybe 10 seconds to load a larger program.
3: As for OTA upgrades, you'll need to figure that out. You have the ability to reset your chip from application code...and that reset can trigger the bootloader. (You can call the bootloader specifically from application code as well...) but you'll then need to do the handshake and send code...it's tricky, you'll probably need to roll your own bootloader / application update code for that. I don't know of any "Protected program area" on the 8-bit PICs that I play with. There are some PICs (that I havent' played with) that have a separate flash section you can upload code to and then "switch over" to...it's interesting, but nothing I've played with yet.
4: Yes, there is less overhead, and you have all the control you want over power consumption, frequency, and which parts of the chip are in use or not.

It's a lot of fun, but it's a big learning curve as well...PICAXE takes care of a TON of stuff "under the hood" that you'll need to take care of yourself...but for me, it's a lot of fun.
 

hippy

Technical Support
Staff member
Converting syntax should be fairly straight forward. For example -

Code:
For b0 = 1 To 10
  Toggle C.0
  Pause 100
Next
Could become -
Code:
int main () {
  const char C_0 = 8;
  char b0; 
  for( b0 = 1; b0 <= 10; b0 = b0 + 1 ) {
    toggle(C_0);
    pause(100);
  };
  return 0;
}
The hard part is what's in those 'toggle' and 'pause' routines you may have to write yourself. It obviously gets more difficult with more complicated PICAXE commands.

The advantage of the PICAXE is all the work you may have to do yourself has already been done for you and can be expressed in simple to use commands. That's great for the type of people and projects the PICAXE is targeted at but it might not be such an advantage for much larger and more complicated programs.

Porting from PICAXE Basic to C++ or other language is possible but you may end up swapping one set of problems for others.
 

stan74

Senior Member
I and others want to convert c to basic and it's a bit very difficult...usually decimal point/floats stuff
 

pxgator

Senior Member
Hi johndk ,

I once had the same thoughts about converting PICAXE basic to C and I had much fun with MPLAB and a
PICkit 3 programmer. Please look at my previous posts..:). My C progs ran much faster and floating point
was very easy. However, about all I accomplished was having much fun and realizing that you basically must
'roll your own' functions and/or libraries. Also, I soon realized how much the PICAXE system does for you behind the scenes.
If you don't need blazing fast speed or extensive floating point arithmetic, I would advise to use the PICAXE Basic
system for what it was designed for. If you insist on using C/C++ then I would recommend the Ard** system
because of all the available libraries and docs.

Cheers to All

P.S. The PICAXE system is more often than not my first choice. With respect to what you're goals are
(field upgrades with LoRa) the ESP8266 and the Ard** sytem would be worth a look.
 
Last edited:

johndk

Senior Member
Thanks for the comments!

I DO appreciate the PicAxe system for it's rapid prototype capacity. I've been able to prototype my application AND get to know the capabilities of the 28x2 chip in the process. I like that chip a lot and am now finding that I'm bumping into some limits of PicAxe Basic (as detailed above). Honestly, my biggest hurtle is the limitations imposed by slots ... if there were a way around that ... or perhaps a PicAxe revision around the corner that addressed that ... OKAY, just dreaming.

I'm wondering if going the native route will be worth the work it's going to take. From the posts above, it doesn't sound TOO bad, but not an easy transition by any means. Of course, the challenge / fun part comes into play as well and serves to balance the equation a little more favorably.

In short, I'm looking at some other chips which require compiled code, and some of them have some appealing characteristics. But the PIC18F25K22 (28x2) does what I need it to do at a good price and with a low energy signature. So why not stick with it? If I go to another chip, I'd have just as much work translating my PicAxe Basic to native code anyway. So I'm inclined to try give native PIC a go.

Any other tips or suggestions would be welcome, especially from those who have done some serious dabbling.

John
 

pxgator

Senior Member
Hi again johndk ,

It might be good too stick with the PICAXE system for the time being. The other alternatives are pretty good but the support
is not so good compared to the PICAXE system. If you can post your specific problems with PICAXE code there are many experts
on this forum (I'M NOT ONE OF THEM!!) but Hippy, AllyCat, Technical,etc.,etc., can usually provide a solution to you're problem.
This forum is by far the most friendliest and informative forum that I've ever been a member of. However, as a side note, I'm a retired
old geezer that made a good living programming PLC's and Micros with C and C++. So I'm a bit partial to that type of programming.
But since working with the PICAXE Basic system I've been very impressed with how much code that will be interpreted has been crammed
into such a small code space with the PICAXE system. The MPLAB C,C++,and Assembler system is a lot of fun, (if you like puzzles) but
compared to the PICAXE Basic PE..6, MPLAB is a convoluted mess.

Good luck and Cheers to All from the Colonies....:)

PE..6 or something similar that could do compiled C/C++ and/or Basic would be like a dream come true..!!
 
Last edited:

bpowell

Senior Member
You could also check out Great Cow Basic...I hear that mentioned a bit...it's a basic language that compiles down to native PIC code...so the benefits of Basic language, with the benefits of native-running code.

I haven't played with it myself, but it sounds promising.
 

PhilHornby

Senior Member
I decided to have (another) go with raw Pics - about a year ago now, but I've not made much progress :(

I purchased a Microchip 'Curiosity' Development Board (there's lots of variants; mine is for 8,14 & 20 pins pics), but you might be more tempted by the "HPC" (high pin count) version. I also bought a Pickit 2 clone off eBay. I chose the PICS that are the basis of the 08M2 and 14M2 to experiment with.

I never really left "GO" - getting tangled up in creating a practical way to download programs to the things. Low-voltage ICSP used up the pins and 'high' voltage seemed to require me to press "Reset" buttons and disconnect things and still have no pins left! ... I ended up using ZIF sockets to transfer the PIC between programmer and breadboard ... a complete nuisance (and where I'd been twenty+ years ago, when I last dabbled).

The 'bootloader' approach sounds like the nearest thing to the Picaxe methodology and there are loads to choose from. Getting one working is another matter though; the best I've achieved to date, is getting one to load an initial program - but I could never re-invoke it to do a second one :( .

As for C++ ... my view, is don't do it, unless you really, really have to (it's one of the few programming languages I've actually been on a course for - but I never got on with it.) If the (free) Great Cow Basic can't do what you want, there seem to be lots of alternatives (at a cost). $249 for mikroBasic Pro might be justified, if you're doing this commercially, for example. (Just something I found on google - I know nothing about it!)
 

tmfkam

Senior Member
I'm another fan of GCB. (Great Cow Basic) The IDE is easy to understand, the language is a quite close relative of PicAxe Basic and it produces standard MicroChip compatible .hex files. For programming the processors I have a (cheap clone of) PicKit 3. GCB can automate the programming of the PIC so that it is possible to select one button which compiles and downloads the active Basic file 'automagically' in much the same way as PicAxe's programming editor does. I can't use this due to me running GCB on my Mac under WINE but it is possible (and to my simple thought process - better) to use the 'IPE' (Integrated Programming Environment) supplied as part of MpLAB to program the .hex file into the processor.

I use both PicAxe and GCB. For ultimate code execution speed it's GCB. For development speed it's PicAxe.
 

geoff07

Senior Member
It is only by trying to program a PIC in C++ that you realise just how powerful Picaxe Basic is. Clearly it has limitations. But you don't have to master a 500-page Microchip manual, and set up all those peripheral registers. You can get a complex real-time system in operation very quickly, and understand it enough to maintain it in future. I have programmed in quite a few languages over nearly 50 years since I was 16, and for embedded code PB gets my vote.
 

Technoman

Senior Member
Hi,

Doing some search about languages, I came across an interesting concept : editing in a high level language then using a cross compiler for a specific platform (C++, Python, ...). Although, Basic is not yet a target. It's name : Haxe.
https://haxe.org/#learn-more
 

stan74

Senior Member
I and others would like c to basic as everything has been done in c and the same stuff not in basic. Think adafruit or ebay hardware and arduino github. Examples in c or rpi python but no basic.
 

PhilHornby

Senior Member
Doing some search about languages, I came across an interesting concept : editing in a high level language then using a cross compiler for a specific platform (C++, Python, ...).
Cross-compilers have been around for quite a while, but Haxe seem to be attempting to lock you into their infrastructure (or am I just being a cynic?)

Decades ago, I evaluated some software that converted PDP-11 assembler to VAX assembler. Although it handled the instruction set ok, it had no idea about migrating Operating System calls from one to the other (RSX11M Directives -> VAX/VMS System Services). In those days, that particular problem was addressed by the use of "Middleware" (a term whose meaning has changed somewhat over the years) - which sat between 'application' and Operating System, to provide a consistent interface. An API is probably what you'd call it these days. What we need is an "HPI" ... a Hardware Programming Interface, that is consistent across all Microcontrollers :)

On a different subject, Microchip are having a sale of some of their Development Hardware: http://www.microchipdirect.com/product/DevToolDeals
 

hippy

Technical Support
Staff member
Cross-platform to me means developing on one platform to create something which runs on a different platform. For example our AXEpad which is developed under Windows but creates executables which run under Linux and Mac.

A cross-compiler is the tool for that; takes in source code and churns out an executable for the platform that executable runs on, rather then the platform the compiler itself is being run on. Our development tools which create AXEpad executables effectively have a native compiler which runs on Windows and generates a Windows executable, it also has two cross-compilers which run on Windows but produce Linux and Mac executables.

Converting one programming language to another is really a separate function to both of those and I wouldn't call it specifically cross-platform nor cross-compilation. Though I suppose there will be cases where the source may be changed to be more appropriate for a specific platform than another. For example you can't usually use the exact same source code for creating a Windows application as one would need for an Android or IOS app.

For turning C into PICAXE Basic, or PICAXE Basic into C, I'd call that translation, then there's the step of compiling or cross-compiling what had been produced by that translation. Though once one rolls it all into one I'm not sure what one calls it and whatever one does it probably doesn't really matter.

PE6 does do translation; it translates Blocky and Flowcharts into Basic then compiles that for the PICAXE. Perhaps technically cross-compiles seeing as it runs on Windows and the output only actually runs on a PICAXE - though simulation within PE6 clouds the issue there!

PICAXE Basic could be converted to C, and possibly fairly easily, but it's no good converting "SERVO B.1,150" to "Servo(OUT_B1.150);" if whatever that C is for doesn't understand nor implement "Servo()" as the PICAXE intended. This is where it gets far more complicated in translating from one language to another. It's not so much the language itself, but what else is behind it or relates to the target platform.

It's not "converting to C" it's "converting to C for a specific implementation of C on a particular platform with particular capabilities". That's not always so hard for desktop computers where all use a screen and keyboard, have well defined ways to get things onto the screen and common peripherals, but it's more difficult with microcontroller systems where they can be very different.
 
Top