Using SpiDevice instead of SpiBus plus Chip Select

Julian,

I have tested this driver with the following device: https://www.waveshare.com/wiki/RP2040-Touch-LCD-1.69

I have built display drivers for different displays. While the SpiDevice abstracts away from the ChipSelect, I wanted to keep the driver very simple and have explicit control. I also wanted the driver to be readable so someone else could use it. Changing the driver to use the SpiDevice would be a small change. In fact, I have switched between the two implementations before.

If you want to propose some changes or work with me on a version that is based on SpiDevice, I am happy to help. :)

Also, I am excited that someone is looking at my code.

Direct Control Over Chip Select (CS) With SpiBus, you have explicit control over the chip select (CS) pin. This allows for more granular control over the timing and toggling of CS, which is crucial in some cases where a device’s communication protocol requires more precise or customized handling of the CS pin. Some peripherals, particularly complex ones like displays, may require unconventional CS timing sequences, which can be hard to achieve through the more abstracted SpiDevice.
Performance Optimization SpiBus allows for more efficient communication because it provides direct access to the SPI bus. When using SpiDevice, the framework may abstract away some of the hardware details and add overhead, particularly when dealing with shared bus devices. In performance-critical applications, where raw throughput and low latency are essential, SpiBus may be more advantageous since you can fine-tune SPI communication and ensure minimal overhead.
More Flexibility in Handling Multiple Devices When managing multiple SPI devices on the same bus, the use of SpiBus gives you direct control over when to assert and de-assert the CS pin. In contrast, SpiDevice abstracts this, and in cases where you need to tightly manage several devices with different timing requirements, SpiBus provides the flexibility needed for optimal performance.
Advanced Bus Control Features Some advanced features, such as multi-device handling, may be easier to implement using SpiBus directly. For instance, if you need to manage complex bus-sharing logic (such as communicating with multiple devices that may use different settings or protocols on the same bus), SpiBus can give you full control over how data is sent and managed.
Testing and Debugging Simplicity While SpiDevice simplifies working with SPI devices by handling the CS pin internally, this abstraction can make debugging more difficult in certain situations. If you need to trace specific communication problems related to the CS pin or SPI transactions, using SpiBus might make it easier to pinpoint issues, as you have control over every stage of the transaction.

On Wed, Sep 25, 2024 at 8:23 AM Julian Büttner @.***> wrote:

Hello,

according to the official embedded HAL traits, it is encouraged to use an SpiDevice where ever possible, instead of requiring the entire SpiBus and an extra chip select pin (CS) (see here https://docs.rs/embedded-hal/latest/embedded_hal/spi/index.html#for-driver-authors ).

Also thank you for implementing the ST7789v2 standard and all relevant traits from all relevant crates. I am currently figuring out how to get my display to do anything, but I think I'm close. Have you tested the library already?

Kind regards Julian

— Reply to this email directly, view it on GitHub https://github.com/GordonCox/st7789v2_driver/issues/1, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFMTLGHTAEQRSWEWCJVXSL3ZYLIQJAVCNFSM6AAAAABO2ZTEQCVHI2DSMVQWIX3LMV43ASLTON2WKOZSGU2DQMRZHEYTINI . You are receiving this because you are subscribed to this thread.Message ID: @.***>

GordonCox / st7789v2_driver

Using SpiDevice instead of SpiBus plus Chip Select #1