Is PICAXE support for Mac officially dead?

pleiser

Senior Member
It's been a few years since MacOS Catalina came out, dropping support for apps that hadn't been updated in the last decade and change to support 64 bit Intel processors. When this happened, we were assured here by @Technical that, although AxePad is discontinued, it's replacement, Blockly, would be updated "when required" to support 64 bit devices, along with the command line compilers needed to upload code to the PICAXE, regardless of where it's written.

It's been a year and a half since then, another new version of MacOS has come out, Apple's announced and released a new (and amazingly fast) chip architecture, which will, thanks to the effort of apple's software team, continue to support 64 bit intel apps for now (and probably 5-ish more years, if I had to guess). Meanwhile, as far as I can find, there's not been a single word since on the matter from PICAXE's software team.

Has Mac support been entirely abandoned? If not, when can we expect the updated compilers to be released to allow us to use a version of MacOS that's not 2 years old? I just tested both Blockly and the command line compilers (both freshly downloaded directly from the website), and neither of them is functional on MacOS Catalina or Big Sur. The compilers give the error "Bad CPU", and Blockly hangs forever when you try to run a syntax check or upload.

Because of my recommendation, my College's robotics club recently bought around 10 Versabots from you guys, but I'm starting to regret it as I'm realizing you still haven't updated your software to support any computers bought or updated in the last 2 years. Also, it's clear my class isn't the only one affected by this issue, as demonstrated by this thread that never even received an official response. Is there any good news in the pipeline, or should I give up on waiting for an update?
 
I guess that the "cost" V "return" equation for Rev.Ed is not balanced in favour of MacAxePad. Most people are running Windows, those not may be in such a minority that it simply isn't worth the effort of supporting macOS?

I had problems this week trying to run MacAxePad to update a legacy project. I am still running Mojave which does run 32bit apps (I have not upgraded my older iMac yet). I had to install the Axe027 drivers as these had been lost. I updated the code once the drivers had been installed. I then needed to further update the code the next day. I could not get Axe027 to work. I kept getting a "device does not exist" error. I installed, re-installed, switched off, on. Still couldn't get it to work. Noticed the drivers package was some years old. Looked on the FTDI site and found a much newer driver which did say it fixed the specific problem of drivers disappearing. Installed that and finally all worked.
 
The development system axepad was written in is no longer supported on the latest versions of Mac OS, so there will be no new macaxepad releases (windows and linux axepad are still working fine). The very small number of PICAXE users that use a Mac does not justify the investment required for a new editor when other options are readily available.

You have not stated which version of Blockly you are using - for Mac we recommend using the online version at www.picaxecloud.com and the downloader app https://picaxe.com/software/drivers/picaxe-programmer-app/

Alternately use the mac Blockly app and enable the online compile option, however most educational Mac users are simply using the Blockly cloud online version these days.
 
If the compilers were compiled for 64bit macOS, another editor could be used to write PicAxe code?

I know I'm very much in a minority here, but it was the cross compatibility of Windows and Mac that led me to introduce PicAxe to the Students at the Higher Education College where I worked. A real shame that has been lost.

Being old school, for me, online compilers are a definite no. And for the College it is another thing to battle with the dreaded IT department over allowing a website to control a classroom PC.
 
There is no 'website controlling a classroom PC', the online compilation process uses common web technology no different to browsing a website. Thiis is quite deliberate, to support many different platforms including macs and Chromebook - which are now far more commonly used than Macs in many schools.

Please do try it out - the actual download via the AXE027 cable is controlled by the programmer app on the local machine (linked above), not the website.
 
Thanks for the response @Technical. I know I'm in the minority, but I suspect your online system will be insufficient for me and my peers. Is there an API available to directly access the online compiler? If not, that would be very, very helpful, if it could be implemented.

If not, the features my college need to have access to include the ability to edit multiple files simultaneously, use #include, and push and pull changes through git.

