still have to resolve the static mut issue of getting the USB
controller state into the interrupt controller.
I'm not sure there *is* a good way to do it - this might actually
be "the" use case for static mut's - but the point of this
exercise was to just diff out the driver in machine mode versus
OS mode to try and figure out if there's a hardware problem
causing instability or if it's a driver issue
the conclusion so far is that the USB stack requires extremely
tight interrupt handling timing, and so, for better stability
we may have to mirgate away from the heavily user-space dependent
implementation currently in use.
disk enumerates now, and initiates r/w transactions but
the reference driver does not match the implementation in that
the USB stack can't access all of RAM, so we have to add
an intermediate stage that splits the command requests into
smaller chunks
this is in preparation for loader-based updates
may have to increase space even more when we pull in e.g.
firmware signing and verification primitives.
this loops an image from the camera to the oled display in real time.
it will also dump the Y (luminance) data to to a serial port for
offline development & testing of the QR code algorithm.
- fix tx_await() condition to consider both control and tx channels
- make tx_async more efficient for the common case that the buffer
fits in a single transaction by appending the CS de-assert as part
of the initial command stream
- make trait for the udma global clock setting
The high bit in this exploration is that there seems to be no
way to actually confirm when a UDMA transaction has fully completed
on the hardware interface. All the completion signals tell you
when the software-side UDMA resources are freed up. However, in this
case, the hardware-side resources may still be transmitting/receiving
data.
This is a problem for the case of a '4-wire SPI' display where you
need to set an extra line to control command/data mode addressing.
In this case, the current work-around is to read back the state of
the chip select pin as a GPIO to determine when the hardware has
finished.
I suspect that if we can figure out how to use UDMA in a full duplex
mode that we could do something more essentially linked to the
hardware, but this would also require having a dummy Rx buffer allocated
that is the same depth as the hardware Tx buffer if all you cared about
is the hardware conclusion of a Tx.
Realized that the last round of mixed values wasn't actually being
used because we nuke the `seed` value at the top of the loop.
We effectively had a round of ChaCha8 that we were doing but then
throwing away.
This construction should capture all the benefit of the computation
without wasting computation.
