SPI slave support

[LinusU]

(first of all, thanks for all the amazing progress with Rust support for the ESP32, it truly is amazing!)

I'm trying to build an ISP slave device using the ESP32, and of course I want to build it using Rust. However, it seems like there is no support fir this currently?

If I understand correctly, the SPI traits in embedded-hal is only for SPI master, and when slave traits will be added they will be separate and probably named spi_slave. ref: rust-embedded/embedded-hal#396. And as far as I understand, esp-hal is an implementation of embedded-hal?

It seems like the only way right now is to use Rust with the ESP IDF (e.g. using ), and then call the C functions (spi_slave_initialize, spi_slave_transmit, etc.) via the esp_idf_sys crate?

If my understanding is correct, than this is a feature request to add SPI slave support. In either case, any pointers or guidance would be much appreciated!

---

• ESP32 (Mode 1 and 3) ESP32 spi slave mode #2278
• ESP32-C2
• ESP32-C3
• ESP32-C6
• ESP32-H2
• ESP32-S2
• ESP32-S3

[bjoernQ]

Yes, we implement SPI traits from embedded-hal which all define only 1 bit full-duplex master mode.
We also have some additional functionality like half-duplex, dual and quad SPI

Technically we can define our own API to add SPI slave support (like we had to do for e.g. I2S before)

TL;DR this is a feature request for SPI slave functionality 😄

[Studiedlist]

As far as I understand from reading #580, slave driver for ESP32 and ESP32-S2 is not implemented due to pdma issues.

I could try to investigate this and add implementation if someone guide me through codebase a little bit so I can understand how to get started

[Studiedlist]

I browsed through available spi options and found some things that could help make it work.
According to esp32::spi0::clock::W documentation and esp32 datasheet, all of its options should be set to 0 in slave mode.
So I added the following to start_read_bytes_dma:

reg_block.clock.modify(|_, w| {
    w.clkdiv_pre().variant(0)
    .clk_equ_sysclk().clear_bit()
    .clkcnt_l().variant(0)
    .clkcnt_h().variant(0)
    .clkcnt_n().variant(0)
});

There are also dma_int_ena::in_done_int_ena and dma_int_ena::in_suc_eof_int_ena bits that enable dma interrupts, but I don't know are they used in current driver.

The next observation is that slave::slv_last_state_bit is working correct, so, I think, dma is handling transaction, but there is something with ch.tx and ch.rx.

Unfortunately, I cannot find actual Rx and Tx implementation since Spi2DmaChannelRxImpl is generated with macro, so I cannot debug rx/tx internals

[Studiedlist]

I have also written sketchy interrupt-based no-cs slave driver:

#[interrupt]
fn GPIO() {
    critical_section::with(|cs| {
        let mut slave = CLK.borrow_ref_mut(cs);
        let slave = slave.as_mut().unwrap();

        let mut timer = TIMER0.borrow_ref_mut(cs);
        let timer = timer.as_mut().unwrap();

        timer.start(100u64.millis());

        let input = slave.mosi.is_high().unwrap();

        slave.end = false;

        slave.buf_n += (input as u8) << (7 - slave.c);
        slave.c += 1;
        if slave.c == 8 {
            slave.c = 0;
            slave.buf.push(slave.buf_n);
            slave.buf_n = 0;
        }
        slave.clk.clear_interrupt();
    });
}

#[interrupt]
fn TG0_T0_LEVEL() {
    critical_section::with(|cs| {
        let mut timer = TIMER0.borrow_ref_mut(cs);
        let timer = timer.as_mut().unwrap();

        let mut slave = CLK.borrow_ref_mut(cs);
        let slave = slave.as_mut().unwrap();

        if slave.end == false {    
            println!("{:?}", slave.buf);
            slave.buf = Vec::with_capacity(110);
            slave.c = 0;
            slave.buf_n = 0;

        }
        slave.end = true;

        if timer.is_interrupt_set() {
            timer.clear_interrupt();
        }
    });
}

It works fine except low speed (about 10kHz).
Could such approach be correct for no-dma implementation?

[bjoernQ]

Thanks for working on this!

Regarding the interrupt-based implementation I guess we shouldn't include bit-banging protocol implementations in the HAL. Those could go into a 3rd party crate I guess

[Studiedlist]

Unfortunately, I was unable to figure out what was wrong with ESP32, but I've got ESP32S3, and now test SPI slave with it.
Example is working with Raspberry PI as master, but whenever I change dma_transfer to dma_read, wait call is stuck forever.

I browsed through source code, and spotted strange check at DmaTransfer::is_done for dma_read. I've removed ch.tx.is_done(), and now dma_read is working.
Could it be a mistake, or ch.tx.is_done() is required in case of dma_read?

[Studiedlist]

By the way, current implementation of SPI slave for ESP32S3 is capable of handling insane clock speed of 10mHz.
Thank you all for this feature

[bjoernQ]

Unfortunately, I was unable to figure out what was wrong with ESP32, but I've got ESP32S3, and now test SPI slave with it. Example is working with Raspberry PI as master, but whenever I change dma_transfer to dma_read, wait call is stuck forever.

I browsed through source code, and spotted strange check at DmaTransfer::is_done for dma_read. I've removed ch.tx.is_done(), and now dma_read is working. Could it be a mistake, or ch.tx.is_done() is required in case of dma_read?

I think the intent is to make sure that all bits are clocked out on MOSI - but probably a good hint what to look at. Maybe just checking rx.is_done() should be good enough in reality

[Studiedlist]

Now I see the reason: there is only one implementation of wait for both read and write transfers, so both ch.tx.is_done() and ch.rx.is_done() are required.

According to datasheet, GDMA_OUT_TOTAL_EOF_CH interrupt, which is used to determine if tx channel is done:

triggered when all data corresponding to a linked list (including
multiple descriptors) have been sent via transmit channel n

There is no exact information on whether it is fired when tx list is empty. But, as far as I understand, no transmission takes place when there is nothing to send, so GDMA_OUT_TOTAL_EOF_CH will not be triggered.

I think, the problem can be solved by introducing different SpiDmaTransfer structs for read and write, like SpiDmaTransferRead and SpiDmaTransferWrite.