So I figured it out by now. It didn't really work with overlay but using the main .dtsi file worked. pca9635.dtsi &i2c { pca9635@8 { compatible = "nxp,pca9635"; reg = <0x08>; #address-cells = <1>; #size-cells = <0>; status = "okay"; led@0 { label = "led0"; reg = <0>; default-state = "off"; }; led@1 { label = "led1"; reg = <1>; default-state = "off"; }; led@2 { label = "led2"; reg = <2>; default-state = "off"; }; led@3 { label = "led3"; reg = <3>; default-state = "off"; }; led@4 { label = "led4"; reg = <4>; default-state = "off"; }; led@5 { label = "led5"; reg = <5>; default-state = "off"; }; led@6 { label = "led6"; reg = <6>; default-state = "off"; }; led@7 { label = "led7"; reg = <7>; default-state = "off"; }; led@8 { label = "led8"; reg = <8>; default-state = "off"; }; led@9 { label = "led9"; reg = <9>; default-state = "off"; }; led@10 { label = "led10"; reg = <10>; default-state = "off"; }; led@11 { label = "led11"; reg = <11>; default-state = "off"; }; led@12 { label = "led12"; reg = <12>; default-state = "off"; }; led@13 { label = "led13"; reg = <13>; default-state = "off"; }; led@14 { label = "led14"; reg = <14>; default-state = "off"; }; led@15 { label = "led15"; reg = <15>; default-state = "off"; }; }; }; placed in the build folder /home/thomas/openwrt-wallcontroller/target/linux/ramips/dts and lastly adding an include to the omega .dtsi mt7628an_onion_omega2.dtsi #include "mt7628an.dtsi" #include "pca9635.dtsi" #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/input/input.h>

@Ghofran-Daoues perhaps a good starting point would be HERE

@crispyoz Thanks! That's an idea - I could probably just do a bunch of register level acces to initialise the display over i2c and put up something. I'll need to do a bit of learning on uboot

@luz Thanks for the confirmation!

Hello again! The wiring is one issue (can't say for sure if it works with the expansion per se cause I have another breakout of the chip for testing purposes). Though, you can easily adapt this example -> https://www.element14.com/community/community/raspberry-pi/blog/2012/12/14/nfc-on-raspberrypi-with-pn532-py532lib-and-i2c and use I2C. Lastly, there is no official documentation regarding the schematics of the NFC/RFID expansion but our tests showed that that onion has left out SPI/I2C support for their chip -sth that needs to be checked. We are using python tools for now but I will get back to you if we find anything else!

Thank you for such an excellent reply. It points me in the right direction. We may be doing a custom U-Boot and kernel build anyhow. I am starting to become fond of this platform. I just picked up the Omega2S a couple weeks ago for the first time and had the streaming USB UVC video working on day one over Wifi.

I cant find a library , every one sends bit value to control the pins , not that practical if i need to read and write from all the pins a a lot

If you installed node-red-contrib-bme280 in the config window just change bus# to 0 and it should work. I noticed that i have to reboot each time a new node is installed to see it or make it work.

Serial.println() inside requestEvent() always fails, even with NUL str, Serial.println(""). root@Omega-745F:~# i2cdump -y -r 0x30-0x32 0 0x09 b 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 30: 0c XX 0c ?X? where as Serial.println() inside receiveEvent() can print one or two characters, for eg, void receiveEvent() { reg = Wire.read(); Serial.println(reg, HEX); } to a certain volume of data. root@Omega-745F:~# i2cdump -y -r 0x30-0x32 0 0x09 b 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 30: 30 31 32 012 root@Omega-745F:~# i2cdump -y -r 0x30-0x3F 0 0x09 b 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>? root@Omega-745F:~# i2cdump -y -r 0x40-0x4F 0 0x09 b 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 40: 40 41 42 43 44 45 46 47 48 49 4a 4b 4c 4d 4e 4f @ABCDEFGHIJKLMNO root@Omega-745F:~# i2cdump -y -r 0x30-0x41 0 0x09 b 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 30: XX 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f X123456789:;<=>? 40: 40 41 @A If there is more data, it fails.. root@Omega-745F:~# i2cdump -y -r 0x30-0x45 0 0x09 b 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 30: XX 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f X123456789:;<=>? 40: 40 41 42 00 00 00 @AB... root@Omega-745F:~# i2cdump -y -r 0x30-0x4F 0 0x09 b 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 0123456789:;<=>? 40: 40 41 00 00 00 00 02 XX 00 00 00 00 00 00 00 24 @A....?X.......$ It fails every time if a long str such as "Hello, World!" is to be printed, even inside receiveEvent(). It is not a problem associated with ARD Dock; I am not using ARD Dock at all.. Thanks..

@Modest-Polykarpovich I tried but the device did not appear in /dev/ echo rtc_m41t80 0x68 > /sys/class/i2c-dev/i2c-0/device/new_device dmesg show [ 152.302693] i2c i2c-0: new_device: Instantiated device rtc_m41t80 at 0x68 root@Omega-61B6:/# lsmod | grep 41t8 rtc_m41t80 8704 0 root@Omega-61B6:/# i2cdump -y -f -r 0-6 0 0x68 c 0 1 2 3 4 5 6 7 8 9 a b c d e f 0123456789abcdef 00: 00 ff ff 7f 07 3f 1f ...????

@Decagrog the shipping cost to Oz would exceed 20 Euros, otherwise I would purchase.

Yes, those work perfectly and are used to determine the device is there. But there is no way to read the actual range data without a lot of i2c back-and-forth with their custom protocol. There are python libraries to handle this, but none of them work on the Omega (yet)

@jose-r You don't have to do anything with an Onion ADC Expansion Board: the power supply voltage of the ADS1115 is 5V each I2C bus line has a usual 5V-to-3.3V MOS-FET bidirectional logic level shifter

I hadn't finished and it submitted somehow. The Python code is: bytes = [0xAA, 0, 0] try: i2c.write(0x18, bytes) except: print "write failed" time.sleep(0.01) y0 = i2c.read(0x18,4) print y0 This returns a status byte, but zeros for the pressure data. The i2c waveforms which I captured from an oscilloscope look different enough to matter. Can I upload them here somehow? The command bytes to read the pressure [0xAA, 0x00, 0x00} for Arduino and Onion: And the two responses showing that the sensor only returns zeros on the Onion The oscilloscope interprets all of the i2c bus traffic correctly, but it appears that the sensoe is never getting triggered by the [0xAA...] command to start digitizing. So it only sends back zeros. Does anybody know why the i2c waveforms are different and how to make the Onion i2c library behave as the Arduino does which works properly. I am not having any trouble with other i2c communication from the Onion, only this sensor. Thanks to anyone who is up on this. Stay safe! Y.

@cmelnick It's possible the onion-i2c:: debug readings aren't 100% correct. Can you try changing your code when you read to this: val = i2c.readBytes(0x5a, 0x5d, 1) print(val)