Raspberry Pi Forums

tito-t wrote:hello davenull + Gordon + all,
thank you all for your help! I meanwhile tried this

Code: Select all

for (cnt=0; cnt<30; ++cnt ) { 
    recvbuf[cnt]=wiringPiI2CRead (ard_due) ;
}

Although it read and displayed 30 values on the Rpi, I encountered 2 issues:
1st, it always read just the first array value[0] == 255, but 30 times, no array[1] or [2] or [29] or what ever
2nd, after having done this 2 or 3 times, the i2c connection breaks and the Rpi does not find the Arduino any more. i2c device list on the Rpi is empty. After restarting the Arduino, it's there again (0x04).

tito-t wrote:thank you, Gordon,
as for the Arduino slave, the corresponding Arduino MASTER code works fine and both go fine together:

Code: Select all

// Wire Master Reader
// by Nicholas Zambetti <http://www.zambetti.com>

// Demonstrates use of the Wire library
// Reads data from an I2C/TWI slave device
// Refer to the "Wire Slave Sender" example for use with this

// Created 29 March 2006

// This example code is in the public domain.


#include <Wire.h>

void setup() {
  Wire.begin();        // join i2c bus (address optional for master)
  Serial.begin(9600);  // start serial for output
}

void loop() {
  Wire.requestFrom(8, 6);    // request 6 bytes from slave device #8

  while (Wire.available()) { // slave may send less than requested
    char c = Wire.read(); // receive a byte as character
    Serial.print(c);         // print the character
  }

  delay(500);
}

it also sends just "require 30 bytes" commands to the Arduino slave, and that works!
So how will the ported Rpi code have to look like to your opinion? Or how will have dav's code to be changed for the array receiving?

  unsigned char buffer [6] ;
...
  read (fd, buffer, 6) ;

tito-t wrote:o yes, this Arduino code was the 6 bytes example. But davenull already also posted another code using 30 bytes by a read command which also failed. So to have finally 1 complete code which establishes byte array sending and receiving alternatingly would be fine to have eventually...
UART for Arduino is not easy to do because UART and USB ports are already in use and the Arduino USB is needed for the serial window during runtime.
Or do I understand you correctly that not even you are able to write code like for the Arduino master which works for the Rpi because the Rpi i2c is such a total crap?
Sort of a Rpi Wire() lib which mimics the Arduino Wire() lib?

tito-t wrote:no, what I wanted to say was: no single code works, neither using read nor using wiringPiI2CRead.
All things are totally messed up, either I get just 1 byte or 30 identical (not incrementing the array counter). But nevertheless, if I use Arduino code by the Wire lib, everything works always fine: the slave works fine and the master works fine. So the reason must be a totally muddled-up Rpi i2c functionality. That's why I asked if it's not possible to hae a Wire lib for Rpi which works as fine as the Wire lib on Arduino. In case the i2c implementation to Linux is faulty, then that will have to be fixed before of course.

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <wiringPi.h>
#include <wiringPiI2C.h>

#include <errno.h>
#include <string.h>


int main (void)
{
  int fd, i ;
  unsigned char data [16] ;

  if ((fd = wiringPiI2CSetup (0x68)) < 0)
  {
    fprintf (stderr, "Can't open RTC: %s\n", strerror (errno)) ;
    exit (EXIT_FAILURE) ;
  }

  for (;;)
  {
    read (fd, data, 16) ;
    for (i = 0 ; i < 16 ; ++i)
      printf ("  %02X", data [i]) ;
    printf ("\n") ;
    sleep (1) ;
  }

  return 0 ;
}

  00  00  00  00  00  00  00  00  00  00  00  00  56  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  57  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  58  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  59  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  5A  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  5B  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  5C  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  5D  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  5E  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  5F  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  60  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  61  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  62  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  63  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  64  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  65  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  66  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  67  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  68  AE  A8  56
  00  00  00  00  00  00  00  00  00  00  00  00  69  AE  A8  56

davenull wrote:hey Gordon,

I can confirm what Tim wrote:
neither wiringPiI2CRead works to read from the Arduino slave (Arduino array is not incremented by read request) nor did the simple read code work which I tried.
There must be a big issue for Arduino-to-Raspi-communication.

