Use MicroPython for full flexibility

[torwag]

Hi, when the buspirate was introduced, running on an PIC uC. The software landscape for microcontrollers was still pretty much C...

However, now we have tools like MicroPython. As I used both projects intensively I always dreamed of having a buspirate running MicroPython as "OS". This would enable users to rely on a complete programming language. In an interactive session you could easily define functions which set-up the buspirate, define the protocol, send initialisation code, request or send data, even very complex scenarios, etc.

Furthermore, with the help of the vfat memory (something the buspirate and MicroPython have in common), the community could build up libraries for all kind of chips. Within individual MicroPython files the entire communication protocol can be embedded and the buspirate can provide functions to test chips on different levels, from bit-by-bit up to a single high level read_sensor() command.

Yet other libs can be more generic, dealing with byte-juggling, formating, filtering, searching, fault detection, etc.

For me, that would be a perfect combination of two great projects

[therealdreg]

Hi, when the buspirate was introduced, running on an PIC uC. The software landscape for microcontrollers was still pretty much C...

However, now we have tools like MicroPython. As I used both projects intensively I always dreamed of having a buspirate running MicroPython as "OS". This would enable users to rely on a complete programming language. In an interactive session you could easily define functions which set-up the buspirate, define the protocol, send initialisation code, request or send data, even very complex scenarios, etc.

Furthermore, with the help of the vfat memory (something the buspirate and MicroPython have in common), the community could build up libraries for all kind of chips. Within individual MicroPython files the entire communication protocol can be embedded and the buspirate can provide functions to test chips on different levels, from bit-by-bit up to a single high level read_sensor() command.

Yet other libs can be more generic, dealing with byte-juggling, formating, filtering, searching, fault detection, etc.

For me, that would be a perfect combination of two great projects

so... do you wanna a ipython shell with buspirate features right? like a pyftdi on stereoids... too ambitous :D

[torwag]

More like a buspirate firmware running on MicroPython, a core library which includes all the buspirate features and a reference implementation of that library. The "cl-interface", which basically does what the current firmware does in terms of cli but enabling it to load additional tools (MicroPython files which follow a certain interface standard). This modular method enables the design of of entire alternative interface modules, the usage in an interactive shell, as well as the possibility for the community to contribute additional cli-compatible modules. E.g. A module for WS2812 could, after being loaded, provide a tool in the cli, which includes easy addressing of individual Leds, test pattern, timing tests, colour testing, total number testing, etc. This are all features, very helpful to people experimenting with WS2812 stripes but complete overkill to keep it in the main firmware, let alone being maintained by the core devs. However, a perfect candidate for a community contribution and maintenance.

[DangerousPrototypes]

That sounds interesting. Is it possible to mix C with micro python? I know there are lots of libraries out there that cover a lot of devices, but I'm not super keen to build and maintain an embedded project this big in python. There's no reason a parallel project for the same hardware couldn't be made by developers with more micropython experience than me.

[dzervas]

it sure is possible to mix and match python but micropython has a fair amount of problems due to its nature - memory segmentation is a big one for large projects and/or small RAM environments

It would certainly be amazing to have a python interface but it smells impossible (as in: while I don't have a deep understanding of neither the project nor the RP2040, it seems unrealistic)

however, as @DangerousPrototypes said there's a lot that we (community) can do to bring a micro/circuitpython firmware targeted for BP5 (easy libraries to do everything with a lot of syntactic sugar and nice GUIs)

[torwag]

The rp2040 is already a first class citizen of the Micropython project and the main dev of Micropython actively work on getting the experience of Micropython on the rp2040 better and better.

Living at a time where people can simply swap boards as long as the same microcontroller is used, I believe we come to the point that one could, without any modification, install Micropython on the buspirate 5.

I gladly would give it a try as soon as my buspirate 5 arrives.

I agree that Micropython might take much more resources and that particular for stuff like bitbanging and timing things could get ugly. That is why I agree with you that a mix of C and Micropython might be needed.

That said, Micropython comes already with libs to deal with I2C, SPI, etc. Sure enough those libs expose interfaces at a rather high level and do not provide such a detail like it is known for the actual firmware, but it proofs that it is not an impossible task to do.

[MrAureliusR]

I don't think Micropython would work well for such a real-time, accurate system like this. The overhead in Micro/CircuitPython is quite high and unpredictable. There's a reason C is still used for so many embedded systems. I think CircuitPython is great when you're quickly prototyping something, but for an application like this it just doesn't feel like the right choice.

[thestumbler]

Is the second core being used in the BP5/5XL/6 build? If it's free, the next question, is there enough memory available for MP? Then maybe put MicroPython in the second core, as only a mere shim to the main Bus Pirate code. Basically it would be an interface library that presented the CLI functionality as a Python module in the so-called Pythonic way.

However... while such an embedded method might be cool, what advantage does it have over just providing the same Python shim library to run on your computer? The only edge cases I can see are if your computer can't run Python for some reason, or you are a time-traveler who insists on using a real terminal with their Bus Pirate.

I will note that these two approaches are not mutually exclusive. In fact, with minor attention to the details, one could write such a shim interface library so that it could be used in both MicroPython and the PC desktop/laptop.