[STM32] [SPI] [feature] Slave Mode Support for STM32

[ahadjeres]

Description

Currently, the Embassy STM32 SPI driver supports only Master mode. Many applications require the MCU to act as an SPI Slave to communicate with a more powerful Master or to implement certain protocols where the MCU does not drive the clock. This feature request proposes extending Embassy’s SPI driver (or creating a dedicated driver) to support Slave mode operation for STM32 devices.

Use Case / Motivation

1.	Peripheral MCU: Often, smaller or lower-power MCUs connect to a central controller (e.g., a larger MPU or another microcontroller) over SPI. In such a system, the smaller device must be configured as Slave.
2.	Performance / Protocol: Some custom or proprietary protocols mandate that the device be an SPI Slave to offload tasks to a Master.
3.	Better Coverage: Supporting SPI Slave mode in Embassy would broaden the library’s coverage and remove the need for manual register-level configurations or external HAL usage.

Proposed Approach

•	API: Extend or add an SPI trait that abstracts both Master and Slave usage.
•	Configuration: A Config object that includes a mode enum (Master or Slave).
•	Implementation details:
•	Potentially re-use the existing DMA approach for data in/out, if possible.
•	Must handle NSS pin as input or software-based.
•	Must handle TXE/RXNE interrupts (or DMA events) appropriately in Slave mode, which differs slightly from Master flow.
•	Edge cases such as busy detection, “dummy” data when Master is reading, or receiving data when Master is writing more than expected.

I would love input from the maintainers and community on whether:

•	This feature is in line with Embassy’s roadmap.
•	There’s any existing partial or experimental implementation for Slave mode.
•	Particular STM32 series or embedded scenarios where Slave mode is most critical.

Tx
Ahmed

[joelsa]

Configuration: A Config object that includes a mode enum (Master or Slave).

Dirbaio wrote regarding this:

I think it would be best if the SPI slave driver was a separate struct, instead of a "mode" in the same SPI struct. The reason is they're fundamentally very different, so they require different APIs.

In this PR: #885