You talk to the industrial I/O  pins via the Linux file system. They are mapped to character device drivers.

It would be easy in plain python. No idea how to deal with that with the wiring bridge...

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: fxl6408fxl6408.

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.

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.

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....

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²C Analysis results

sudo echo 1 > /sys/class/gpio/gpio201/value

I²C Analysis results

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.

Jan Cumps  wrote:

 

I get this report. It matches with the note above.

If I understand i2cdetect, the UU means that the device is busy which is validated if you try to read from the device

sudo i2cget -y 1 0x43 5
Error: Could not set address to 0x43: Device or resource busy

lsmod shows these:

$ lsmod
Module                  Size  Used by
bnep                   20480  2
hci_uart               36864  1
btbcm                  16384  1 hci_uart
serdev                 20480  1 hci_uart
bluetooth             368640  24 hci_uart,bnep,btbcm
ecdh_generic           28672  1 bluetooth
rtc_pcf8563            16384  0
gpio_fxl6408           16384  0
brcmfmac              307200  0
brcmutil               16384  1 brcmfmac
mcp251x                20480  0
cfg80211              565248  1 brcmfmac
can_dev                24576  1 mcp251x
sc16is7xx              20480  0
rfkill                 28672  4 bluetooth,cfg80211
i2c_bcm2835            16384  0
uio_pdrv_genirq        16384  0
uio                    20480  1 uio_pdrv_genirq
fixed                  16384  0
i2c_dev                16384  0
attiny_btn             16384  0
attiny_led             16384  0
attiny_wdt             16384  0
attiny_mfd             16384  0
ip_tables              24576  0
x_tables               32768  1 ip_tables
ipv6                  446464  22
crc_ccitt              16384  1 ipv6

if you remove gpio_fxl6408

$ sudo rmmod gpio_fxl6408

and rerun i2cdetect you get this:

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- -- 
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- UU -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- 43 44 -- -- -- -- -- -- -- -- -- -- -- 
50: -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- --                        

After that you can set/get the registers:

$ sudo i2cset -y 1 0x43 5 255
$ sudo i2cget -y 1 0x43 5
0xff

You can then use the I2C functions of WiringPi to programmatically access the I/O.

What you loose is the ability to control the I/O with the /sys/class/gpio/ files.

0x44 also appears to be an FXL6408.  Any idea what that is or how to configure the gpio_fxl6408 driver to ignore 0x43 and still enable the file access for 0x44?

I didn't have to unload the libs. I think your device is busy because the Iot example for the smartedge is running. I switched those off.

Yes the 0x44 is a second bus expander. I don't know what it's used for.

Jan Cumps  wrote:

 

I didn't have to unload the libs. I think your device is busy because the Iot example for the smartedge is running. I switched those off.

The stock apps were disabled long ago. We have some significantly more capable software with OPC, PLC drivers, Cloud AWS, Azure, Docker, etc. that we deploy from our application builder.  The smartedge is a really nice hardware platform.  We delivered it to a customer just to monitor some Modbus (RS485) temperature controllers (onboard serial, configurable as RS232 or RS485 - very nice).  Once the customer saw the I/O they immediately took an interest in motor control and replacing the temperature controllers with direct control from the box.  We have drag-and-drop GPIO support (based on Wiring Pi) for the stock Pi header but the isolated 60V external I/O is an attractive feature that we now want to support.

For the tests that you did, I wouldn't expect you to need to unload the driver.  The UU in i2cdetect indicates that the bus is busy on your system.  I would expect that i2cset and i2cget will fail and report that the resource is busy - please give it a try and let us know.

0x44 is configured for two outputs - bits 5 & 2, register 3 return 0x24 both were high at the time I read them.  I didn't read the input status - maybe some other time.

This is an interesting option.  One issue with the industrial I/O being on the I2C bus is that you loose the ability to use either hardware or software PWM.

ergouser  wrote:

... I would expect that i2cset and i2cget will fail and report that the resource is busy - please give it a try and let us know.

 

You are correct.

ergouser  wrote:

... I would expect that i2cset and i2cget will fail and report that the resource is busy - please give it a try and let us know.

 

You are correct.