Got up to version 8 to decode, although version 8 is a bit fussy.
Fairly sensitive to camera focal distance - hard to see focus
issues on B/W display. This needs to be improved in the HW.
There is a hardware bug that causes SPIM RX packets to fail when
the UDMA bus is busy (like when streaming video). This causes
swap memory to fail because it relies on the SPIM bus.
This patch causes the video to sample *after* any computation
happens, so that any swap memory that might be hit taken care of.
This reduces the efficiency of the loop somewhat, because without
the decongesting, we could kick off the camera read and do useful
computation while the camera streamed data. Now we have to keep
them separate to work around this bug.
The USB hardware stack is different enough that I think it
doesn't make sense to wedge it into the existing USB driver.
Instead it will be a separate driver that has the same `lib` level
API calls, but a totally different implementation underneath.
This allows us to make better architectural decisions that will
make the USB stack more reliable because the hardware has some
pretty strict latency requirements on responding to packets that
can't be met with the previous abstraction.
The whole graphical interface - camera + display & QR code processing -
is incorporated into a single process space to minimize on the amount
of swapping/memory message passing necessary to implement a low-latency,
high-frame rate video interface.
The current service just starts a camera-to-display loopback
while searching for and aligning QR code markers, without consulting
any other service on whether it should do that or not. Suitable
for debug and performance characterization, but not usable for
product integration.
The good news is we're getting an acceptable frame rate on
the camera during search mode with the kernel running.
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.
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.
