Firmware To Do thread

Development
1

There’s a ton of good stuff to work on and cool scripts to add. It’s getting spread around, so I’ll try to keep it here.

I2C stuff

  • Rework the PIO program to be less fussy about releasing the bus after errors
  • Add a list of I2C addresses (to a text database on flash?) as a reference
  • Get permission to embed i2cdevice.org list, or copy the JSON database to the flash and search it for matching device IDs

Help

  • Needs to be totally reworked. It is terse because we had 64K words on the old bus pirate. Maintaining that dual column design is a right pain.
  • New system needs to be implemented in all commands/help screens

SPI stuff

  • SPI binary mode is the most important binmode in my option, because it’s the most likely to do heavy lifting with flash scripts. I’m on this next with flashrom. There are new PICO things that have modern flashrom support (Dirty JTAG), maybe one is a better option? @Dreg told me the flashrom support depends on dipping in and out of the old text terminal, which is a bit ugh.
  • Build out the onboard “load” and “dump” commands. Currently they support a single 256 byte chip. It should be a fairly quick and fun project to add support for the most common flash protocol, though setting the configuration is going to be an interesting bit of work.
  • SPI Flash program currently uses SPI. Update to use QPI when possible for speed

Arbitrary Waveform Generator?

Frequency measurement project

WS2811 LED client

SLA4442 and similar smart IC cards

  • 2 wire mode
  • dump/load/lock/unlock scripts.
  • Adapter PCB

JTAG stuff

HIL testing?

CH32V003
-SWIO program/debug tool interface and another for porting as a stand alone

Ncurses and tiny emacs

Hex editor - I added a hex print command but it’s just a basic dump. There are pretty formatting scripts used for syntax that could make them look a little better. The ability to navigate a binary file and do hex edits would be interesting. Perhaps in the second display buffer?

TPMsniffer

Ported firmware

I port stuff to the Bus Pirate all the time. It’s kind of a mess at the moment.

  • Need to refactor the bus pirate firmware so the main hardware (buffers, display, psu, resistors, maybe storage) is supported by a library I can just add to other projects
  • Big one: I’m guessing we can have separate compiles relocated in a massive firmware file. The desired mode can be set and saved to the onboard storage. On restart a second stage bootloader reads the mode and dispatches to the correct start location. This gets over the issue

System updates

There’s some really nice half-finished stuff that would make life easier going forward, or it could be replaced with something existing.

  • I want a clean separation of menus/prompts/parsing/validation. This means keeping options like voltage/fuse/current limit out of the code that actually configures the power supply (part of moving things into libraries). commands.c is sort of my hack of the napkin sketch what I could do in that regard. It needs some work to separate it into topical files and somehow register the components as available without the massive arrays of parsers and functions.
  • This is when things like the kind of choppy PSU setup will because streamlined and consistent.
  • The introduction of the scope brings in the concept of display mode. Before anything like a logic analyzer display mode is added, it needs to be refactored to be more like the modes operate. A struct of functions for each mode assigns handler functions. Then choosing a mode is done by a key in an array of the structs. Paul already did this.
  • Binary mode similarly really needs to be handled the way the modes are handled. A struct of handler functions called in response to commands. This will help give a consistent interface and feature set across modes, instead of the hodgepodge that currently exists.
  • opt-args - I spent about 10 minutes on a way to pass variable from the command line to the first scripts I wrote. It’s a big ugly bag of variables. I think it’s better to put this all in a single array, then store the index and variable type for casting to char uint, float, or null terminated string as needed.
  • The syntax compile-run-report system is nice, I’m very pleased with it. It currently works on a “slots” system that fill up when there’s too much data to send or output generated. This should at least give a warning of less than idea performance, and then keep sending/receiving data as best possible.

Logic Analyzer is probably good for now, but there’s always more things to add!

  • Split pin mode to use logic analyzer and Bus Pirate output at the same time.
  • Menu and options for UI LA
  • No buffer voltage warning and suggestion (W) when LA starts.
  • Add 200MHz overclock 100MSPS mode
  • Add ADC measurements from scope to LA for analog view in clients (pulseview and ols both support an analog view)
  • logic-viewer or load saved logic files in main UI for viewing later
  • Increment or name saved .bin files
  • Show indication/feedback in UI for state ARMED/SAMPLING/DUMPING
  • ‘Auto’ mode similar scope that looks for trigger or auto updates the display every second for live view stuff
  • LA graph as a display mode
  • Complex hardware triggers (see gusmanb for examples) in PIO. They can communicate with a shared pin. The button pin would be a good candidate, and users pressing the button would then have the bonus of being a manual trigger.
  • I already ported gusmanB and pico-sdk-sigrok

I’m sure I’ve forgotten things. I’ll keep adding as I find them.