Struct embedded_hal_bus::spi::CriticalSectionDevice

pub struct CriticalSectionDevice<'a, BUS, CS, D> { /* private fields */ }

critical-section-based shared bus SpiDevice implementation.

This allows for sharing an SpiBus, obtaining multiple SpiDevice instances, each with its own CS pin.

Sharing is implemented with a critical-section Mutex. A critical section is taken for the entire duration of a transaction. This allows sharing a single bus across multiple threads (interrupt priority levels). The downside is critical sections typically require globally disabling interrupts, so CriticalSectionDevice will likely negatively impact real-time properties, such as interrupt latency. If you can, prefer using RefCellDevice instead, which does not require taking critical sections.

Implementations

impl<'a, BUS, CS, D> CriticalSectionDevice<'a, BUS, CS, D>

pub fn new( bus: &'a Mutex<RefCell<BUS>>, cs: CS, delay: D, ) -> Result<Self, CS::Error>

where CS: OutputPin,

Create a new CriticalSectionDevice.

This sets the cs pin high, and returns an error if that fails. It is recommended to set the pin high the moment it’s configured as an output, to avoid glitches.

impl<'a, BUS, CS> CriticalSectionDevice<'a, BUS, CS, NoDelay>

pub fn new_no_delay( bus: &'a Mutex<RefCell<BUS>>, cs: CS, ) -> Result<Self, CS::Error>

where CS: OutputPin,

Create a new CriticalSectionDevice without support for in-transaction delays.

This sets the cs pin high, and returns an error if that fails. It is recommended to set the pin high the moment it’s configured as an output, to avoid glitches.

Warning: The returned instance technically doesn’t comply with the SpiDevice contract, which mandates delay support. It is relatively rare for drivers to use in-transaction delays, so you might still want to use this method because it’s more practical.

Note that a future version of the driver might start using delays, causing your code to panic. This wouldn’t be considered a breaking change from the driver side, because drivers are allowed to assume SpiDevice implementations comply with the contract. If you feel this risk outweighs the convenience of having cargo automatically upgrade the driver crate, you might want to pin the driver’s version.

Panics

The returned device will panic if you try to execute a transaction that contains any operations of type Operation::DelayNs.

Trait Implementations

impl<'a, BUS, CS, D> ErrorType for CriticalSectionDevice<'a, BUS, CS, D>

where BUS: ErrorType, CS: OutputPin,

type Error = DeviceError<<BUS as ErrorType>::Error, <CS as ErrorType>::Error>

Error type.

impl<'a, Word: Copy + 'static, BUS, CS, D> SpiDevice<Word> for CriticalSectionDevice<'a, BUS, CS, D>

where BUS: SpiBus<Word>, CS: OutputPin, D: DelayNs,

fn transaction( &mut self, operations: &mut [Operation<'_, Word>], ) -> Result<(), Self::Error>

Perform a transaction against the device.

fn read(&mut self, buf: &mut [Word]) -> Result<(), Self::Error>

Do a read within a transaction.

fn write(&mut self, buf: &[Word]) -> Result<(), Self::Error>

Do a write within a transaction.

fn transfer( &mut self, read: &mut [Word], write: &[Word], ) -> Result<(), Self::Error>

Do a transfer within a transaction.

fn transfer_in_place(&mut self, buf: &mut [Word]) -> Result<(), Self::Error>

Do an in-place transfer within a transaction.