Again, I must give up, and at least I am not able to port your Gertuino code to make it work for my Due and my Raspi.
If both devices are Arduinos, everything is ok, when the master is a Raspi, it fails.

I can also confirm Tim's observation about the crashing i2c bus - so that's not a good and reliable setup so far.

What would be needed was actually really a complete tested sample code for alternating reading arrays[30] from an Arduino slave and writing another array to an Arduino slave.

BTW, how large is the I2C buffer to Raspi? 30? 32? even more? 64? 128? or perhaps even less than 30?
For the Arduino default is 32 minus 1-2 address bytes, but I2C_Buffer_Size can be adjusted in Wire.h or twi.c (not completely sure which one).

Nevertheless, perhaps this could be an additional issue, too.

I have little inclanation to further this myself.

davenull wrote: As I am currently stuck to my Raspi-Due-UART communication, I abandonded my I2C comm attempts.

But if (e.g. Gordon...?) would provide some good working code for alternatingly exchanging raw arrays of bytes between Raspi and (either) Arduino I would gladly try to find out if there were issues about Due and Mega which could be fixed by that.

@Gordon: about your last post saying

I have little inclanation to further this myself.

after all, " little inclination" would not compulsorily mean "NO inclination" , so perhaps there would still be a little space for hope for future developments and enhancements, what do you think...?

tito-t wrote:thank you! But now I am totally bewildered - no one around here in this forum full of experts who is able to write Raspberry C code to send and receive arrays to/from an Arduino!? That is embarassing.... So do I really have to abandon this and have to use multiple PCFs and MCPs instead? That cannot be true to be honest....

tito-t wrote:thank you! But now I am totally bewildered - no one around here in this forum full of experts who is able to write Raspberry C code to send and receive arrays to/from an Arduino!? That is embarassing.... So do I really have to abandon this and have to use multiple PCFs and MCPs instead? That cannot be true to be honest....

tito-t wrote:it's not a large system, it's just for a mobile robot with 8 sharp IR distance sensors and a couple of rotary encoder motors plus a Pixy cam plus a couple of bumper sensors (touch buttons). At first I wanted to use 2 PCF8591 for the analog sensors and 1 or 2 MCP23017 for the touch sensors and the encoders plus 1 Arduino Uno to interface the Pixy Cam and 1 or 2 more UART sensors (via softserial). But then Davenull's idea about a Arduino Due seemed to be even a better idea. But I had to interface 1 Arduino in either case. The problem seems to read 30 bytes from the Arduino, not to write, but I am a beginner and just used to Arduino IDE Sketches where everything is so easy and comfortable. I have no idea about IOCTL and the low level C coding, I thought the Rpi was made for beginners and hobbyists like the Arduino, not for specialists. This all looks awfully complicated. If I only had a simple code to start with (simply first read and then write an array to an Arduino)! I tried davenull's code for reading 30 bytes from the Arduino which he posted above and I failed completely, and he, too, as he wrote. So it appears not to be just trivial.

tito-t wrote:thank you Gordon, am I right that then the code for the Rpi should look like that?

Code: Select all

...

Anyway, I'm almost sort of reassured to hear from you that there are severe Rpi and Arduino issues to i2c and that this problem is not just a simple "read the f... manual" thing as I read above - instead it actually appears really to be a specialist's task to make that work. Anyway I'm very happy that you - perhaps - will try to establish a code from Rpi to Arduino Sketch which - perhaps - even would work. I'm gladly looking forward to it, thanks for your efforts!

gordon@drogon.net wrote: ...
I'd not go as far as to say severe issues - it's just one feature that the Pi doesn't support (clock stretching).
...

joan wrote:

gordon@drogon.net wrote: ...
I'd not go as far as to say severe issues - it's just one feature that the Pi doesn't support (clock stretching).
...

I understand the lack of support for clock stretching is down to the current driver rather than the Pi hardware.

I remember a forum post where someone had tested their own I2C driver with clock stretching and had done a push or pull or whatever to try to get the update included.

gordon@drogon.net wrote: ...
That's interesting - be good to know for sure. I was chatting with Gert once and he was the one who explained to me that it simply didn't work in the hardware side of it - the Pi keeps on outputting clock (& data) pulses even when the slave holds the clock low... Maybe it bit-bangs it - at the bit level rather than using the SoC hardware driver? That ought to be possible...

-Gordon