`Spi` API about embedded-hal HOT 3 CLOSED

Hi,
it would be of great help to have a function here to set the SPI clock frequency.
As an example, MPU6000 is mostly connected via SPI to µC. This chips starts in I2C mode, so it needs SPI clock of below 400kHz. After you configure the MU6000 to use SPI mode you can use ~8MHz SPI clock to fasten up transfer.
This is a valid use case where you need a set_spi_frequency() function at a relative high abstraction level (abstracting the whole MPU6000 chip in a crate), independent from sharing some µC knowledge of how to set SPI clock frequency.

from embedded-hal.

I recently wrote two crates (mfrc522 and mpu9250) to interface two different SPI devices. These
crates use the traits in this embedded-hal repo and have been tested to work with Cortex-M
microcontrollers (no_std, svd2rust API) and the Raspberry Pi (std, spidev API).

I wanted to jot down some things I noticed while writing these crates.

(I would suggest reading RFC rust-embedded/svd2rust#157 first. It contains some ideas on using move
semantics (the type system) to enforce driver correctness (prevent misuse) at compile time. These
ideas have heavily influenced how I've written the aforementioned SPI device crates)

• SPI devices can operate in different modes. Your SPI peripheral must be configured to operate in
  the same mode or you won't be able to interface a SPI device.

Would it be practical (ergonomics correctness trade-off) to encode the mode in the type system? As
in the type system would force you to configure the SPI in the correct mode to be able to use a
driver.

Is there an use case for switching the mode of a SPI peripheral at runtime? Or is it always a set once and forget setting?

If we want to do this I don't think the SPI trait should contain the mode as a type parameter but
for code sharing the mode types should live in the embedded-hal crate. (I already added some mode related Polarity / Phase enums to embedded-hal)

• A single SPI master can interface with several slaves by individually "selecting" them (driving
  some digital I/O low).

Background: In my crates I modeled the device drivers as struct Driver { spi: impl Spi, nss: impl OutputPin } that is the driver takes ownership of both the spi peripheral and the slave select pin.
This is a bit incompatible with multi-slave applications where you have a single SPI peripheral that
you want to use with several device driver instances.

Would it be more ergonomic to change the driver struct to only take ownership of the slave select
pin, as in struct Driver { nss: impl OutputPin }, and have the API borrow the SPI peripheral, as
in impl Driver { fn do_stuff(&mut self, spi: &mut impl Spi) { .. } }. Would this approach be still
be correct?

I consider the fact that these potential improvements don't require modifying the existing methods of
the Spi trait a good sign :-).

from embedded-hal.

The spi::FullDuplex and blocking::spi::{Transfer,Write} traits are now part of a crates.io release so I'm going to close this. If you encounter any problem implementing / using those traits feel free to open a new issue!

If you want to propose adding futures or generator based SPI traits you should open a new RFC issue.

from embedded-hal.