Picaxe vs. Arduino Support

[sailgene]

I'm sure I'm going to catch he** for this but I'll discuss it anyway. I've been a Picaxe user for many years. I love the system and believe it is the easiest programming to learn and most reasonably priced programmable system. BUT, if anyone googles anything concerning programming questions, Auduino is always the go-to system. And when referencing the how-to pdf documents for Picaxe, all of the information is relatively old or lacking in addressing new hardware.

My frustration hit the limit when trying to employ an electronic compass module for my ROV. The most current module, the CMPS14, has almost no support from Picaxe. The help forums have very few discussions with no specifics on such things as "calibration". I could get the compass to provide directions but calibration was needed. The documentation for the compass gets way too confusing for my small brain in trying to communicate bytes to the chip. When I went to Devantech to see if they could assist, their only help was to refer me to Arduino programming. The Picaxe manual on interfacing various circuits has no topics on compasses. As a builder of any robotic device, I would think that directional feedback would be a reasonable consideration.

So anyway, I'm just venting. I feel like the Picaxe system should be pushed harder as an excellent choice for hobbyists like myself but in so doing, provide more up-to-date information to keep up with the latest modules. If I'm off-base here, I welcome any constructive feedback. Perhaps there is nothing in the forum discussions because everyone has found it a simple procedure to calibrate their compass. Again, I'm not the sharpest tack in the box but I sure would like to see more work done in the manuals to keep up to date and provide sample programming for assistance. Thanks. Gene Darby

 

[hippy]

I suspect lack of discussion of the CMPS4 reflects it being a fairly expensive module which few PICAXE users have used. Lack of details about calibration perhaps because the device arrives factory calibrated, was suitable 'as is' for those who have used it., or is a simpler task than it may at first appear

One of the reasons the CMPS4 won't be documented in our manuals is that we can't cover everything, and especially if we haven't used it ourselves. We cover the common stuff a PICAXE user will likely be using but not more esoteric, exotic or less used modules - This forum serves as the documentation for those, but may be limited if a module has been rarely used.

But the advantage of this forum is one is entirely welcome to ask "How do I ... ?" and it's rare not to get any help or guidance, often from experts and those who have actually done it. Even if no one has, there will usually be a willingness to help with doing it, interpreting manuals and datasheets, even providing code tailored to the user's needs.

The CMPS4 appears to offer Serial and I2C modes with I2C probably being the preferred mode for PICAXE use. Though I have never used it the datasheet seemed detailed enough to me, and I believe I have written some code which did work for reading CMPS4 data for other PICAXE users, so am sure myself and the PICAXE community can help you figure it out.

Your issue appears to be with calibration so I'll have a deeper read of the dasheet and report back tomorrow if no one's beaten me to it.

https://www.robot-electronics.co.uk/files/cmps14.pdf

 

[Goeytex]

There are hundreds if not thousands of different devices ( chips, displays, sensors, etc) that can interface with a microcontroller. I think it may be a bit unreasonable to expect the Picaxe folks to cover everything in detail. With Picaxe (and many others) sometimes you have to "roll-your-own", by getting a datasheet and trying stuff.

If you can't figure it out after at least giving it a shot, there is usually someone here that is willing to help.

 

[sailgene]

Thank you both for your answers. Looks like the price of these modules has increased about two-fold since I purchased mine. And "yes", I have seen Hippy's assistance in coding to get feedback from the device. But again, no one seems interested in Configuration and I'm surprised others have had good feedback without having to perform a configuration. The data sheet is good about addressing the chip but unclear to my untrained self in getting the configuration started. As for covering everything, point well taken. But having nothing at all on any compass seems a bit lacking. Thanks again and I will stand by for any help you guys can come up with. Thanks!

 

[hippy]

But again, no one seems interested in Configuration and I'm surprised others have had good feedback without having to perform a configuration.

Before getting into calibrating the chip it's worth asking why you think it needs calibrating, what directional issues you are running into.

If it's that your ROV indicates it is pointing East when it is actually pointing North, or similar, because of how the module is mounted perhaps, and you want to calibrate it so it indicates it is pointing North, that is likely solvable without having to calibrate the chip itself.

But having nothing at all on any compass seems a bit lacking.

I am sure everyone who wants information we don't have would say the same, but reality is we can't cover everything, and there's not been much call for such information.

 

