This week I’m going to port the old binary IO to Bus Pirate 5. I originally planned to rework the protocol a bit and use USB HID, but after a discussion on Twitter I realize that it’s more important to have backwards compatibility with existing software first.
Second UART for Binary IO
One of the big differences: I added a separate dedicated UART for binary mode. The old binary mode was started with 20 x 0x00, that works but it is kind of sloppy. A dedicated UART keeps it clean, and maybe we can show debug data from the terminal UART or something cool like that.
SPI first
There’s a cool programmer project over on twitter that had some suggestions for enhancing binary mode for the new hardware. I’ll start with SPI so I can do testing with their software.
I’m testing BIO and adding in all the functions using a single UART. Here’s a couple issues I’m thinking about:
It probably is good to use a single UART (shared IO buffer, code simplicity, user confusion).
Sharing the UART is very problematic:
A. The Bus Pirate waits for y/n answer for VT100 terminal emulation, so I need to add entry point here, as well as the main loop (doable)
B. If the Bus Pirate is already on and in VT100 mode there’s a ton of data pushing for the status bar, and also all the VT100 encoding stuff for color will break things that try to parse the terminal output.
The obvious thing is to default to monochrome/ANSI mode, but most users are going to want the new updated interface by default and I feel like needing to enable it each time is a bad user experience.
I’m going to keep implementing it as I have it now and worry about that later, but it feels like the second UART is going to be needed
