Blocking SPI slower than it needs to be?

[timbod7]

I'm trying to understand why my SPI LCD display updates are slower than I would expect. I'm using a blue pill board, and driving the display with this library:

https://github.com/yuri91/ili9341-rs

The ili9341-rs library relies on the blocking SPI implementation. I've just noticed that this stm32f1xx-hal crate relies on the default implementation of the blocking Write trait:

https://github.com/stm32-rs/stm32f1xx-hal/blob/master/src/spi.rs#L321

and this default implementation wait for received bytes, despite discarding them:

https://docs.rs/embedded-hal/0.2.3/src/embedded_hal/blocking/spi.rs.html#72

Is this actually necessary with the stmf1xx processors? Would a hand written Write trait without the blocking read work correctly and return faster?

[timbod7]

I've just looked at the implementation of the FullDuplex trait, and the STM32F1 reference manual, and see that Overrun errors will be generatd if the rx register is not read.

[therealprof]

That's how SPI works in general. There might be room for a specialised uni-directional communication but that would probably not something that just works in a generic way.

[timbod7]

I was expected the blocking write buffer method to be able to fully utilize the SPI bandwidth, but in practice I am seeing ~3us idle between bytes written.

I guess DMA is the solution for this...

[TheZoq2]

Yea, I don't think you'll be able to completely avoid delays without DMA.

[timbod7]

DMA will be fastest of course, but there seems to be some value in improving the blocking Write implementation given that existing drivers use it.

With a 32Mhz sysclk, and 16Mhz spi speed, this proposed change:

#181

improves performance from ~3.7us per byte to ~1.2us per byte.

[therealprof]

Looks good to me. But I can't test it at the moment.

[TheZoq2]

Fixed in #181