The API now provides, in addition to stand-alone read/write
transactions, the ability to send a group of transactions that will
be executed in-order without any other transactions in between.
This allows better compatibility with devices that are designed assuming
they are the sole target on the bus.
Note that the current implementation does not thread out the I2C
handler into its own thread so the service provider blocks until
all the I2C transactions are done. Adding a thread to handle
the I2C stuff would allow other requests to make progress but
at the moment this isn't required.
this is a slimmed down target designed for a smaller memory
footprint. there is some loss of process isolation security but
also a boost in performance due to more items sharing a memory
space.
The screen is tiny, so it's not useful for feedback -- all interaction
happens on the serial console for this target.
Main purpose for this console is debug/test/factory bringup.
mass storage is...somewhat stable now, on both linux and windows,
but there are some corrupt packets. need to look into whether
electrical issue, or if we're stomping the transfer buffers because
we've not managed them correctly.
Also need to reflect on how to turn this API into something
safer...the hardware is doing *so much* in this API, the driver
is basically global mutable state with arbitrary slices you can
write over the ends once you hand things off to the driver.
this is for higher resolution QR code scanning
makes it incompatible with simultaneous USB usage
however, when camera is off, the USB stack can be started, and
vice-versa. Basically, you can't both do active USB and camera
at the same time, but you can do one or the other.
