Open Maldus512 opened 3 years ago
Hi,
the FullDuplex
trait unfortunately has an API that cannot be safely shared in the way shared-bus
solves sharing. The reason is that there is an implicit dependency between calls to send()
and read()
which could be broken if multiple bus users interweave these calls. For example:
User 1 User 2
| |
send() |
| |
| send() - - # Now received byte from first send is discarded (or worse)
| |
read() - - - - - - - - - - # Reads data from second write
|
read() - - # HAL-API violation!!
Because this is impossible to map to a shared design safely, only the APIs from embedded_hal::blocking::spi
are supported as they do not suffer this problem (but come with their own share of issues ...).
I understand, that's unfortunate. I will find another way to share my bus when FullDuplex
is required.
What do you think is possible evolution of this issue? Are you going to leave it aside for now, or are you waiting for suggestions? I'm asking just out of curiosity because it seems quite a sizeable problem, and even if I only used it superficially shared-bus
looks like a very promising library.
Hello, I stumbled upon the issue of bus sharing among device structs and I was trying to use
shared-bus
to solve it. Although it looks very promising I was stopped immediately be the fact thatSpiProxy
does not emplement theembedded_hal::spi::FullDuplex
trait, which I need to use[embedded_sdmmc](https://docs.rs/embedded-sdmmc/0.3.0/embedded_sdmmc/struct.SdMmcSpi.html)
.I was wondering if there is a particular reason for this missing implementation, if it's scheduled for a later date (I couldn't find it in the roadmap) or if it was simply missed (the
FullDuplex
trait is in a different module fromembedded_hal::blocking::spi::{Write, Transfer}
, which are actually implemented).