This is a 3 node I2C network with one master and two slaves.
The board with 4 side LEDs is the master. The side LEDs indicate Slave 1 TX / RX and Slave 2 TX/ RX.
The slave side LEDs indicate TX / RX with the master. There is no slave to slave communication.
The on-board LEDs on all boards flash to indicate a heartbeat main loop still running…
The master is sending 5 byte “packets” to each slave, and after it sends, it is requesting a single byte acknowledgement from the slave.
I added some diagnostics last night to indicate pass / fail for each transmission / ack pair. I then went to bed.
8 hours later, I have 4.7M transmissions, with ZERO failed packets at an average rate of 149.66 messages per second.
I am VERY pleased with these results. I’ve tried to increase the speed by removing code, and the best I can do is ~ 160 messages per second by shortening the packet length. The limiter appears to be the selected I2C bus speed at this point, because transmitting to only one node or both still averages the same messages per second. I don’t need more speed, this is responsive enough, I just wondered where the bottleneck might be.
Next step is to try longer wire lengths to see if it works and if it affects speed or reliability.
After lots of trial & error + googling, I now having the network working over 25 foot lengths of cat 5 (longer than should be needed in an automotive application). For longer lengths, termination resistors (I used 4.5k Ohm) are needed. Once I figured out what to use, I went to longer & longer cable lengths. I can do 3 foot without the resistors, anything longer needs them. I also found some inexpensive ($3) buffer ICs designed for running I2C over long lengths, but at the moment they don’t appear to be needed. I’m still powering them all via USB, so next step is to get a 12v power supply connected and try running power & ground over the cat5 as well. I’ve logged 400k transmissions (5 byte command + 1 byte ack) without failure at ~165 messages / sec with ZERO failures.
I’m very happy with the progress so far – the networking was the part that concerned me most about this concept.
Update – More progress:
I now have CRC16 checksums being added to the outgoing 5 byte command packet. The slave uses this checksum to validate it received the packet correctly, and then as the acknowledgement, sends back the checksum bytes. The master validates the checksum bytes, and the command is believed to have been sent with integrity. This increases a single message to 5+2+2 bytes or 9 bytes total. The increase in byte count and the CRC computation now has the transmission rate down to ~85 messages per second. This is still quite adequate, but I’m hoping it doesn’t drop much more as I add input / translate / command send on the master and command receive / translate / output on the slaves. I’ll leave it running over night to see a few million messages go through with no error, but at the moment, this seems completely plausible for use in a vehicle.