I haven't yet tried this online form of Blockly, but based on the downloadable version you offer, I can't imagine it has any of these features available.

Even if there is an API, it's still far from ideal, given that (ironically, I know), the computer science and mechatronics building at my college is notorious for having an unreliable network connection, so the ability to compile for PICAXE locally would be very advantageous to needing to send it off to a server every time.

Also, in your response to my previous thread on this matter, you said there was an updated MacOS version of the compiler you were in the process of testing. Even if it's not as thoroughly tested, and still in a "beta" form, if you could release that (with plenty of disclaimers that it's not an official release, may behave unpredictably, etc), that would be sufficient to solve my issue, along with other power-users using recent versions of MacOS.

EDIT: I just tried checking the "online compile" box in the downloadable version of Blockly, then running a syntax check on an empty, default program, to be greeted with the response "The online compile service is not available. Please try again later", as a great example of why, even when I am connected to the internet, making users rely on an online service that could be interrupted or nonfunctional at any point, can never fully replace installable software, which is immune to networking issues, API changes, etc.
 
Last edited:
pleiser,

Given that you describe the Blockly App (Intel Mac 64-bit) hanging when you try to compile this is a bit of a long shot but ...

Open a terminal window, navigate to the Blocky compiler directory:
<where you unzipped Blocky>\Blockly PICAXE.app\Contents\Resources\app.nw\app\assets\compilers\

and try running one of the compilers from the command line to see what happens:
e.g. picaxe08m2 -h

Even if it doesn't work it's possible that the compiler could be outputing an error message that the Blocky code is not trapping.

I don't own a Mac so I can't test this myself.
 
The lack of any "local" compiler was what steered me away from mBed.

I may be in a minority, within a minority here, but I'd quite like to see a truly local macOS compiler. One that allows BASIC code to be entered, not added to a flowchart block. Preferably one that incorporates Macros and the other features never added to the macOS compiler and pre-processor.

Arduino offers an "offline" compiler for macOS, I cannot see why I would now recommend to my department anything other than Arduino.

There is competing version of BASIC for PIC processors which also incorporates many of the (ex)Atmel processors. That has macOS native binaries available, it can be operated from within a simple editor where code can be edited, compiled and programmed automatically. Much like MacAxePad did.
 
Thank you for the helpful thread. So it does seem that Tech Support is inclined to disregard Mac Users at this point, but I thought I might just ask after the cable driver, too. My new Mac mini (M1 chip, running Big Sur), tells me the driver for the USB cable is a 'legacy extension', and will not load. I can get Blockly to at least load up, but without the driver, it seems Big Sur on Apple Silicon is indeed the completely the end of the road for PicAxe. Rather a pity, really. -- The Professor (601)
 
Rev Ed has still not got the axe027 pid accepted (at least not in Linux) in the Future Technology driver's list of valid pid's, and probably never will. That can (and does) cause problems. Two solutions:

Change the cable's pid to the standard 6001
Make your own cable
 
Thank you for the helpful thread. So it does seem that Tech Support is inclined to disregard Mac Users at this point, but I thought I might just ask after the cable driver, too. My new Mac mini (M1 chip, running Big Sur), tells me the driver for the USB cable is a 'legacy extension', and will not load. I can get Blockly to at least load up, but without the driver, it seems Big Sur on Apple Silicon is indeed the completely the end of the road for PicAxe. Rather a pity, really. -- The Professor (601)

You could try the FTDI driver from FTDI direct? It seems to have loaded and worked for me? Although I did install the PicAxe driver over the top of it.

Mind you, I'm not convinced that you will get AxePad running, or the compiler(s) either on M1 silicon.

VirtualBox and a copy of Windows 10, which should work well enough to code and programme PicAxe without needing to be purchased, could be your best route?
 
pleiser,

Given that you describe the Blockly App (Intel Mac 64-bit) hanging when you try to compile this is a bit of a long shot but ...

