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.
- add USB mass storage state tracking for handler-based intervention
- fix some wait loops
need to regression test this againt a xous-mode USB operation
split the handler out into a function pointer
add callbacks for completion handling of EPs - in-line with
the reference code
improve the pei handling
change visibliity of structures to allow for out of crate
handlers
We use the txrx call instead, which does not signal a completion
until the rx transaction is finished (which is after the final
bit is received of a pending SPI transaction).
This allows us to do a "swap" transaction (transmit and receive)
asynchronously (the await returns a pointer to the receive buffer).
Note that a pure-rx-only variant is still todo, but should follow
pretty naturally from the pattern outlined here.
this is a CSR object that presents writes as an immutable on the
parent object. This simplifies traits, etc.
On the one hand, the CSR itself is truly immutable - the address
represented by the CSR does not change.
On the other hand, the underlying data inside the CSR is changing,
so, the CSR actually represesnts an immutable pointer to a mutable
piece of data.
For the case of the UDMA, we have a bank of globally shared state,
it is much more convenient to think of the CSR as immutable, and
we manage the underlying global shared state through other checks,
e.g. through dynamic allocators that track when various blocks
or resources have been parceled out.
- 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.
this allows us to tease out the clock setting code from the pin
setting code. probably will need to add more helpers for other
peripherals as we continue through with this exercise.
- filter setup can be impacted by previous engine running, make
sure engines are stopped and FIFOs flushed prior to test start
- when reading a filtered bank we can get garbage, so make the
test check for the specific value we should see.
