I been reading about this on the web like at:
http://blog.retep.org/2014/02/15/connec ... using-i2c/
As I found there are 3 ways to connect the PI + Arduino:
What I need is not the fastest but the most ROBOUST which remains stable over the long term. I don't want to squash through thousands of bits every time on the wire between the 2 device. All I need is to send some commands to the ardu (like turn relay X on) and get some read backs (like input from infrared remote).
For what it matters the USB is definitely not that. I have a working home control installation where I control my Arduino from an x86 linux server with a C control program (which should be as fast as it gets), still I ran into a lot of issues over time that the usb connection just stucks in and I either have to reboot the arduino or kill this C control program and restart it.
The other thing is that the Arduino need a capacitor to be connected between 2 legs, otherwise it will reset every time you try to open the port. So for example if I decide to close this C program on the linux host which closes the /dev/ttyACM0 port that would make the Arduino reset and that's not what I want since it has some automation functions on it's own (which it must be able to do even without the computer connected to it (for example turn on lights by remote button presses). So the computer control in my case is just another layer of control. The downside of adding this CAP is it will make the reprogramming impossible, so I had to add it with a switch, what I switch off every time I want to reprogram the Ardu.
So what I planning to do is to replace this installation with an RPI (1/2) + Arduino board where I can run the control program directly from the Pi, the question is just how stable will this be on the long term.
The useful comments I found on that site regarding this was:
"I’ve been struggling to get reliable communication between my raspberry pi and an arduino micro. It works 99% of the time and fails 1% of the time."
"Sorry for the late reply. As you point out This is a known issue with the current I2C kernel drivers and clock stretching.
What I’ve been doing to get around this problem is I manually add delays to my code – one after sending the command and before reading the response and another after the response."