Well, this kind of blew up on me 
All the infrastructure is in place, but it turns out a ton of the mode header files are reused and have a lot of the same structure names. Bringing it all together in bpio_transactions.c results in 100s of compiler errors.
Options?
Option 2 is probably less tedious than option 1. I guess cleaner too.
I’m really excited about the BPIO2 interface! I just realized the I2C interface doesn’t have the sniffer mode. I might have to switch back to the manual mode for now, but a way to run that would be amazing!
Hope you find it useful! The docs are available here.
I’m trying to learn from past mistakes (BBIO1) and be really methodical about adding BPIO2 features. We’ll get there though, then next step is to define an asynchronous table for stuff like sniffing.
Not sure if it is best to resurrect this old thread, or start a new one.
Currently working through BPIO2 updates for:
The major change is the addition of a is_async to the Data Response table. This indicates packets that arrive async from any deliberate data request. For example UART, HDUART, and INFRARED.
BPIO control of the UART and LEDs is now live in the firmware, tooling, python lib and docs.
There’s a new is_async flag in the response packet indicating if it is in response a request, or generated asynchronously.
To support this, library developers need to have a main routing function that receives all the incoming packets and dispatches them to the right handler based on the async flag. See the Python library for an example.
I’m working towards getting HDUART mode working, and the best test we have for that is the SIM/bank IC card reader. This needs a PWM, so step one is supporting PWM from bpio2.
Still experimental, but I updated the flatbuffers schema, tooling, and the python client. It seems to work fine. Next I’ll finish up the HDUART bpio mode and update all the docs.
