0

I have an Moteino board (similar to Arduino with a radio module). The Moteino uses the radio module to collect weather data from my Davis weather station. I want to use I2C to send this data to an RPi which then uploads it to Weather Underground.

Searching the internet, it seems that when RPi and Arduino are communicating via I2C, the RPi is the normally the master. But I did see there is a PIGPIO library that lets the RPi be the slave.

Because there's a lot going on when the Moteino is using the radio module, I'm worried that if the RPi was the master, the I2C interrupts might cause some problems. So I'm leaning towards making the RPi the slave. Alternatively, I could make the RPi the master and use a GPIO pin from the Arduino that would signal the RPi that the radio isn't being used and now is a good time to request data from the Moteino.

I don't really know the pros and cons of using the RPi as a slave, so I'm looking for suggestions on which way to proceed. BTW - Moteino is 3.3 volts, so I don't have to worry about sending 5V to the RPi like with many Arduino boards.

4
  • 1
    Why not just use the UART? The Arduino can then send data whenever it feels like, and if there is no data going the other way, doesn't have to handle it (= interrupt free). If you do use I2C, it might be simpler to have the Arduino hold a line connected to the Pi high while waiting on the radio, then periodically suspend that and drop the line to indicate to the Pi it is ready to send. Finally: "I'm worried ... might cause some problems" -> This is a bit like how optimization is the root of all evil. Might be healthier to not worry about it unless you actually observe it causing problems.
    – goldilocks
    Nov 11, 2018 at 22:21
  • Using the Pi as I²C slave is a non-trivial task (joan has code to do this). You haven't quantified your problem (how much data, how often, timing constraints) but I²C is probably not the best choice. I agree with @goldilocks using serial or SPI will be simpler and more reliable.
    – Milliways
    Nov 11, 2018 at 23:11
  • I'm worried because currently the Moteino locks up a lot, but it's also connected to an Ethernet board. The Moteino is using SPI for both the radio and Ethernet board, which I think is too much. I was leaning towards I2C because I've used that in several other Arduino projects (never RPi though) so I'm a bit familiar with it. I'll check out UART. Thanks for the feedback. Nov 12, 2018 at 12:44
  • If you are not otherwise using it, it sounds much more appropriate here than I2C.
    – goldilocks
    Nov 12, 2018 at 15:19

1 Answer 1

2

Because I2C is designed to run on fairly low power devices it already has a mechanism to deal with replying to I2C messages when the slave is busy, called "clock stretching". This way the slave can signal the master that it's received the message but needs to delay the reply for a while. https://www.i2c-bus.org/clock-stretching/

I believe the driver on the Pi supports this and will re-try the message if the slave keeps stretching the clock (although with a small bug, see https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=13771) but I've no idea about your slave device, you'll need to check. Reducing the I2C clock speed to a minimum might help as well.

I'd imagine that as the weather is not going to change that quickly, having to try and re-try to get some data to upload is only going to be a problem if it takes hours: in which case you've bigger problems... As suggested in the comments it might make more sense to simply stream the data out of the Moteino over the USART TX and have the Pi listen in once in a while on it's RX: you only need two wires (GND and RX) and, by choosing the correct baud rate, getting the data on the Pi could be as simple as reading a line from the serial port as a file.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.