Some traits needed to implement, in order to use
The minimum would be to implement DcxPin and one of WriteU8 and
WriteU8s, then use an
adapter to complete the missing
one of WriteU8 and WriteU8s. With these, the write parts of
are already usable.
Note that the SPI protocol of ST7735’s write commands
are actually compatible with command SPI implementations of
microcontrollers, eg., STM32 SPI with
CPOL=1 (clock idles at high) and
CPHA=1 (data sampled at the second edge) without an SS pin. An example
can be found at examples/stm32f3348_disco.
If the user also needs to read data from the ST7735, then Read and ReadBits should also be implemented. Presumably no high performance is needed because reading is mostly for debugging purposes; the dummy bit when reading 24- or 32-bit data is quite annoying (not totally impossible to implement with hardware SPI but quite challenging); and when reading, the clock must toggles slower than when writing (so the user needs to reconfigure the SPI anyway). Therefore, it is recommended that the user simply implements ReadBits::read_bits() with bit-bangs.
The reason to allow the user to implement WriteU8 and WriteU8s separately is for better performance. While it is natural to think WriteU8s as a looped version of WriteU8, there can be quite some latency and throughput differences. Eg., in a STM32 microcontroller, A loop-based WriteU8s is suboptimal for the following reasons:
- As soon as a byte is started to be sent, the user can already write the next byte to SPI’s TX FIFO buffer. But WriteU8::write_u8() finishes only after the previous byte is fully sent to the device.
- DMA (direct memory access) is also very beneficial for WriteU8s, especially when sending many bytes.
So the user should only use an
AdapterU8 if they doesn’t care
about the performance difference here.
Defines how the
Defines how the MCU should use the
Defines how the helper RAII variable returned by Read::start_reading() should behave.
Defines how a single u8 is written with the
Defines how a sequence of