Adapt to gpio_cdev

[ohmyarch]

https://github.com/rust-embedded/gpio-cdev

Sysfs interface for GPIO is now deprecated: rust-embedded/rust-sysfs-gpio#38

I'm using kernel 5.11 and the old way does not work any more.

[caemor]

Hello Ohmyarch,
you can use this crate with whatever driver you want. Currently linux-embedded-hal is only added for the examples (also afaik the latest stable linux kernel is v5.6 :-o) . So if you already want to use this crate with gpio_cdev use it with linux-embedded-hal = { version = "0.3", features = ["gpio_cdev"] }

But I will try to add an example for it soon

[ohmyarch]

Thanks, I'm trying it.

let line = chip.get_line(8).unwrap(); //CE0
let handle = line.request(LineRequestFlags::OUTPUT, 1, "test").unwrap();
let cs = CdevPin::new(handle).unwrap();

Error(Msg("linehandle request ioctl failed"), State { next_error: Some(Sys(EBUSY)), backtrace: InternalBacktrace { backtrace: None } })

lsgpio | rg CS0

line  8: unnamed "spi0 CS0" [kernel output active-low]

It seems that we cannot get a linehandle of gpio8 because the kernel is using it for /dev/spidev0.0.

[caemor]

A possible solution for you: Use a different pin for the cs pin.

The problem at hand is that I am currently handling the CS for spi myself, since the spi trait isn't specifying how it will be handled. There is an ongoing discussion for improving this situation here: rust-embedded/embedded-hal#180

And a bigger quote from the specific current doc (https://docs.rs/embedded-hal/0.2.3/embedded_hal/spi/trait.FullDuplex.html) :

• It's the task of the user of this interface to manage the slave select lines
• Due to how full duplex SPI works each read call must be preceded by a send call.
• Some SPIs can work with 8-bit and 16-bit words. You can overload this trait with different Word types to allow operation in both modes.

[ohmyarch]

It works, thanks.

[caemor]

Let's leave it open as a reminder for myself to look for a better solution

[ohmyarch]

Maybe add something like NoOutputPin?