Pi to Pi communication with I2C and pigpio

[iwbnwif]

Hi, I am new to the Raspberry Pi, so apologies for any gaps, misunderstandings or incorrect terminology.

I would like to connect a few (~4) Pi's together as part of an experiment. 3 of the Pi's will be connected to LORA modules and receive different serial data from various remote sensors. Each Pi will process and rationalise the data into a common format. The 4th Pi will receive the rationalised data and display it on a TFT.

Originally, I started by using standard RPI 3's and a LAN switch, however I would now like to use CM3 and a custom backplane.

I have searched as many threads as I could find on inter-CM3 communication without finding a clear solution to the problem. Then I found this thread viewtopic.php?t=162790#p1061380 on I2C slave mode using the BSC slave pins.

I've used I2C with 8051 a long time (27 years!!) ago to do something similar and was involved more recently (17 years!!) with CANbus. But I haven't been designing for many years, so rather rusty

I'm planning some tests this evening to see if I can make pigpio work between 2 RPI instead of a Pi and an Arduino. If that is successful, I will try with 3 and 4 Pi's.

However, I would like to hear of any other ideas or experience in this area, specifically:
1. Is it possible to get this kind of communication working or is it a complete non-starter?
2. Apart from bit-banging, are there any alternative techniques for (expandable) inter-CM3 communication?
3. Any other opinions or advice.

TIA!

[joan]

I'd try bit bang serial before trying slave I2C. If the slaves generate the data automatically you would just need one GPIO per slave at the master. Bit bang serial will probably be pretty solid up to 19.2Kbps.

[iwbnwif]

Thank you very much for your help.

The reasons why am looking for a 'bus' solution are to have some level of expansion capability and to automatically handle the asynchronous nature of the incoming messages. Using a standard such as I2C or CANbus would allow me to sniff the bus with off-the-shelf tools for debugging.

I'd try bit bang serial before trying slave I2C. If the slaves generate the data automatically you would just need one GPIO per slave at the master. Bit bang serial will probably be pretty solid up to 19.2Kbps.

Out of interest, what is the reason for trying bit bang serial before I2C slave - is it just speed?

Maybe another alternative would be to use the UART with an enable line per slave. When a slave sees the enable line, it can activate its TXD pin or could set it as an input otherwise?

[Heater]

What I don't understand is why you need so many Pi. That is a huge lot of computing power for simply shunting a few bytes of LoRa data around. Not to mention the complexity of connecting them all together. As your post shows. Not to mention the expense.

Why not simply have one LoRa module on one Pi acting as a LoRa base station?

For example: https://www.rs-online.com/designspark/b ... an-gateway

[DougieLawson]

1. Is it possible to get this kind of communication working or is it a complete non-starter?
2. Apart from bit-banging, are there any alternative techniques for (expandable) inter-CM3 communication?
3. Any other opinions or advice.

1. Maybe. But you're going to have to do it yourself.
2. Use a UART, connect TX to RX, RX to TX and you can easily communicate over that. You can even get TCP/IP running over PPP over a serial connection.
3. Use anything other than I2C.

[iwbnwif]

Thanks for the tips.

2. Use a UART, connect TX to RX, RX to TX and you can easily communicate over that. You can even get TCP/IP running over PPP over a serial connection.

Yes, I think that is the way to go. I did look into PPP for this (that bought back memories from years back!). It would be quite nice as it would leave the option to replace serial with Ethernet at some later date if needed.

3. Use anything other than I2C.

Thanks

So far the UART with enable lines is looking quite good. I am even thinking about leaving all the slaves in 'receive only' watching for an enable string from the master. When they see there enable string, the reconfigure GPIO14 to be TXD and then set it back to tristate afterwards.

Alternatively, I could leave TXD active and use a master controlled gate for each slave TXD line. This would obviously be safer.

Edit: Or another alternative would be to star the TXD together with OD buffers.... hmmm