Add support for I2C via sysfs provider about diozero HOT 14 CLOSED

Challenge accepted.
Actually been on my to-do list for sometime now. Last I had a look it would require a small bit of C code for the some of the low-level I/O commands.
Note my Odroid C2 sysfs implementation provides PWM support (I might need to commit all my latest changes).
Do you have any other boards in mind plus are you able to provide any test support? I have rPi, BeagleBone Black and Odroid C2.

from diozero.

I own C.H.I.P. that was only 9USD and had it in mind. Library support for it's low level comms is rather scarce because it seems like it's user base focuses on using it as yet another retro games emulator but it's IO seem quite decent (side note: I wouldn't mind if it had more than one PWM pin).
C.H.I.P.'s sysfs provides:

• 3 I2C buses
• 1 hardware PWM out
• a bunch of GPIO pins

I have tested GPIO support through sysfs on C.H.I.P. and was able to open GPIO pin and write to it (tested using blink() method) without any issues so it may be fairly safe to assume that sysfs is quite universal and could be depended on. Let's hope the same translates to using I2C bus.

I would be more than happy to test anything that's needed. I don't yet own much hardware to test logic changes but I think I'll need to consider something.

from diozero.

I've just done a commit and push to staging repositories to include support for I2C natively within Java. It was fairly straightforward, although I've done very limited testing so far and only on the Raspberry Pi. It does however require a single native method that I have added to the existing native system-utils library. You would need to compile this library on the CHIP and we can then add to the diozero-core library (you should be able to test with it just in your library path). I would also need to know what "cat /proc/cpuinfo | grep Revision" returns on the CHIP. I have ordered one but it will be a couple of weeks before it is delivered.

from diozero.

I checked out new changes, made core and provider-sysfs jars, compiled libdiozero-system-utils on CHIP and included it in class path. I hoped to test it with my I2C LEDs hooked up but realised they must have broke in the mean time since they don't show up in i2cdetect anymore. I've ordered new ones.
I attempted to instantiate new I2CDevice regardless but DIO-Zero throws java.lang.UnsupportedOperationException: I2C not supported at com.diozero.internal.provider.sysfs.SysFsDeviceFactory.createI2CDevice(SysFsDeviceFactory.java:126)
I take it it's because it can't see any devices on I2C bus.

Full output of /proc/cpuinfo:

processor	: 0
model name	: ARMv7 Processor rev 2 (v7l)
BogoMIPS	: 429.72
Features	: half thumb fastmult vfp edsp thumbee neon vfpv3 tls vfpd32 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x3
CPU part	: 0xc08
CPU revision	: 2

Hardware	: Allwinner sun4i/sun5i Families
Revision	: 0000
Serial		: XXXXXXXXXXXX

from diozero.

I've just commited changes that hopefully includes support for CHIP and I2C via sysfs (not sure why you got I2C not supported - shouldn't have got that if you had latest code / JAR files). Code updated in github and new 0.9-SNAPSHOT builds pushed. You'll need to make sure you check out the system-utils-native project and run a make. It would be great if you could add the library to diozero-core/src/main/resources/lib/chip or attach the file here and I will add.

from diozero.

I finally had some time today to sit down with it properly. I2CDevice is now successfully instantiated on CHIP and seems to be working although I won't be able to test actual communication until new LEDs arrive. There were few other bugs I had to fix to make it work (broken references) so made a pull request with changes.

from diozero.

Awesome, thanks and apologies for the compilation error in HEAD - cardinal sin (too many things going on)! I look forward to getting my own CHIP.
The native I2C / GPIO code via sysfs is looking promising, I've tested it on Pi, BeagleBone Black and Odroid C2 with a simple I2C display, will test on other I2C devices. Next up will be SPI support, maybe also go back to the /dev/mem provider.

from diozero.

FYI my CHIP arrived in the post today, ran some simple GPIO and I2C tests, all ran successfully first time. Neat little device.

