Add SpiBus, SpiDevice implementations #181
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We're testing unsafe code in the HAL. Make sure miri is happy with that unsafe code. We build with minimal optimizations by default, no matter the target. Turn those off during the miri invocation.
When we support the embedded-hal 1.0 traits, we should distinguish between the bus -- having the data and clock pins -- and the device(s), which have the chip select. Removing the chip select type state is the first step in supporting this interface. Temporarily enable PCS0 in the board setup routines. This keeps the examples working as expected.
We'll need something like this when we implement SPI devices.
This'll make it easier to associate bus state with each transaction.
Default behavior is unchanged, in that the mode is still set by the user's `Lpspi::set_mode` value. But now users could define it as part of a one-off transaction.
On the RT1180, these two fields are WO/RAZ. Since we can't trust the hardware to retrieve these values for us, we cache them in memory. Writes will behave as before. The driver ensures that all accesses on CCR pass through the cache.
This reverts commit 0cb3b8d.
We implement all I/O in terms of `transact`. We'll manually flush at the end of eh02 SPI writes. Since the `SpiBus` interface exposes a flush, we have no need to perform an internal flush when transacting I/O. Keep the spinning async state machines to manage the TX and FX FIFOs. We introduce a schedule to eagerly execute transmit operations ahead of receive operations. Without this ability, we'll stall the LPSPI bus. (The NOSTALL field can change this behavior, but then we move complexity into TX FIFO underrun handling.) There's some miri tests to simulate our hardware utilization. Our `SpiDevice` impls mimic the embedded-bus design. There's an "exclusive" device that owns the bus and uses a hardware chip select. There's a `RefCellDevice` that lets users share the bus and use hardware chip selects. There's no critical section / mutex device, but it should be straightforward to add that later.
mciantyre
force-pushed
the
lpspi-refactor
branch
from
402580a to
2c3593a
Compare
|
Thanks for working on this, I wasn't able to continue my work due to personal things, sorry :) glad to see you are still motivated <3 |
mciantyre
force-pushed
the
lpspi-refactor
branch
from
2c3593a to
870939e
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We implement all I/O in terms of
transact. We'll manually flush at theend of eh02 SPI writes. Since the
SpiBusinterface exposes a flush, wehave no need to perform an internal flush when transacting I/O.
Keep the spinning async state machines to manage the TX and FX FIFOs.
We introduce a schedule to eagerly execute transmit operations ahead of
receive operations. Without this ability, we'll stall the LPSPI bus.
(The NOSTALL field can change this behavior, but then we move complexity
into TX FIFO underrun handling.) There's some miri tests to simulate our
hardware utilization.
Our
SpiDeviceimpls mimic the embedded-bus design. There's an"exclusive" device that owns the bus and uses a hardware chip select.
There's a
RefCellDevicethat lets users share the bus and use hardwarechip selects. There's no critical section / mutex device, but it should
be straightforward to add that later.
Part of #142.