Open a terminal window, navigate to the Blocky compiler directory:
<where you unzipped Blocky>\Blockly PICAXE.app\Contents\Resources\app.nw\app\assets\compilers\

and try running one of the compilers from the command line to see what happens:
e.g. picaxe08m2 -h

Even if it doesn't work it's possible that the compiler could be outputing an error message that the Blocky code is not trapping.

I don't own a Mac so I can't test this myself.

I actually already tried this, and although the compilers seem to be a newer version than published on the website (modified in 2017, vs 2014), they didn't work, giving the error "bad cpu type in executable".

Regarding the FTDI drivers discussion, I don't yet have an M1 Mac either, but I have in the past had good experiences with installing the FTDI drivers directly from FTDI. MacOS has some FTDI drivers built in as well, and I did have some issues that required disabling the built in drivers. That was several years ago, so I don't remember the details now unfortunately.

Also regarding the suggestion of running a windows or linux virtual machine, my understanding for those with the new M1 Macs is that, although companies are working on it, there's not yet publicly available VM software that can run windows on the new macs.

Given the lack of an official reply regarding an API or unofficial release of the MacOS compilers, I've managed to slightly reverse-engineer the communication involved in invoking the online compiler, effectively enabling an unofficial API. It's still a work in progress, but if you're interested, I can share my code so far, which is pretty close to actually being theoretically functional.
 
Thank you for the helpful thread. So it does seem that Tech Support is inclined to disregard Mac Users at this point, but I thought I might just ask after the cable driver, too. My new Mac mini (M1 chip, running Big Sur), tells me the driver for the USB cable is a 'legacy extension', and will not load. I can get Blockly to at least load up, but without the driver, it seems Big Sur on Apple Silicon is indeed the completely the end of the road for PicAxe. Rather a pity, really. -- The Professor (601)
For systems where you wish to use the default (often pre-installed) FTDI driver instead it is relatively simple to change the AXE027 to use the default PID.
 
Technical,

FYI. Blocky is still reporting "The online compile service is not available. Please try again later " when I try to do an online compile.
 
Given the lack of an official reply regarding an API or unofficial release of the MacOS compilers, I've managed to slightly reverse-engineer the communication involved in invoking the online compiler, effectively enabling an unofficial API. It's still a work in progress, but if you're interested, I can share my code so far, which is pretty close to actually being theoretically functional.

Thanks for your kind and generous offer. I would normally be extremely grateful for your work but I would like to avoid reliance on online compilation.

Once the time comes for me to upgrade to a 64bit only macOS, I fear that any remaining stock of PicAxe devices will be reprogrammed as standard PICs and my PicAxe adventures will be over.
 
Let's not lose sight of who caused all this trouble.

The world's wealthiest business that can't be bothered to make life easier for its customers.

I was going to suggest creating a linux live usb stick to boot into, and use LinAXEpad for programming.

Apple make it so difficult even Linus Torvalds doesn't think it's worth the trouble.
 
Technical,

FYI. Blocky is still reporting "The online compile service is not available. Please try again later " when I try to do an online compile.
Please ensure you are using 1.4.1, you are probably using 1.4.0. The update is required since the blockly cloud site changed from http to https.
 
We have just uploaded 64 bit Mac compilers (for beta testing only please), as well as a version of Blockly 1.4.1 that includes these 64 bit compilers (for ease of testing).

 
Please ensure you are using 1.4.1, you are probably using 1.4.0. The update is required since the blockly cloud site changed from http to https.

Technical, you are correct. My Blocky was v1.4.0 and after downloading v1.4.1 I can online compile with no issue.
 
We have just uploaded 64 bit Mac compilers (for beta testing only please), as well as a version of Blockly 1.4.1 that includes these 64 bit compilers (for ease of testing).


I will give those compilers a try when I get the time. I may be able to incorporate them into Geany. I will (eventually) report on my progress.
 
tmkfam,

If these new 64 bit Mac beta compilers work then you can consider using Visual Studio for Mac as the IDE.

