<div dir="ltr"><div class="gmail_default"><font size="2">Thanks for sharing your Pi to Arduino code. This is of interest to me because I'm doing something quite similar.</font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2">Ever since I started playing around with Lidar, and thus have outgrown my Atmega1280P (Pololu Orangutan 1280p board), I have been looking at ways to pair up a Raspberry Pi with "something else" that takes care of all the bit-banging and low-level stuff. <br></font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2">Over the years I have explored a number of options, including of course the obvious options such as UART, I2C and SPI. They all have some gotchas, and most of those gotchas stem from the fact that the Pi is so much faster than the AVR.</font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2"><b>UART & SPI: </b><br></font></div><div class="gmail_default"><font size="2">As long as the bitrate is kept low enough, this will work fine. The AVR does not have any FIFO, so operating the UART or SPI at around 1Mbit/second would probably be tough to get working reliably because that results in an interrupt every 10microseconds or so. 100Kbits/sec on the other hand is not be an issue. Its been a while since I have checked, but I don't think the SPI port on the Pi can even go below a certain speed - i.e. I don't think its possible to run the SPI port on the Pi at 100 or 200 Khz. If you run the SPI port very fast, you run the risk of loosing data on the other end due to lack of FIFO.<br></font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2"><b>I2C:</b></font></div><div class="gmail_default"><font size="2">Need to watch out for that infamous Pi I2C hardware bug. <b>Murray - Since you implemented your own I2C based mechanism you may want to look into this.</b> See links below. <br></font></div><div class="gmail_default"><font size="2">I'm not 100% sure if this bug still applies to the Pi 4, but from what I have read, it does seem to.</font></div><div class="gmail_default"><font size="2">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 <a href="https://www.pololu.com/product/3544">Romi controller</a> 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.<br></font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2"><b>Pi clock-stretching bug:</b><br></font></div><div class="gmail_default"><font size="2"><a href="https://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html">https://www.advamation.com/knowhow/raspberrypi/rpi-i2c-bug.html</a></font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2"><b>Another good article about Pi and I2C:</b></font></div><div class="gmail_default"><font size="2"><a href="https://www.recantha.co.uk/blog/?p=19880">https://www.recantha.co.uk/blog/?p=19880</a></font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2"><b>Pololu's library for Pi to Arduino comms via I2c:</b><br></font></div><div class="gmail_default"><font size="2"><a href="https://github.com/pololu/pololu-rpi-slave-arduino-library">https://github.com/pololu/pololu-rpi-slave-arduino-library</a></font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default"><font size="2"><br></font></div><div class="gmail_default" style="font-size:x-small"><font size="2">Chris N.</font><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, May 9, 2020 at 5:13 AM Murray Altheim via DPRGlist <<a href="mailto:dprglist@lists.dprg.org">dprglist@lists.dprg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Bit busy, been raining here.<br>
<br>
Just a note to say that with my most recent code revision the project at<br>
<br>
Raspberry Pi Master to Arduino Slave (pimaster2ardslave)<br>
<a href="https://github.com/ifurusato/pimaster2ardslave" rel="noreferrer" target="_blank">https://github.com/ifurusato/pimaster2ardslave</a><br>
<br>
is functional and now has three working tests:<br>
<br>
* test_echo.py: this tests that the Raspberry Pi and Arduino can<br>
talk to each other, and doesn't require any sensors or additional<br>
hardware other than the I²C between the two boards.<br>
* test_blink.py: this test blinks an LED connected to pin 5 of the<br>
Arduino. This requires a Raspberry Pi connected to an Arduino<br>
over I²C on address 0x08.<br>
* test_config.py: this tests a hardware configuration of one button,<br>
one LED, two digital and one analog infrared sensors, first<br>
configuring the Arduino and then performing a communications loop.<br>
<br>
I've also posted a "technology preview" (not yet complete) of the Robot<br>
Operating System (ROS) in Python 3 to:<br>
<br>
A Python-based Robot Operating System (ROS)<br>
<a href="https://github.com/ifurusato/ros" rel="noreferrer" target="_blank">https://github.com/ifurusato/ros</a><br>
<br>
and a new blog entry on Mecanum wheels to:<br>
<br>
We’re Goin’ Mecanum!<br>
<a href="https://robots.org.nz/2020/05/09/goin-mecanum/" rel="noreferrer" target="_blank">https://robots.org.nz/2020/05/09/goin-mecanum/</a><br>
<br>
If anyone is an expert on Mecanum wheels, the post includes a schematic<br>
diagram ("Plan 1") for a new robot and I'd dearly like a review, i.e.,<br>
does it makes sense in terms of placement of the wheels? I.e., should the<br>
wheel centers be on the circumference of a circle or does that really<br>
matter? Any comments or suggestions very welcome.<br>
<br>
Cheers,<br>
<br>
Murray<br>
<br>
On 7/05/20 4:30 pm, Murray Altheim via DPRGlist wrote:<br>
> Hello all,<br>
> <br>
> As discussed in the last Robot Builders Night Virtual, I've been working on<br>
> a project to communicate between a Raspberry Pi as master (in Python) and an<br>
> Arduino slave. This uses a two byte call and response pattern over I2C so<br>
> its performance seems pretty good (and it's relatively simple).<br>
<br>
...........................................................................<br>
Murray Altheim <murray18 at altheim dot com> = = ===<br>
<a href="http://www.altheim.com/murray/" rel="noreferrer" target="_blank">http://www.altheim.com/murray/</a> === ===<br>
= = ===<br>
In the evening<br>
The rice leaves in the garden<br>
Rustle in the autumn wind<br>
That blows through my reed hut.<br>
-- Minamoto no Tsunenobu<br>
<br>
_______________________________________________<br>
DPRGlist mailing list<br>
<a href="mailto:DPRGlist@lists.dprg.org" target="_blank">DPRGlist@lists.dprg.org</a><br>
<a href="http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org" rel="noreferrer" target="_blank">http://lists.dprg.org/listinfo.cgi/dprglist-dprg.org</a><br>
</blockquote></div>