I want to control the BP5 programattically, in C-- is there a working binary mode where I can execute commands? I see it has binmode, but none of those seem applicable to generic control.
Posts here seem to indicate this not implemented or a WIP?
Obviously doing this through the normal interface would be pretty onerous, since it’s geared for human interaction.
I second this. Having a binary interface to the complete character-based interface would be awesome.
Or alternatively, have the “normal” mode not ask about ANSI color on start, just start up with whatever you have it configured for (e.g. No color, no ANSI status bar, just pure character mode), though the “I2C START” reports aren’t super helpful either.
The console is intended for interactive use.
There was talk of defining a protobuf mode for the binary UART. That seems the right way forward, to allow access from C, C++, C#, JAVA, … etc., with the interface only needing to be defined once.
I don’t think it has any progress yet. I you have expertise in this area (or are interested in learning protobuf) … start small, by branching the code, defining a bitbang’d IO interface, and whipping up a prototype. Then create a second branch, and create that same prototype, only better by using your learnings from the first attempt. 
I’m interested in learning protobuf and integrating it … so maybe we’ll end up working together on this. First, however, I need to get RTT working so debugging is less painful…
Unfortunately it is still underdeveloped. There are two routes into SPI, a legacy mode and a demo mode. Neither are ideal.
I made a few starts towards a simple “will work okay” binary interface. Every thread evolves into a discussion of protocol buffers, which sounds super nice but is something I have yet to wrap my head around and nobody has contributed a prototype or pattern to follow.
The binmode test framework is a set of functions to control most aspects of the Bus Pirate. It is intended to be wrapped in any protocol someone wants.
Barring a hero contributor, I will put together something simple that nobody will like by the end of the year 
Honestly, if we could just get a mode on the first serial port where all the interaction is machine-friendly (100% reactive, not interactive), that’d be great.
SLCAN is a good example of a serial-to- protocol. It translates simple serial commands into CAN bus messages. When a message is received, it’s simply dumped to the serial port in the same format as if you had sent it. It’s 100% printable ASCII, and binary data is always in hex
I personally need I2C, so if the first serial port could handle:
Setup I2C, 100K, w/ clock stretching:
m 5 100 y
Or better yet:
i2c 100 y
since the numbers are a bit ambiguous.
That’s what the second serial port is for … automation interfaces. Trying to fit that into the first serial port will result in compromises that will cause long-term pain. Not recommended…
Okay, but the 2nd serial port doesn’t seem to support the functionality of the first port.
Correct. This automation is not implemented yet. Then again, the firmware doesn’t support all features via the interactive console yet.
It’s open source, and pull requests are welcome.
That sounds really close to the binmode test framework. There is a method to get a CSV list of protocols, and then return the protocol name to enter the mode. However, it is not a protocol itself, just all the functions needed to implement one.
If you’ll be around to test in a few days, I will implement a basic I2C access mode this weekend.