Is the CS pin really needed?

[matz-e]

First of all, thank you for this crate! I'm using it with the #14 to drive a what, and it works very well.

When I first set up my display, I found out first that I had to use CdevPins to drive the interface (this is on the 64bit beta of Raspian), and that the CS pin should just be set to a random unused pin. Otherwise, the CdevPin creation would fail with a "busy" pin or similar. This took me a while to realize :(

I see that the CS pin usage seems to be actually commented out:

ssd1675/src/interface.rs

Line 118 in 4852726

// self.cs.set_low();

and

ssd1675/src/interface.rs

Line 131 in 4852726

// self.cs.set_high();

Would it be possible to either remove it from the interface or augment the documentation for the new cdev GPIO?

[wezm]

Hmm interesting. I wish my past self had documented that better. It seems I commented them out in 204f654 which suggests it was required to get the Inky pHAT working. Presumably I meant to come back to it but never did.

This codebase was based on epd-waveshare and their implementation does manipulate CS. I think this driver should use chip select, otherwise I think you can only have one child device on the bus. I'll try to allocate some time to digging out my display in the near future to play around with it and see what I can work out.

What are the CdevPins? Where do they come from?

[matz-e]

I didn't find a lot of information about it. From the gpio-cdev crate, with a bit more information in the README:

rust-gpio-cdev is a Rust library/crate providing access to GPIO character device ABI. This API, stabilized with Linux v4.4, deprecates the legacy sysfs interface to GPIOs that is planned to be removed from the upstream kernel after year 2020 (which is coming up quickly).

I'm hypothesizing that the Spidev itself may occupy the pin itself, and the new API locks it as busy? I should read up on this in the source…

I'm running the 64bit beta of Raspian on my Pi (with a 5.4 kernel), and did not even have the sysfs interface. Setting up the pins is pretty much a drop-in in my playground project.

Edit: found caemor/epd-waveshare#42, which seems to be the same issue.

[Thra11]

I had to use gpio-cdev as well. I didn't have your busy pin issue, although I am using an Orange Pi Zero2 Plus H5, not a raspberry pi, so there may be some differences.

Have you tried using libgpiod command line tools such as gpioinfo to work out whether something else on your system has actually claimed the GPIO you want to use for CS?

If you suspect spidev is using it, you could also have a look at the devicetree (either look at the relevant .dts files if you have them, or run fdtdump on the .dtb which it uses to boot) to see what pins it specifies for your spi device.

[Thra11]

I assume if you only have one chip attached to your SPI chain, you can get away with leaving the corresponding chip select pin active all the time. The chip will listen to everything, but since everything is destined for that chip, it should still work. Not sure if that's what's happening here. If that is the case, then it's possible that the interface doesn't need to manipulate the CS pin (as long as there's only one chip), but the CS pin does need to be set to the correct state initially.

[matz-e]

Thanks for the hint, I'm pretty new to this and am still missing the right tools. This is on the Raspberry Pi4, fresh after boot and a quick package install to get gpioinfo (all other pins are unused):

❯ gpioinfo
gpiochip0 - 54 lines:
…
	line   7:      unnamed   "spi0 CS1"  output   active-low [used]
	line   8:      unnamed   "spi0 CS0"  output   active-low [used]
…
	line  42:      unnamed       "led0"  output  active-high [used]
…
❯ uname -a
Linux worf 5.4.42-v8+ #1319 SMP PREEMPT Wed May 20 14:18:56 BST 2020 aarch64 GNU/Linux

I'm still wondering why the code has the cs pin usage commented out — do you use it?

[wezm]

I'm still wondering why the code has the cs pin usage commented out — do you use it?

From above:

I wish my past self had documented that better. It seems I commented them out in 204f654 which suggests it was required to get the Inky pHAT working.

I can't remember my exact reasoning but it is needed to allow more than one device on the SPI bus. I'll be doing some work on this crate in the future to try to clean it up and close off some open issues and I'll look into this further at that time.

[matz-e]

Sorry, replied after a long workday… let me know if I can help with testing future changes in any way (and thanks again for this crate) :)