Proposal: SPI HalfDuplex and Device traits

[no111u3]

Currently SPI have one model of work - Master + FullDuplex. But some mcu and mpu have more intelligence SPI implementation: HalfDuplex, variable length of transfer (4 - 16 bit), Device mode. I thinks we need to add HalfDuplex and Device trait for current SPI interface. Also I think that adding of 8:16 bit transfer is not difficult.

[dzarda]

IMHO half duplex will see most usage among features you mentioned.

[ryankurte]

hey, thanks for opening an issue, a few questions and comments:

• what do you mean by half duplex? afaik this is covered by theblocking::spi::Write trait.
• as far as variable length transfer goes, the SPI traits are currently generic over W allowing implementations to define supported word sizes (though in practice I haven't seen any non-u8 implementations yet). static definition of variable length transfer thus would involve adding implementations or bindings for the relevant word sizes, is this unsuitable for a particular application?
• Device mode certainly would be interesting! There's a related issue for I2C here https://github.com/rust-embedded/embedded-hal/issues/179

[dzarda]

@ryankurte half duplex references a bidirectional mode where MISO and MOSI are shared (one signal). Master then generally needs to:

1. write multiple bytes (driving "MOSO")
2. read multiple bytes (sensing "MOSO")

Please see BIDIMODE and BIDIOE bits from STML0x3 manual (SPI control register 1):

[therealprof]

@dzarda Sure, but why do you need special traits for that case? The traits only care about the data transfer, not the initialisation or the hardware connected to it. So unless I'm missing something here you only need to have a HAL impl that provides a half-duplex setup but the usage would be exactly the same.

[ryankurte]

@ryankurte half duplex references a bidirectional mode where MISO and MOSI are shared (one signal).

Ahh, that makes sense, thanks!

So unless I'm missing something here you only need to have a HAL impl that provides a half-duplex setup but the usage would be exactly the same.

I guess we're missing a Read trait to support this?

[hannobraun]

@ryankurte

the SPI traits are currently generic over W allowing implementations to define supported word sizes (though in practice I haven't seen any non-u8 implementations yet).

Here: https://github.com/stm32-rs/stm32f7xx-hal/blob/master/src/spi.rs Specifically: https://github.com/stm32-rs/stm32f7xx-hal/blob/af6900285648d48decb8ac5e0f8c74ef72e5ec4b/src/spi.rs#L738-L763

[therealprof]

I guess we're missing a Read trait to support this?

Not sure, you still have to clock out a number of Words to do the Reads so I guess the question really boils down to whether this already possible in an efficient way now. If the answer is no, then we'll need a Read trait.

[dzarda]

blocking::spi::Write - sure, that could be used for sending data. But the receive functionality is simply absent. It's not a matter of efficiency AFAIK, I don't see a way of mapping this onto current API.

[dzarda]

I evaluated the idea on the STM32L0x3 where the "bidirectional" receive behaviour is to output SCK clock with BIDIMODE=1 and BIDIOE=0. Not sure how to map this onto some API. More devices should be researched.

[ierturk]

Is there any update?