pyOCD
pyOCD copied to clipboard
pyocd
Standalone Flash executable
Hi all,
Is there a way to generate a standalone binary for the flash portion of PyOCD? It looks like in the how_to_build.md there are instructions for building a standalone executable but I see that it is outdated, as the option for building the flash tool on its own has been removed.
We've adopted the DAP-Link project as our debugger/programmer of choice in our Engineering team and my use case is as follows: Our hardware engineers would like to be able to take a .hex file given to them and flash a target at their bench without requiring too much setup (This is mostly a severe allergic reaction to having to open a CL :roll_eyes:). The same goes for our clients who are not as technically adept, but would like to be able to update their devices without sending them back to our office.
I would like to create a GUI application that will build the latest PyOCD Flash tool and package it along side our application. (Think J-Flash for the J-Link suite of tools). That way we can send a DAP-Link probe, Installer/Executable and their new Firmware and the end user is able to update without too much hassle.
Is this an existing feature or is it a potential new feature that could be added (again)?
Thanks!
Whew, really sorry it took so long to get back to this one! 🙇🏽
Having a GUI flasher is (somewhere) on the todo list. 😄 It's something I'd like to get to, but right now there are lots of other priorities for me. But I'd be super happy to held guide an effort.
Also on the list is releasing a standalone executable of pyocd. The how_to_build docs are unfortunately totally out of date. 😦 I have a work in progress branch feature/binary_build with updates to the pyInstaller script, but it's not working. There are issues with some of the dependencies that I didn't have time to finish debugging.
Another option for a binary executable is PyOxidizer, but I haven't tried it. No idea if it's better.
@flit no worries on the delay. I know your a busy person! I am more than happy to help and contribute to this. What did you have in mind when creating this GUI? Did you intend to ship it with the pyocd utility or have it has a separate project/repo and then the pyocd executable is a dependency?
My idea was the latter. We have been on an ElectronJS kick lately and created quite a few applications with standalone executables as binaries so this wouldn't be much of a stretch to get SOMETHING working.
I'm realizing as I type this out though that I would need to either duplicate your effort on the Pack manager or instead generate a standalone .exe for the entire PyOCD tool and then put a GUI front-end on it instead of the "Flash" portion only.
Happy to hear your thoughts and help out.
Having it be a separate project is probably best, but I'd be happy to host it within the pyocd GitHub org.
Personally, I was thinking it would be easiest to use PyQt5 or PySide to build the UI, so it stays entirely Python. Then use PyInstaller or PyOxidizer to build a standalone executable. Not sure how realistic the executable is, though, I haven't even been able to build pyocd itself as a standalone executable lately (I'm sure it's possible, just haven't had time to follow through debugging), and the Qt libs will only add complication.
So an Electron based project might be easiest, especially if you're already familiar! If you can't put the time into building pyocd as an executable, something like miniconda might work. That's how pyocd is packaged for Mbed Studio. That would also cover the Pack manager.
One question is how to communicate with the pyocd process. It's perfectly possible to just parse the current stdout+stderr output, and that should be the starting point. But for a long time I've wanted a better machine interface, something like a simple JSON Lines based interface over stdio. This would obviously be a long term goal, however.
I'll take a look at miniconda and/or generating a standalone binary. That's the only real hurdle to getting a minimal viable product.
Our current implementations are just event listeners on the 'std' pipes. Based on our current "state/operation" we know what to be parsing & looking for in the output strings. Creating a standard interface over stdout/err intended for communicating to other processes would be totally fine and we can definitely look into it. I would agree it's much more robust and is the "correct" way to go about this type of problem in the long run.
// I should add that we also have experience with JSON Lines (Didn't know that's what it's called or had a "project"). We use it on a lot of our embedded projects where we need some quick basic comms. We put a CDC serial port on the MCU and use a lib like cJSON to parse incoming packets (Outgoing is just a template string & printf) and then communicate via JSON objects to the electron app :+1:
The feature/binary_build branch on my fork is as far as I got with PyInstaller. IIRC, the last? hurdle was prettytable for some reason.
Yeah, I also had never heard of the JSON Lines project/spec until very recently even though I've used it (more or less) in pyocd for the remote probe server/client.
Any news on this? I want to make an standalone programmer for the py32f002. The idea is to make a port of the arduino core. Tks
