Several projects I’d like to port into the main Bus Pirate firmware use USB vendor class endpoints. I’m going to add one on an experimental branch firmware as a second kind of binary access mode.
It’s almost time to think about priority between the different interfaces.
Counting things through…
- COM A - terminal usage with its own modes
- COM B - Binary
- Potential USB Vendor-defined interfaces
- Potential USB HID interfaces (my changes, not yet ready)
Does use of BBIO2 lock out other access? Does entering specific modes lock out other interfaces?
Or, does BP5 just leave it to the user to prevent the host from accessing things from multiple interfaces? (note: when this occurs, it can be difficult to diagnose / prevent.) Maybe even intentionally allow “conflicting” access?
Binary COM locks the terminal COM. With a message. Indeed I need to handle cases where the terminal isn’t open so we don’t lock up waiting for the queue to clear.
The others should lock when active and unlock at end with a reset command.
I’ll check the current state of locking and push something multi mode capable.
Updated topic to “& HID”. I’m going to install the infrastructure for this as my next binmode task.
Awesome! I needed to add a HID endpoint, and trying to figure that out blocked my addition of a “neat” / “nice to have” / “Wow factor” feature.
Looking forward to learning from your changes how to add a specific HID type!