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.
This releases flatipc 0.1.2 with more documentation and a new
`Ipc::from_memory_message()` call to reconstitute an object from a
xous::MemoryMessage.
Signed-off-by: Sean Cross <sean@xobs.io>
prior use of `rkyv` reserves two bytes to record `pos` pre-pended
to the rkyv record
the new rkyv works without having to do that because it indexes
the rkyv data off the end of the stored records. Thus, all you
need to know is the total length of the byte slice that stores
the serialized data. This is available as the return argument
when you read a PDDB key, so we don't have to explicitly store it
anymore.
@nworbnhoj would love it if you could have a look at
the implementation and let me know if I've ported this correctly.
I think what was going on is you were using rkyv to serialize
a structure to the PDDB. I've just updated the ser/de to use
the latest `alloc` API (which is much simpler than the API used
in xous-ipc because it is no-alloc).
I'll try and run some tests that involve the TLS crate too down
the road under the theory that it would suss out any porting
errors.
