Smartedge External GPIO and WiringPi

Question

There's a good discussion of the external IO on the SmartEdge by Jan Cumps here : AVNET SmartEdge IIOT Gateway: Use the Industrial I/O

Has anyone used these GPIO with wiringpi or have any ideas how that might be done?

Thanks.

Jan Cumps · Answer

ergouser wrote: .... Has anyone used these GPIO with wiringpi or have any ideas how that might be done? ... As far as I can see, the I/Os are managed by an ON Semi i2c port expander: fxl6408 fxl6408 . I derive it from their github: https://github.com/Avnet/smartedge-iiot-gateway/blob/master/drivers/gpio/gpio-fxl6408.c . I am not sure, because the On Semi datasheet says the package should mention TX, but the IC on my device says UK RX. You could try and talk to it from wiringpi. The protocol is documented in the datasheet .

ergouser · Answer

Jan, Thanks for the input so far. As far as I can tell, there is already an FXL6408 on the Pi3 which controls some of the existing peripherals (eg hdmi hot-plug) and it has firmware support. That expander is rumoured to be full, and so do we think that the additional GPIO adds another FXL6408 (which would make some sense)? The manual also references some reserved I2C addresses: *NOTE: I2C1 Bus (GPIO2/GPIO3) is shared with onboard devices. I2C addresses: 0x33, 0x43, 0x44, 0x51 are reserved. Any thoughts on how to confirm these thoughts or how to determine the I2C address? There's a huge performance advantage to using the firmware driver over using the character file interface from which I'd like to benefit.

Jan Cumps · Answer

I get this report. It matches with the note above. I'm setting up probing with a protocol analyser source: https://www.raspberrypi.org/documentation/usage/gpio/ Let's see if I can capture a conversation....

Jan Cumps · Answer

Here are the results of the i2c capture. I made my analyser trigger on a change of the output O1. and captured the traffic before that event. Two scenarios: First I sent a 0, then a 1. The IC's i2c address is 0b1000011 -> 0x43 sudo echo 0 > /sys/class/gpio/gpio201/value I 2 C Analysis results 2 januari 2021 Bus configuration SDA Channel 1 SCL Channel 0 Statistics Decoded bytes 7 Detected bus errors 0 Index Time Hex Bin Dec 0 -2,30 ms START 1 -2,29 ms 0x86 0b10000110 134 2 -2,00 ms ACK 3 -1,98 ms 0x05 0b00000101 5 4 -1,71 ms ACK 5 -1,66 ms START 6 -1,65 ms 0x87 0b10000111 135 7 -1,36 ms ACK 8 -1,34 ms 0x02 0b00000010 2 9 -1,07 ms NACK 10 -1,02 ms STOP 11 -971,50 μs START 12 -955,50 μs 0x86 0b10000110 134 13 -667,50 μs ACK 14 -651,50 μs 0x05 0b00000101 5 15 -379,50 μs ACK 16 -363,50 μs 0x00 0b00000000 0 17 -91,50 μs ACK 18 -43,50 μs STOP sudo echo 1 > /sys/class/gpio/gpio201/value I 2 C Analysis results 2 januari 2021 Bus configuration SDA Channel 1 SCL Channel 0 Statistics Decoded bytes 7 Detected bus errors 0 Index Time Hex Bin Dec 0 -2,23 ms START 1 -2,21 ms 0x86 0b10000110 134 2 -1,92 ms ACK 3 -1,91 ms 0x05 0b00000101 5 4 -1,63 ms ACK 5 -1,59 ms START 6 -1,57 ms 0x87 0b10000111 135 7 -1,28 ms ACK 8 -1,27 ms 0x00 0b00000000 0 9 -993,20 μs NACK 10 -945,20 μs STOP 11 -883,60 μs START 12 -867,60 μs 0x86 0b10000110 134 13 -579,60 μs ACK 14 -563,70 μs 0x05 0b00000101 5 15 -291,60 μs ACK 16 -275,70 μs 0x02 0b00000010 2 17 -3,60 μs ACK 18 44,40 μs STOP

Jan Cumps · Answer

ergouser wrote: .... Any thoughts on how to confirm these thoughts or how to determine the I2C address? There's a huge performance advantage to using the firmware driver over using the character file interface from which I'd like to benefit. In the scheme of things, the majority of time is spent in i2c. Writing to the block device is going to be a snap, compared to the 2.x ms i2c conversation. If you want to have direct fast control over the pins, you'll need to bring out the hot air gun. You can move the control from the IO expander to a direct GPIO pin, by moving resistors: In this case I'm showing O1. By moving resistor R156 to position 157, it is now controlled by generic GPIO6.