I'm building for an Arduino nano 33 IOT on Arduino IDE 2.0.0-rc9
Error message:
C:\Users\lerman\Documents\Arduino\SumpPump\SumpPump.ino:149:14: error: 'class arduino::TwoWire' has no member named 'setWireTimeout'; did you mean 'setTimeout'?
Wire.setWireTimeout(3000, true); // 3 msec, reset on timeout
TwoWire.h has such a member. (I also get errors for other timeout related members.)
The wire library doesn't seem to have a version number in it, but a comment says:
Modified 2020 by Greyson Christoforo (grey@christoforo.net) to implement timeouts.
Thank you, Koepel. I thought I had set the gui to use the nano 33 iot device. It appears to me that I included Wire.h, and there was none for my device. It then used the one for the uno. At any rate, you solved that problem for me.
My new problem is that there is no timeout for the SAMD functions. That's a problem for me because I'm building a redundant, high availability system. If the peer to which this system goes down, it will take the system down if the I2C connection hangs.
Aside from rolling my own, do you have an alternative?
The I2C bus is not fault tolerant and it is designed to stay on the same pcb board. It has weak signals, because the high level is made with a pullup resistor.
On this forum we say sometimes that 50 cm is the maximum for the I2C bus. The standard maximum length for the I2C bus is 2 meters (if everything is done right), but if everything is done wrong, then the length is 20cm. Some have a I2C bus of 6 meters long or more.
There has been a number of problems with the I2C bus for the "samd" branch on this forum, those are not quickly solved, it seems. I still don't know what to think of this.
Arduino is for learning and for fast prototyping. It was created by people at a university, not by embedded software engineers with many years of experience. Redundancy was never the goal.
Every Wire or Wire-compatible library waits. In the Master the sketch waits until the full I2C session has finished.
With normal Serial RX-TX communication, there is no waiting. Incoming and outgoing data uses buffers and interrupts, as it is supposed to be.
The Serial RX/TX communication is more reliable and has strong signals. If you choose that, than you can also fall back to a half-duplex RS-485.
A good alternative is the Raspberry Pi Pico. Arduino is a layer on top of Mbed. You could even put Arduino aside and program it directly in Mbed. That might sound good, until you use the well known I2C Scanner sketch. That does not work normally on Mbed, since a "write" with zero bytes is not supported by Mbed.
Let us know what you decide, maybe others have some tips.
I have two nano 33 iot systems with a ISO1540 connecting them to provide isolation and communication. My I2C length is only a few inches on each side of the ISO1540.
One system is the primary and the other the secondary. Once a second, the primary sends a message to the secondary and expects a response. If there is no response, the primary knows the secondary has died. If the secondary doesn't get a message from the primary, it knows the primary has died.
The problem I'm concerned with is what happens if the secondary dies and the primary hangs when trying to communicate with it. Then both systems are inoperative and my basement might fill with water. (My application is a redundant sump pump controller.)
My inclination right now is to:
Modify the code in SERCOM.cpp so that the while loops that wait for data also look at a (new) timeout flag.
Use an interruptTimer to set the abort flag when appropriate.
I'm reading the code in SERCOM.cpp and reading the spec of the I2C interface to try to determine if I can do something clever and reset the I2C and not have to change SERCOM.cpp.
ISO1540 I2C isolators: https://www.ti.com/product/ISO1540.
It might weaken the signal, it is certainly not meant to drive a I2C bus in a cable.
I read the document to use the isolator for a hot-swappable I2C system, but I'm not convinced. I think that it will only work in a very specific situation.
You description is not clear. How long are the wires (for all three parts), what are your pullup resistors (for all three parts), is SCL next to SDA (bad), and so on.
I think that your idea of the I2C bus is wrong. It is not that kind of bus. Looking into the library and the SERCOM does not help if you use the I2C bus for something that it can not do.
The I2C bus can not deal with a device that is offline. Everything should be on the same pcb board and if one I2C device fails, then a restart is needed. If a I2C device fails more than once, then the pcb board has to be replaced.
The I2C bus is not really a communication bus.