search

modm-io / modm

modm: a C++23 library generator for AVR and ARM Cortex-M devices
https://modm.io
Mozilla Public License 2.0
739 stars 132 forks source link

More flexible firmware upload support for multiple targets and programmers #355

Closed salkinium closed 2 years ago

salkinium commented 4 years ago

scons program should be renamed to scons upload and support a more generic way to upload firmware to the device (preferrably only wrapped by SCons so it can be reused by CMake).

openocd != ST-Link, but so far this is the only combination we use. openocd offers many other debug adapters.

Original comment:

arm-none-eabi-gdb + Black Magic Probe is the other combination I am using.

Also to be considered:

  • Deal with serial and CAN bootloaders
    • at least the ones which are preprogrammed to STM devices
    • optionally, all 'official' bootloader protocols like app note AVR109 (which is commonly used by Arduino I think)

I would like to see a concept for retargeting the existing semantics of the CLI onto the user's specific targets:

  • scons program transparently uses either OpenOCD or BMP or DFU or STLink
  • scons gdb transparently runs both GDB and programmer

I am in favour of

  • scons upload (or even flash if target is flash.)
  • scons debug

And debug can also be something else, not tied to the gdb tui forever. Saw some nice web-based tool.

salkinium commented 4 years ago

Additionally when having multiple programmers connected, it should be possible to detect which targets are connected and automagically choose the right one for the current context. So if I have a bunch of Nucleos connected, the script needs to probe all targets IDs (once with cache?) and choose the Nucleo that matches the current :target. Alternatively a mechanism must be provided to select a specific programmer or specific device (using UID, USB port or serial number?).

It would also be nice to automatically select the right serial port for bootloaders, if that is possible.

rleh commented 4 years ago

scons upload or scons download? Arguments could be found for both terms, so I am strongly in favour of scons program!

salkinium commented 4 years ago

Well, 🤓🤓akschtually🤓🤓 OpenOCD is doing both an upload and a download or the other way around to verify the firmware writing was successful. But joking aside, of course we would alias scons program to a new command if any.

salkinium commented 4 years ago

I think scons upload would be the correct term, since they are user centric as in a webbrowser, where upload means "data going away from the user's machine", and download "data going towards the user's machine". The user's machine here being the USB Host where the user calls SCons. 🤓🤓🤓🤓🤓🤓🤓🤓

rleh commented 4 years ago

I recently worked with EtherCAT devices and there a transfer from the Computer to a device on the bus (slave) is called download. Transferring data from the connected device to the computer is called upload.

Therefore I would prefer not to use the term upload anyway, but a more unmistakable term like program or flash.

salkinium commented 4 years ago

Ok, no directional commands then. What we have is:

se-bi commented 4 years ago

scons program: transfers the firmware using some mechanism onto the device, could also be into RAM.

I just wanted to ask: Is their a scenario where flash would not be suitable?

When and why is loading into RAM used?

But, I am also struggling with program.

salkinium commented 4 years ago

When and why is loading into RAM used?

For example when you want to execute a bunch of unittests without wearing down the flash too much. In most devices there is enough RAM to fit both code and data. (this needs linkerscript support, which we currently don't have). Also EEPROMs and other non-flash based storage exist ;-P

But, I am also struggling with program.

Yes, I, the programmer, don't like the programming my program via a USB programmer thing. But it's not super important for me, it's just a name at the end of the day.

salkinium commented 4 years ago

I've refactored the SCons tooling to extract the common code into a stand-alone Python library that makes it easier to implement more complex features (like auto-detecting of programmer) without having to worry (too much) about how to integrate that into the build system. I resurrected a all programming methods and integrated them fully with debugging via GDB tui or gdbgui. Currently implemented:

se-bi commented 4 years ago

Is there plan to address to boards by there type, e.g. _nucleoxy, _discoveryxy or whatever one is using

or only via the iSerial which is offered by the programming device?

Like building some kind of memory / cache either in the modm clone or somewhere in $HOME, where a mapping of iSerial to board type is stored, whenever the board was programed the first time as the only one connected.

(Maybe also refuses to program, if there are multiple boards and no mapping)

salkinium commented 4 years ago

Is there plan

Yes. Somewhere in my head there is a plan. I'm almost certain of it! 😜

The broad idea is something like scons/make program port={usb-port} serial={hex}? It's not trivial to detect and categorize connected devices, so I didn't want overload the PR with even more functionality.

salkinium commented 3 years ago

We should use the libusb1 Python library to detect what kind of programmer is available, then choose the best one.

salkinium commented 3 years ago

We should be looking at pyOCD as a replacement for OpenOCD.