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.
hope to trim this down a bit - using rqrr to do some back
end processing but after intiial evaulation the right path
is probably going to be fork and slim down the code, which
is fine by me.
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.
There's a hardware bug that makes concurrent camera and SPIM
traffic unreliable. The work-around is to place the camera
code inside the XIP area so we don't have to hit SPIM to swap
in code while the camera is running.
However, we do need to figure out a more reliable fix for this.
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.
