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.
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.
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
| 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
| 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 |
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.
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.
ergouser wrote:
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.
It works: AVNET SmartEdge IIOT Gateway: Control Industrial I/O directly from GPIO Pins
