[Dprglist] Raspberry Pi Master to Arduino Slave (pimaster2ardslave)
secretary at dprg.org
secretary at dprg.org
Sun May 10 14:31:59 PDT 2020
Murray,
The Rpi's I2C clock stretching has a flaw. It fails because the default
clock stretching register is set to 40. The units are clock pulses. So, if
you are using a high clock rate, the 40 clock pulses are a very short time.
This short time is not sufficient for sensors that require a bit of time,
to respond to a I2C data request. There are a couple of ways to get around
this issue.
1. Slow the clock rate. This will work but has data throughput issues,
and if for some reason a device still needs more time I2C will hang.
2. Change the Rpi's clock stretch timeout register. The book "Raspberry
Pi IoT in C" by Harry Fairhead explains how to do this in C using the
bcm2835 library (see p. 145).He also has some blog posts that are very
helpful.
3. Ensure that you never need clock stretching. You should be able to do
this by gathering all the data from the sensors in your slave
microprocessor (In Murray's case, I believe it is a Nano) and reply to data
requests from the Rpi as soon as they are received (use a "no update" value
if necessary). The slave microprocessor should be a master to the sensors
and be polling them, so a fresh value is at hand, and not waiting for the
Rpi to request info. Since a I2C can have multiple masters, and a master
can also act as a slave, this should be possible. Look at
http://www.gammon.com.au/i2c for an example.
I have messed with the Pololu library, it allows complex communication
between the Pololu board and the Rpi. In my experience it is
overkill, because I don't usually want to send all that data and datatypes
between the master and the slave. However if I did want to send that much
info, it would be a good place to start.
I hope others will join in with their experiences.
Regards,
Doug P.
On Sun, May 10, 2020 at 3:28 PM Murray Altheim via DPRGlist <
dprglist at lists.dprg.org> wrote:
>
>
> 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
>
> _______________________________________________
> DPRGlist mailing list
> DPRGlist at lists.dprg.org
> http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dprg.org/pipermail/dprglist-dprg.org/attachments/20200510/a8068599/attachment.html>
More information about the DPRGlist
mailing list