from diozero.

Great. My WS8212B LEDs arrived today and I planned to do some testing over the weekend but I guess its safe to assume that they'll work perfectly in this case.

from diozero.

Out of curiosity how do you plan to control the WS281B LEDs? The library in diozero is Raspbery Pi specific unfortunately as it relies on a Raspberry Pi specific library https://github.com/jgarff/rpi_ws281x.

from diozero.

I was going to write my own driver to control them. That library uses PWM which seems bizarre to me because I'm pretty sure they can be made to work with I2C but I won't know for sure until I do my research. If my assumptions prove to be correct then I will consider publishing it and maybe incorporate it in diozero to provide a more universal driver.

from diozero.

I was going to test GPIO on CHIP once more with a simple LED and noticed diozero throws NullPointerException when trying to instantiate an LED on pins >8 which of course is a problem since CHIP's pin addressing for common GPIOs ranges between 1013:1020 on latest kernel (4.4.13-ntc-mlc). See stack trace:

Exception in thread "main" java.lang.NullPointerException
	at com.diozero.util.BoardInfo.isSupported(BoardInfo.java:80)
	at com.diozero.internal.spi.BaseNativeDeviceFactory.provisionDigitalOutputPin(BaseNativeDeviceFactory.java:149)
	at com.diozero.api.DigitalOutputDevice.<init>(DigitalOutputDevice.java:92)
	at com.diozero.api.DigitalOutputDevice.<init>(DigitalOutputDevice.java:73)
	at com.diozero.api.DigitalOutputDevice.<init>(DigitalOutputDevice.java:58)
	at com.diozero.LED.<init>(LED.java:67)

Attempts of instantiating LED on pins <=8 of course results in Error setting direction for GPIO 0 since they don't exist.

Exception in thread "main" com.diozero.util.RuntimeIOException: Error setting direction for GPIO 0
	at com.diozero.internal.provider.sysfs.SysFsDeviceFactory.export(SysFsDeviceFactory.java:192)
	at com.diozero.internal.provider.sysfs.SysFsDeviceFactory.createDigitalOutputPin(SysFsDeviceFactory.java:120)
	at com.diozero.internal.spi.BaseNativeDeviceFactory.provisionDigitalOutputPin(BaseNativeDeviceFactory.java:160)
	at com.diozero.api.DigitalOutputDevice.<init>(DigitalOutputDevice.java:92)
	at com.diozero.api.DigitalOutputDevice.<init>(DigitalOutputDevice.java:73)
	at com.diozero.api.DigitalOutputDevice.<init>(DigitalOutputDevice.java:58)
	at com.diozero.LED.<init>(LED.java:67)
	at com.Test.Main.main(Main.java:35)
Caused by: java.io.IOException: Unknown error 517
	at java.io.FileOutputStream.writeBytes(Native Method)
	at java.io.FileOutputStream.write(FileOutputStream.java:326)
	at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221)
	at sun.nio.cs.StreamEncoder.implClose(StreamEncoder.java:316)
	at sun.nio.cs.StreamEncoder.close(StreamEncoder.java:149)
	at java.io.OutputStreamWriter.close(OutputStreamWriter.java:233)
	at com.diozero.internal.provider.sysfs.SysFsDeviceFactory.export(SysFsDeviceFactory.java:190)

The magic number 8 seems to be coming from number of GPIO pins offered by /sys/class/gpio/gpiochip1013/ngpio which is correct. Just wondering if you stumbled upon this.

from diozero.

Do you have the latest version? I've made some changes to this recently. The code is supposed to dyanimcly map 0-8 to the 8 XIO pins using some simple lookup code. Anything 8 and up should be accessible as a GPIO pin with no mapping.
I'm away at the moment, sorry, will have a look when back.

from diozero.

Turns out my artifacts were stale. I checked out most recent changes and rebuilt them and everything's fine. False alarm.

from diozero.