Mac / Linux Support
Closed this issue · 16 comments
A few other users and I would like to be able to use this tool from Mac / Linux. I looked into the possibility of doing this and it seems that some changes may be required.
The command string relies on the windows executable. I wonder if this could instead include artemis_svl.py and ambiq_bin2board.py from the BSPs repo (or perhaps these tools should now be maintained all together in another repo, and the BSPs repo includes it as a submodule?)
Anyhow if those scripts could be included as Python modules then perhaps the AFU could directly call their methods w/ appropriate arguments and pyinstaller could generate windows and mac and linux executables equally well?
I had originally intended to implement the python scripts rather than calling the compiled executable but gave up after a bit. I forget the specifics, but I faintly remember there being major issues re-jiggering the scripts to be callable.
I'm all for it but will need help.
Cool, I want to help. I will try to squeeze in some effort here or there!
Edit: (to any willing open-source contributors out there don't let that stop you from lending a hand, it might be a while before I can make progress on this)
Hi Owen (@oclyke),
Nathan (@nseidle) asked me to take a look at this.
I've had a very quick look at Ambiq's Python and it doesn't look too scary. I think it will transplant OK.
I have a question:
Do you think we should keep "Update Bootloader" and "Upload Firmware" combined into a single GUI, or would you recommend splitting them into two GUIs?
If we keep them combined then I'll need to add a second file browser box for the bootloader bin. Does that make the GUI messy? Is it obvious to the user that they need to select one file to update the bootloader and a second different one to upload the firmware?
I'm leaning towards two separate GUIs.
I'd be grateful for your thoughts!
All the best,
Paul
@PaulZC Good question. Here's what I think:
The user can use the 'Firmware' box to upload whatever program they want (though it was originally created by Nate just to update the firmware on the OLA without needing to use Arduino) I assume that this assumes that the user has the SparkFun Variable Loader flashed so that the program will begin running from 0x10000.
Giving the user the option to upload whatever image they want for the bootloader would make it hard to guarantee that the other portion will work. (Because they might upload something that is not a suitable bootloader and does not jump execution to the 0x10000 address)
So, the way I see it, the firmware uploader GUI could come pre-packaged with our latest SVL version and that is what you get when you press 'update bootloader.' When the SVL gets updated we could just re-release the GUI with that new binary (maybe?) (hard mode: the button could perhaps retrieve the latest SVL over a network connection, so that it always gets the latest.... but it would need to keep a local copy for use without network...)
That's just my opinion of course ;) Thoughts?
Many thanks @oclyke - great suggestion!
It looks like the pyinstaller --add-data option will let us do exactly that (include the bootloader binary as part of a --onefile bundle). I’ll give it a try tomorrow.
Thanks again!
Hi @oclyke / @nseidle ,
The integrated code could do with a little tidying-up, but is working nicely on Windows. Pyinstaller builds successfully and the artemis_svl.bin gets bundled successfully too! It is ready for testing on Linux. I'll give it a go on Raspberry Pi over the weekend.
https://github.com/sparkfun/Artemis-Firmware-Upload-GUI/tree/PaulZC_Integrated_Uploader
All the best,
Paul
The GUI now looks like this, just in case you want to update:
https://cdn.sparkfun.com/assets/home_page_posts/3/2/4/5/Artemis_Firmware_Uploader_GUI.jpg
PS. The Blink.bin in the repo blinks on pin 19 - not 5. So I guess it blinks the STAT LED on the OLA - not LED_BUILTIN on the ATP? Should we fix that?
This looks really good Paul! Thanks for working on it.
WRT Blink: Yes, the original was really just for OLA. Please modify to your heart's content. I recommend blinking multiple pins to support multiple boards.
Sweet! I'll give it a shot soon. Nice work Paul!
Code builds and runs nicely on Raspberry Pi at 115200 baud:
I was using a fresh Full install of Raspberry Pi Debian - which comes with python3-pyqt5 5.11.3 pre-installed. (Avoid PyQt5 5.15 - it doesn't seem to want to install correctly.) The only thing I had to install was pyinstaller (pip3 install pyinstaller).
from the /tools directory, use:
pyinstaller --onefile --distpath=. --icon=artemis_firmware_uploader_gui.ico --add-data="artemis_svl.bin:." --add-data="Artemis-Logo-Rounded.png:." artemis_firmware_uploader_gui.py
If pyinstaller has ended up in ~/.local/bin use:
~/.local/bin/pyinstaller --onefile --distpath=. --icon=artemis_firmware_uploader_gui.ico --add-data="artemis_svl.bin:." --add-data="Artemis-Logo-Rounded.png:." artemis_firmware_uploader_gui.py
The only gremlin I've found is that the icon gets ignored...
I've updated Blink.bin so it will flash LEDs on all the boards. I'm not seeing any undesirable conflicts other than it also toggles the GPS power on the AGT.
// ***** SELECT THE REDBOARD ARTEMIS ATP - to avoid pin/pad confusion! *****
// The Edge uses the bare Apollo3 and does have pad 46 (GPIO46) connected (to LED_RED)
// All of the boards based on the Artemis Module do not have pad 46 connected
// So, for the Edge, let's pick pad 44 (LED_GREEN) instead!
#define blinkPin_ATP 5 // RedBoard Artemis ATP (Pad 5) - also covers the RedBoard Artemis (Pad 5)
#define blinkPin_OLA 19 // OLA (Pad 19) - also covers the Edge2 (Pad 19) and the AGT (Pad 19)
#define blinkPin_TP 26 // RedBoard Artemis Thing Plus (Pad 26)
#define blinkPin_Nano 31 // RedBoard Artemis Nano (Pad 31)
#define blinkPin_Edge 44 // Edge (Pad 44)
// RedBoard Artemis ATP:
// Pad 5 : Pin 5 : ~D5/SCK/LED
// Pad 19 : Pin 19 : ~D19
// Pad 26 : Pin 26 : ~D26
// Pad 31 : Pin 31 : ~AD31
// Pad 44 : Pin 44 : ~D44
// RedBoard Artemis:
// Pad 5 : ~D13/SCK/LED
// Pad 19 : Not connected
// Pad 26 : Not connected
// Pad 31 : ~D21/A5
// Pad 44 : Not connected
// RedBoard Artemis Thing Plus:
// Pad 5 : ~D13/SCK
// Pad 19 : Not connected
// Pad 26 : ~D18/LED
// Pad 31 : ~D24/A5
// Pad 44 : ~D2
// RedBoard Artemis Nano:
// Pad 5 : ~D11
// Pad 19 : ~D19/LED
// Pad 26 : Not connected
// Pad 31 : ~A5
// Pad 44 : Not connected
// Edge:
// Pad 5 : Camera Y3
// Pad 19 : Not connected
// Pad 26 : Camera HREF
// Pad 31 : Not connected
// Pad 44 : LED GREEN
// Edge2:
// Pad 5 : Camera D5
// Pad 19 : LED RED
// Pad 26 : Camera MCLK
// Pad 31 : GPIO 31
// Pad 44 : GPIO 44
// OLA:
// Pad 5 : SCK
// Pad 19 : STAT LED
// Pad 26 : SDIO1 (MicroSD DAT1/NC)
// Pad 31 : Not connected
// Pad 44 : ICM !CS
// AGT:
// Pad 5 : SCK
// Pad 19 : WHITE LED
// Pad 26 : GPS Power Switch (!) so will also flash the blue GPS Power LED
// Pad 31 : Not connected
// Pad 44 : Not connected
void setup()
{
pinMode(blinkPin_ATP, OUTPUT);
pinMode(blinkPin_OLA, OUTPUT);
pinMode(blinkPin_TP, OUTPUT);
pinMode(blinkPin_Nano, OUTPUT);
pinMode(blinkPin_Edge, OUTPUT);
}
void loop()
{
digitalWrite(blinkPin_ATP, LOW);
digitalWrite(blinkPin_OLA, LOW);
digitalWrite(blinkPin_TP, LOW);
digitalWrite(blinkPin_Nano, LOW);
digitalWrite(blinkPin_Edge, LOW);
delay(1000);
digitalWrite(blinkPin_ATP, HIGH);
digitalWrite(blinkPin_OLA, HIGH);
digitalWrite(blinkPin_TP, HIGH);
digitalWrite(blinkPin_Nano, HIGH);
digitalWrite(blinkPin_Edge, HIGH);
delay(1000);
}
@PaulZC this is looking awesome! Would you consider updating the readme to include instructions for these new platforms? Once you do that will the changes be ready for a pull request / review?
Hey Owen (@oclyke ),
Sure - no problem. Do you want "how to run the code" instructions, or "how to build an executable using pyinstaller" instructions?
I'm thinking we should add executables for OSX and a generic x86 flavour of Linux (if such a thing exists!?) but I've got no hardware here to build those on. If you have, any chance you can find time to work on this? Thanks!
All the best,
Paul
Right, good distinction. I was thinking of something pretty basic - like explaining that on Windows you use the .exe and on Mac you use the file in (say) binaries/macosx/ and on Linux you use binaries/linux/. But instructions to build the binaries would also be useful because it can then cover people with those exotic Linux builds.
Yes, I could help generate binaries. I have a laptop running OSX 10.15 and a VPS running Ubuntu 18.04 (or something like that)