RevEd provide the "PICAXE extension for VS Code" that you need to download but these are text configuration files for VS Code which you need to install on any OS that you want to use VS Code to program PICAXE chips using the command line compilers on that OS.
 
I already use Geany for writing code in another dialect of BASIC for microcontrollers. If the compilers work, it might be quickest to include them in Geany (for me).
 
I have to start off saying that yes, the 64bit compiler(s) for macOS do seem to work. Yes I managed to include it in the "Geany" editor. Ideally you would need to use the python script (or similar) that J G kindly uploaded (https://picaxeforum.co.uk/threads/p...pt-for-includes-and-compiler-selection.32205/) to allow switching between devices, unless you use only a few selected devices and only added support for the devices used.

The compiler threw an error on every single line of the file I opened, probably due to incorrect line endings to that expected?
Error: Illegal character: ('^M' (0x0D))
This file had been successfully compiled using MacAxePad though so I would have expected it to work. I had to add a single quotation mark " ' " to the end of every line to enable it to be compiled.

If I needed to work on a legacy project, this could be the answer.
 
I had the same issue with the ^M in Linux. I think it is the carriage return that is added in Windows as an extra character in line endings that for some reason won't work on other platforms and must be filtered out in the Programming Editor and or Axepad before it is passed onto the compiler. The python script also filters it out so that line endings are just \n instead of \r\n, but I forgot to mention that.

Edit: Git or a text editor might be able to automatically convert the line endings as well.
 
dos2unix is a utility for converting from dos (i.e.windows) style end of line characters to unix style end of line characters.
Try this at a command line prompt:
dos2unix your-filename.bas

and then try compiling the converted your-filename.bas
 
Thanks for the suggestions.

Given this is all getting very hard work, I think it's time I admitted that PicAxe is not for macOS.
 
The fact that you are getting the compiler to start well enough to complain about line endings would say to me that you are close :)
 
Thanks for the suggestions.

Given this is all getting very hard work, I think it's time I admitted that PicAxe is not for macOS.

Any file created on a Mac should not have a CRLF line ending, it should only be the unix style LF. Hence the reason the mac compiler expects a unix style line ending. It is very easy to convert file types in most editors such as notepad++, geany etc. In Geany make sure "Preferences / Files / Default end of line characters" is set correctly to LF (0x0A). Or convert existing files using Document->Set Line Endings->Convert and Set
 
Last edited:
For anyone else that's interested, I've released another update to my PicaxePreprocess script, adding many more of the features that PE6 has that the command line compilers don't natively support (Thanks again to J G for the pull request for many of the new features!) It now supports #IF, #IFDEF, #IFNDEF, #ELSE, #ELSEIF, #ELSEIFDEF, #ELSEIFNDEF, #ENDIF, #UNDEF, #ERROR, #INCLUDE #DEFINE, and the preprocessor substitutions ppp_filename ppp_filepath, ppp_include, ppp_includefilepath, ppp_date, ppp_date_uk, ppp_date_us, ppp_time, and ppp_datetime .

I suppose within the next few years, we'll again be at the mercy of Rev-Ed to release a new version of the compilers that supports Apple's Arm CPUs.
 
Having moved onto ‘Apple Silicon’ [M1 Mac mini] and wishing to rekindle my interest in PicAxe … I was disappointed to read this thread … but I decided to move with the times, and try the Blockly Cloud using the iPad.

The screens seem to work, but the three video tutorials all fail to load, and just display the curt message ”This video isn't available any more” … Then, reading through the PDF maual, I found [on p11] “You must then use the Chrome Programmer App (www.picaxe.,com/progapp) to download the .axe file onto the PICAXE chip. … but that link is dead too!

So my question is: Is there any ongoing support, or is this actually being allowed to die?

Very, very, disappointed so far …
.
Edit:__ I’ve discovered why that URL for progapp doesn’t work … there is a superfluous comma
 
Last edited:
Back
Top