[steliosm]

This is indeed the case for some 'exotic' peripherals. Every time I need to get some details about a module I usually only find information on how to interface it with an Arduino. It's not bad, because you still get insights on what is happening under the hood. This could also be the case that more people have been introduced to Arduino instead of Picaxe. Big electronic hobby companies have also helped push the Arduino forward, making things even more simple by developing hardware for Arduino, releasing software libraries and also helping new people into the hobby through tutorials, youtube videos, etc. It's was a huge effort and it took a lot of time and money.

As for the support, my feeling is that you get more solid responses from the Picaxe forum, since many of the forum members are professionally involved with electronics or used to be involved, than from the Arduino forum which most of the time the response is just a guess.

Have of the fun (pain) of the hobby is to figure out things on your own. You will still need a few tools to assist you on this, like a oscilloscope and a digital logic probe. You can get the first from the Picaxe store in a fairly cheap price, and the second from a china-based eshop, also in a cheap price. Software is also free for both tools. It will help you debug your circuits easier.

 

[oracacle]

Picaxe was primarily designed as an educational tool within the UK. It is also closed source making it harder to work with.

Arduino was designed to be open source and fairly easy to use. It's multi national meaning there are more people likely to use, meaning exotic parts are more likely to be used with them, and libraries written to make life easier.
The open source nature also means that it is used with other micro controllers too, esp, attiny, and teensy spring to mind. The forum is active and mostly helpful with a few die hards who do their best not to help.

Also the C language is fast meaning you run into fewer problems with some hardware, WS2812 LEDs spring to mind.

 

[AllyCat]

Hi,

The most current module, the CMPS14, has almost no support from Picaxe.

IMHO it's asking for trouble to choose the "latest and greatest" (apparently this is the "5th generation") of almost any product, but particularly for PICaxe where one of its most useful strengths is its "Legacy" support: Program Code and Hardware from 10 or even 20 years ago will probably run unchanged - try that with an Ard**** )! Also, I see that the price of the CMPS14 is around ten times the price of a PICaxe, so I would expect most support from the (Breakout Board) designer and/or seller. There must be a much larger range of different "Slave" target peripheral devices (even just limited to the I2C Bus) compared with the number of "Host" microcontroller architectures or Languages, so one would expect support from the sensor not the controller manufacturer.

To be fair, one seller does link to various support documents, including to PICaxe Code ! That code appears to be for the "previous" device (CMPS12) with the 18X or 20M, which are relatively old PICaxes (but the code will probably still run on all the current PICaxes). It appears that the CMPS12/14 both use Bosch chips but I haven't examined how similar is their interface data format . However, I would hope the differences are not as great as I discovered when writing code for the BMP180/BMP280/BME280 family of Bosch sensors. After that, I'm afraid my present recommendation for the BME280 (which I believe has now been "upgraded" again) is to "Use a different Humidity sensor, such as the SHT3x from Sensirion".

Cheers, Alan.

 

[hippy]

Picaxe was primarily designed as an educational tool within the UK. It is also closed source making it harder to work with.

I don't think we would agree that being closed source makes the PICAXE harder to work with.

The issue is usually that no one has written whatever code may be needed for a particular part where someone might have done so for other microcontrollers, but PICAXE not being open source doesn't prevent that code being written if it's an I2C, SPI or serial device. It's usually only where high-speed interfacing is required that it might not support something.

I don't foresee any issues in getting what's needed to work with the PICAXE other than the toil of figuring out what has to be done in what order and maybe having to read between the lines in the datasheet..

 

[sailgene]

I really appreciate everyone's responses and all seem reasonable. I tried to purchase an older model of the CMPS as they seemed easier to program but alas, I can't find them. I must agree that half or maybe 90% of the fun IS trying to figure out the correct coding. It's a satisfying feeling to finally get something to work right. And this forum has been a great assist. I've tried to get a handle on Arduino code but it's a bit confusing for my small brain.

To Hippy's question about calibrating, I got the chip to return headings (both 8 and 16 bit options). When lined up with magnetic north, the chip would read about 320 degrees. (Note: I checked for magnetic interference with a "real" compass just to eliminate that possibility). When I tried factoring 40 degrees to the computed output, it would give me 360 at magnetic north but then the same factoring would provide crazy headings when pointed elsewhere (like 44 degrees output when pointed south). One problem is that it will output 360 degrees at approximately 45 degrees magnetic. And so factoring any math to correct one heading will not work in another heading. The "deviation" changes from one heading to another.

