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.
flatipc is a new method for doing IPC. This is a zero-copy approach
where structs are given `repr(C)` implementations that are well-defined
and work across process boundaries.
If the same struct or enum is used in two processes that has the same
layout, then data can be freely passed between the two processes without
incurring a serialization or deserialization penalty, provided the
following hold:
1. The buffer must be page-aligned and be a multiple of the page size
2. The item must be `#[repr(C)]`
3. There must be no pointers or references of any kind
If these three things hold, then the object is safe to sling across the
process boundary.
This crate adds the ability to annotate structs with
`#[derive(flatipc::Ipc)]` to provide them with this functionality. When
doing so, objects gain the `.into_ipc()` call that turns them into
something that can be sent across process boundaries.
The resulting object has `.lend()`, `.lend_mut()`, `.try_lend()`, and
`.try_lend_mut()` as functions.
Signed-off-by: Sean Cross <sean@xobs.io>
a bunch of lines are shorter or different length now which
triggers a mandatory reformat. this patch cleans that up,
so that going forward the manual rework patches are clearer and
not tied up with formatting patches.
the filter is on by default (which blocks all DMA access with
the null settings) and can be configured to restrict access to
regions of memory that contain secret materials.
