Extend support for Raspberry Pi 5: PWM and SPI

[FDelporte]

• Should be implemented using the Linux Kernel APIs.
• Integrate in the GpioD plugin added in 2.5.0?

https://docs.kernel.org/driver-api/pwm.html https://www.kernel.org/doc/html/v4.14/driver-api/spi.html

[mpilone]

I need SPI support on Pi5 to drive an SSD1306 OLED. I ended up on this ticket when I saw Pi4J doesn't support it yet. I don't have the time to fully integrate a solution, but I did come up with a quick implementation using JNA for the native bindings that demonstrates how to talk to the Linux SPI device. I don't think it would be hard for someone to do the actual integration into Pi4J.

I assume you'd want to rewrite the JNA calls into pure JNI to match the existing pattern, but JNA can save you a good bit of custom native code. The existing LinuxFS class gives you most of what you need, but you'll have to add an ioctl call that can pass a structure and all the JNI magic to read/write the structure.

Thanks for making this library available. Hopefully this helps speed the SPI implementation for Pi5.

JnaSpiPi5.zip

[eitch]

Hi @mpilone Thanks, that does look easier. Maybe you could put it in a pull request? I don't know JNA, and would really appreciate that a lot! I would then check the code and try and test it with other SPI devices.

[taartspi]

I have not looked into that zip that was provided.   Early summer I spent sometime researching the kernel API.  The documentation for the new 6.x kernel is terrible.   After a bit of time I decided to use ioctl.   I coded up the library portion and tested I could control a neopixel LED string using ioctl.  I am in the process of debugging the new provider code I wrote so a normal testcase can use the provider and control the neopixel.

My intent with the provider is support the same interfaces and Config as the existing pigpio-spi provider. So a user could simply change the provider used and their existing code would function. But, there are flags bits specific to pigpio provider and no longer applicable to Pi5.

I wasn't sure if the ioctl usage would be rejected as we wanted to move to the APIs.   I used JNA to connect to the 'C' library.   I created needed declarations to use JNA for the structures used by ioctl.
I have some questions to answer as far as the JNA path. Our practice of creating our own version of the kernel library code is needed as we support multiple ways for the .so to be located. This JNA usage requires more code be duplicated. For the moment to test I set the JNA path explicitly in the java code, I want to research setting it when we first determine where the library is located.

The code needs synchronization added, complete decoding flags config values and setting the ioctl based upon those, complete the functions

I will push this code so we have something else to use in this SPI conversation

[mpilone]

I created a PR for my implementation. As the PR says, it introduces a dependency on JNA and I only tested the write operations for use with an OLED. Use it how you like. If you keep the JNA approach, you could do the same with gpiod and remove the custom C JNI code. Just load libgpiod.so and let JNA handle the bindings dynamically.

[taartspi]

391 PR involving ioctl/JNA Intend is, between mpilone and this we likely have much of the SPI support for Pi5