I will create a new post titled "Calibrating CMPS14" to see if anyone has successfully figured this out with Picaxe. Thank you all for your comments. Again, I want Picaxe to compete with Arduino but maybe that was never a goal of the creators.

 

[hippy]

The "deviation" changes from one heading to another.

Could that be an issue with the way you are doing your adjustment ? It would be worth posting your code, stating what the raw values are for N, S, E and W.

But, yes, it does sound like it might require calibration.

Obviously untested because I don't have a CMPS4 to test with, but this seems like it should enable background self calibration of the compass which might improve things -

HI2cOut $00, ($98) : Pause 20
HI2cOut $00, ($95) : Pause 20
HI2cOut $00, ($99) : Pause 20
HI2cOut $00, ($91)

Not sure if you need to tilt and waggle things about before it becomes calibrated.

 

[tmfkam]

Also the C language is fast meaning you run into fewer problems with some hardware, WS2812 LEDs spring to mind.

The C language itself may not always be quicker. For the Arduino your typed instructions are compiled before being downloaded to the target processor. These compiled instructions run at the native speed of the processor. For PicAxe your typed instructions are downloaded to the target processor. These instructions are then individually translated on the processor before being executed. This is slower than Arduino, not because of differences between C or BASIC, but the design approach taken by Rev-Ed when creating PicAxe. Compiled BASIC can be just as fast as compiled C.

 

[oracacle]

Of course it's compiled. Most will run some form of machines code. Looking in the right places you can get binaries of pre compiled code. And in some cases you can actually choose the compile type, small, fast or normal. If you look at teensy 4.x or can be programmed with teensyduino which essentially allows you to programme the arm cortex processor with Arduino C, compiling to fast code results in more space behind taken by comparison to the the small.

This again speaks to the open source nature of Arduino, I can test a programme on say an Uno find that is not fast enough and switch to a esp32 or teensy 3.6/4.0. often without even having to make any changes to the code itself. Granted I'm not going to be able to run some of them really high speed stuff from teensy on any of the Arduino line. These aren't even the same chip manufacturers and it just works with little to no "that won't work on this chip". People being able to make it work with just about any controller results in wider support over a wide demographic using lots of different components, as you can imagine you then increase the likelihood that an obscure sensor has already been used by someone else.

This open source model is why Arduino has become so popular. Back when I first started, Arduino didn't exist and your had to make do. There were also less obscure sensors around.

 

[papaof2]

In the days of DOS, BASIC code well written and compiled with PowerBasic might parallel Borland's Turbo C in processing speed (Borland had some of the fastest products).

In the 90's I was given the project of getting a 386-25 PC to run "faster" - without spending any actual money (my time was already budgeted for the year, so zero direct cost). The PC linked a UNIX machine with an IBM machine (3270 card? It's been a long time.) using interpreted Microsoft BASIC code someone else had written possibly a decade or more earlier. No one at the original design office would admit to ever seeing or hearing anything about that kludge or the libraries used for the C code that ran the IBM interface so I had one zero equipment cost option: make the BASIC faster.
The process read formatted text emails on the UNIX system and parsed that text into the format the IBM machine expected, thereby replacing the person(s) who once read the email and did manual input to an IBM terminal (24/7 availability and no personnel costs always improve the corporate bottom line). When the system was put together, there were maybe 20-30 emails a day (service orders). When it became my problem, there were hundreds of emails each day and the "Check the mail every 15 minutes" process often ran well into (sometimes over) the next 15 minute interval - especially when a lot of requests got stacked up over a weekend or holiday, which definitely hurt the numbers for the people responsible for handling those service orders when they were measured on speed of response to the requests. If a block emails sat on the UNIX machine for an hour, the response time went way up and the speed went down.
The magic of compiled code worked and the tweaked and compiled version of the original BASIC code ran the busiest blocks of that process in no more than 8 minutes. My "improved" version performed well until the promised replacement for that UNIX to PC to IBM kludge was actually up and running.

