[Dprglist] Raspberry Pi Master to Arduino Slave (pimaster2ardslave)

[Murray Altheim]

On 11/05/20 3:47 am, Chris N wrote:
> Thanks for sharing your Pi to Arduino code.    This is of interest to me 
> because I'm doing something quite similar.
[...]

Hi Chris,

Thanks, my project is still rather new and not entirely tested, but mostly
works. I'll add some cautions below and also explain the rationale for it,
which is possibly different than others' approaches.

> *I2C:*
> Need to watch out for that infamous Pi I2C hardware bug. *Murray - Since
> you implemented your own I2C based mechanism you may want to look into
> this.*   See links below.

Yes, I am aware of the bug. On the list we've been discussing use of the
BNO055 orientation sensor (I'm using Adafruit's board) and that they well-
document that one needs to slow the Pi's clock down to avoid the bug. It's
not hard to do so but of course having a slower I2C bus affects the entire
robot's intra-communication performance. I'd originally been planning to
host the BNO055 on a Metro Mini M4 or an Arduino Micro, and then have the
Pi communicate with that via I2C, so my project is actually a possible
solution to that problem, i.e., Pi-talking-with-Arduino-to-get-BNO055-data.

> I'm not 100% sure if this bug still applies to the Pi 4, but from what
> I have read, it does seem to.

Yes, I believe there is no fundamental change in the Pi 4's architecture
so the "bug" remains. Adafruit states:


  "Raspberry Pi computers do not have I2C clock stretching support so
   they don't work well with the BNO055 - there's hacky workarounds,
   but it's not recommended!"
   https://learn.adafruit.com/adafruit-bno055-absolute-orientation-sensor/python-circuitpython

They don't mention why the workarounds are "wacky" or "not recommended".
For me it was modifying one value in the /boot/config.txt file.

I just didn't like that my I2C bus was suddenly running so slow. When I
rebuilt an SD card for the robot I accidentally forgot to alter the
configuration and accidentally ran my BNO055 on the Pi with the I2C at
full speed -- it seemed to run just fine, so I'm just using it at full
speed now. If there's data loss, well, there's data loss. Doesn't seem
that big a deal: I just poll until I get data. But I haven't noticed it,
frankly.

> I2C  is what I'm current using actually.   Pololu has a few boards that are designed to be mated up with a Pi.  One of them is the Romi controller <https://www.pololu.com/product/3544> that goes with their Romi chassis.   Pololu has created 
> a Python  library for the Pi and they have provided the code that runs on the Atmega.  See link below.  Their implementation specifically takes the Pi I2c bug and the slowness of the Atmega into account.  As a result, the performance that 
> can be achieved is limited to much less than the raw I2C bitrate of 100Khz.

That sounds like a possibility. After chatting with David A. I was digging
around and found that the Teensy 4.0 runs at 600MHz, which is almost half
the speed of the Pi 3 B+ at 1.4GHz, so a Teensy might work too. The 4.0
is pretty impressive and has 7 serial pins. I think that means you can run
7 UARTs?

As I've described both online and offline (I think) but it bears repeating
is that my pimaster2ardslave isn't intended to run as fast as the bus, it's
intended to be polled more on the 20ms range, i.e., I want to (as described
above) offload some of my sensors onto an Arduino or similar board and then
poll it as if it were a sensor, at the same rate as my robot loop timer of
20ms or 50ms. As a quick experiment I reduced the time.sleep() value in the
library loop to see if it was missing poll counts between the library and
the Pi and I didn't see any errors.

I'd be very interested in anyone's performance stats in use of the library
and would be happy to include that in its documentation. It wasn't designed
to require the Pi's I2C bus to be slowed down and there will be some
performance limit (of course), it's just that that wasn't a concern of mine,
given my own usage. It seems to function fine when polled in a test loop on
the Pi with no delay, but that may just be because the Pi is waiting for the
Arduino's response. The actual numbers I have no idea.

Thanks for the links, I've added them to the NZPRG Wiki's I2C page:

    https://service.robots.org.nz/wiki/Wiki.jsp?page=I2C#section-I2C-Links

I'll also take a look at the Pololu link in particular, looks like it
might work for me too.

> *Pi clock-stretching bug:*
> https://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html
> 
> *Another good article about Pi and I2C:*
> https://www.recantha.co.uk/blog/?p=19880
> 
> *Pololu's library for Pi to Arduino comms via I2c:*
> https://github.com/pololu/pololu-rpi-slave-arduino-library
...........................................................................
Murray Altheim <murray18 at altheim dot com>                       = =  ===
http://www.altheim.com/murray/                                     ===  ===
                                                                    = =  ===
     In the evening
     The rice leaves in the garden
     Rustle in the autumn wind
     That blows through my reed hut.
            -- Minamoto no Tsunenobu