If you want processing speed, you either learn assembler for the processor you're using (PDP-11 assembly language, anyone?) or you find the compiler for your language of choice that produces the fastest code. MicroChip sells thousands (millions?) of their microcontrollers to designers looking for the best/cheapest/fastest option for some product (i.e., PICAXE). I'll guess that much of the coding is done in C, using the MPLAB products but there may be parts done in assembly for that last possible bit of speed.

 

[hippy]

The C language itself may not always be quicker.

It is probably more correct that code written in C is not always significantly quicker than code written for PICAXE.

If one were to set a output pin the PICAXE 'HIGH C.1" is equivalent to 'digitalWrite(C1, 1);'. Both will call internal library code which executes at native execution speeds so, if one were using the same chip for both it is likely the library code would be the same, its execution time the same or comparable.

Because the PICAXE stores its call to that library code as tokens these have to be decoded before the code is invoked, where compiled C will generate a natively compiled call. This means there is an interpreter overhead for PICAXE in decoding those tokens but usually only in the order of microseconds.

By using tokens less memory is used than compiled C code will occupy so it is ideal for more constrained, smaller and often cheaper chips. That gain does however come with a slight reduction in overall execution speed. The execution time of the code which actually does what is wanted will often be similar in either case when native instruction times are the same for each.

This open source model is why Arduino has become so popular.

I disagree. Arduino became popular because someone finally got round to producing an IDE which was simple to use and defined a standardised set of high-level code commands which can be used; pretty much as PICAXE has. That others then provided implementations for other microcontrollers than the original used is why it has become popular, much how VS Code has become popular with programmers regardless of which programming language or architectures they are using.

It is correct to say that being open source allowed people to develop their implementations and allowed Arduino to move forward, but not being open source hasn't really held the PICAXE back as the goal has never been to cater for anything but PICAXE chips.

"Arduino" isn't so much a product these days as a simple but universal IDE used to develop for a variety of microcontrollers using a standardised set of high-level C language commands, though there are officially branded Arduino microcontroller boards available.

Arduino's popularity arises from hiding the implementation of the high-level libraries from users; just as PICAXE Basic does. It also allows users to add library and interfacing code to assist other users but so too does PICAXE. Any user can produce PICAXE code to interface to something or do something and share that with the community. In that respect PICAXE is just as much open source as any other system is. Using such code sometimes isn't as easy in Basic as it is in C but that's a matter of choosing Basic over C.

 

[oracacle]

I hate to tell you this, you can read every single library that you use with Arduino, that combined with the Git repositories means that every aspect can be seen and nothing hidden. That's the idea of open source, heck there are even tutorials to tell how to modify them.
If you really want you can see the code compiled into hex. I think you can get the assembly language out as well.

I started with picaxe and moved to Arduino. I currently have 4 projects that it would either cost more (think moving to apa102 Vs ws2812 at the 300led range) to do with picaxe or would need to jump through hoops for - say the steinhart-hart equation that every 3d printer running in an Arduino mega does multiple times a second on at least 2 thermistors. Then apply a PID to that for controlling the temperature. Control at least 4 stepper motors with PID too. Oh and still have a reasonable responsive user interface and be able to send and recieve serial data... Yeah the code and libraries to do that, is all open source too.

These are things that I have been waiting for picaxe to do, it doesn't even support double word. I can use the background timer and not have any issues for 52 days using an unsigned long and a millisecond increment. The same thing in picaxe, less than 2 seconds! Then don't get me started on interrupts... The annoying thing is, most of this can be resolved at compile time.

 

[hippy]

I hate to tell you this, you can read every single library that you use with Arduino, that combined with the Git repositories means that every aspect can be seen and nothing hidden.

I am well aware of what open source means but most users don't have a need to know, let alone update, what goes on in 'internal firmware' libraries. That we don't publish our firmware code, that only we can change that, isn't an issue for most users.

When it comes to interfacing libraries, code written to use sensors and what-not, that's just as open for PICAXE; we have the main forum plus Code Snippets and other Project sections for people to post their code to, plus there's interfacing code published on other sites and elsewhere.

Sure, the PICAXE won't do WS2812, may not do things which require speed, data sizes, or calculations beyond what it was intended to do, but we have never denied that, have always acknowledged there are some tasks a PICAXE isn't good for, won't be good for, that advanced stuff may require jumping through hoops.

But that doesn't mean the PICAXE isn't good at doing what it's intended for, amongst the audience it was intended for.

 

[kranenborg]

...
But that doesn't mean the PICAXE isn't good at doing what it's intended for, amongst the audience it was intended for.

As a tribute to that: I have worked with several microcontroller platforms by now, but the one that I return to most often is still ... Picaxe, as it enables quick prototyping for small and moderate size projects, using this forum to get and bring knowlegde. I am actually planning in 2023 to port the ZBASIC implementation (an Arduino-like system based on Visual Basic) of my MahJong Calculator to Picaxe because of cost and availability reasons .

/Jurjen

 

[Flenser]

My 2 cents worth

most users don't have a need to know, let alone update, what goes on in 'internal firmware' libraries

My opinion on this is similar to Hippy's. The Arduino has a huge number of users and my understanding is that a large part of it's popularity is due to the big ecosystem of libraries that are available to the non-technical user and how easy the libraries are to use.
I'd have thought that only a very small portion of those users ever want to, or need to, get into the internals of the library code and so this wouldn't be a major contributor to it's popularity.

Another point I wanted to comment on is any comparison between the open source nature of Arduino and the closed source nature of PICAXE.

• I don't think that comparing the open source nature of the libraries with the closed source PICAXE firmware is fair. I feel that a better comparison would be between the Arduino C/C++ compiler and the PICAXE firmware.
• The AVRGCC complier used by Arduino is open-source however as it implements a particular version of the C standard I suspect that you are probably as likely to get significant changes to the avr-gcc compiler as you are to get significant changes to the PICAXE firmware and so the two platforms are very similar the that respect. Is anyone aware of any major changes that have been made to the avr-gcc compiler recently?
• Even if all the library code published by 3rd parties for Arduino is open-source so is a lot of the code published by 3rd parties for the PICAXE so the two platforms are also very similar in this respect.

So anyway, I'm just venting. I feel like the Picaxe system should ... provide more up-to-date information to keep up with the latest modules.
The most current module, the CMPS14, has almost no support from Picaxe.
The Picaxe manual on interfacing various circuits has no topics on compasses.

Sailgene, I did some research into this.

There is a list of the official Arduino libraries here: https://www.arduino.cc/reference/en/libraries/
There are libraries for the Arduino boards and the MKR modules that are made by the Arduino LCC company.
There are a set of librarys for features that we might consider core:

• SPI, I2C and serial communications
• servos and stepper motors
• reading and writing to EEPROMs and SD cards
• LCD and TFT displays
• audio sampling and playback
• using the USB features of the Arduino boards.

There are no libraries or documentation for modules made by other companies.
Arduino make the MKR IMU Shield which has the 9DoF BNO080 IMU chip and they provide library for their shield.

This other Arduino page lists official and user-contributed librares for sensors:

Sensors - Arduino Reference

The Arduino programming language Reference, organized into Functions, Variable and Constant, and Structure keywords.

www.arduino.cc

• It has libraries for the Arduino MKR IMU shield
• It has libraries for Adafruit & BohleBots modules with the BNO055 & BNO08x IMU chips.
• It does not list a library for any of the CMPS01x modules

The PICAXE firmware also provides a set of core procedures:

• SPI, I2C, serial, One-Wire, UNI/O and IR communications
• servos
• Using ADC, DAC and PWM hardware (and software PWM)
• Using an attached keyboard
• Reading a DS18B20 digital temperature sensor
• Reading and writing Manchester encoded radio data
• Reading touch sensors

Plus Rev-Ed provide documentation in the PICAXE manuals on how to use a wider list of external components, like seven segment displays, LCDs, solenoids, pots & LDRs and thermistors.
Rev-Ed provide no documentation for modules made by other companies.
Rev-Ed provide no documentation for the 9DoF BNO080 IMU chip or the CMPS014 module.

Sparkfun do list several 9DoF IMU modules, including one based on the BNO080 IMU chip.
Sparkfun provide Arduino libraries for the IMU modules that they make.
Sparkfun provide no documentation or libraries for modules made by other companies and nothing for the CMPS014 module.

In summary:

• Arduino LCC, Rev-Ed and Sparkfun are all exactly the same in that they only write documentation and/or libraries for the modules that they make. They do not write documentation or libraries for modules made by other companies.
• Arduino and Rev-Ed do each provide a different set of built-in features. This is not surprising considering the different markets that they intend to service.