1

I'm doing a project at work which involves multiple (more than 2!) raspberry pies (Model 3 B+) being able to talk to each other (talk to each other means being able to send data of the size of a string, so the size will be one or serveral bytes). My instructor wants this communication to be realized only via gpio pins. His idea is that all the raspberries gpio pins X are connected to each other, as well as all the gpio pins Y, and the gpio pins Z.

If one pi wants to send, it would tell the others on "channel X" that it is sending now, and then switch pin Y to OUTPUT Mode, while all the other pis would switcher their pins Y to INPUT Mode. Then the sending pi would begin encoding the signal in 0s and 1s and (with a little delay) set the output voltage of pin y to either 0 or 1 in order to transmit the signal. Between each bit, the the sending pi would just wait for time t.
Pin Z would be the ground pin. The Idea was that the data transmission takes place on a very low speed, so that the receiving party can simply wait for time t, to know which gpio-value belongs to which bit.

My Question as somebody who hasn't done mutch with a pi before: Can this idea work out?

A follow up question to that: I read about serial communication in this answer which uses the UART pins, which can be used for one pi to be the sending, and the other one being the receiving end of the transmission line. It seemed to be a very easy-to-setup way of communication between 2 pis. Now my question is: Does serial communication work between more than 2 pis as well? With the rx pin of one of the pis being connected to BOTH of the tx pins of the other 2 ones, for example?

Improve this question
6
  • Read the I2C which is supported by RPi and can be implemented via GPIO. Since this is your study project, I will leave the rest of research to you on how to implement it.
    – hcheung
    Jun 11, 2018 at 15:00
  • I2C is multiple slaves, one master. That doesn't quite fit the question which suggests any Pi could trigger the communication. What is pin Z for? What data rate? How does the receiver "clock" the bits? i.e. how does a receiver know what it means if Y is set high for one second?
    – joan
    Jun 11, 2018 at 15:07
  • Only to clarify - I'm not a student. When I said instructor, I meant the guy who is running this project at my working place, and is (formally, since I'm doing an apprenticeship) my instructor. The task is not meant as an excercise, which as well means that he knows solutions that I don't know. This also means that he isn't supposed to teach me raspberry pi, as mutch as I'm not supposed to learn it from him. It just happens that we use the raspberry as a tool to realize the project that he has in mind.
    – Quantumwhisp
    Jun 11, 2018 at 15:08
  • @Joan At the moment z is simply the ground pin, and there isn't a timed clock in this setup: Both parties just wait the same amound of time with sending / receiving one bit of the number they want to transmit.
    – Quantumwhisp
    Jun 11, 2018 at 15:17
  • So if pin X goes high all other Pis set pin Y to be an input. All the Pis have a ground connected (calling it pin Y confuses the matter). The transmitting Pi sends serial formatted data (start bit, 8 data bits, stop bit). There is a fixed baud rate of something like 9600 bits per second. Is that correct? If the baud rate is correct that is doable. The only question is how you plan to detect and handle collisions (two Pis transmitting at the same instant).
    – joan
    Jun 11, 2018 at 15:23

1 Answer 1

Reset to default
1

The problem is that there is a potential for a race condition.

Let's say that A, B , and C are Pi's. A checks pin X and it is low (no signal). The it runs the function to set X high. Meanwhile, B checks pin X and it is low, so B also sets X high.

The data transmission will have a collision. You have to be aware that this can happen and program around it. One way would be to have a token, and only the pi with the token can initiate a serial connection to any other pi.

Here is roughly how I would do this. It involves using pin Q and R, which are interrupt pins. R would receive the token and Q would send the token to the next Pi.

A wants to send the token to B. A sets his Q pin high for a short while (1 ms?); this is connected to B's R pin, which receives the token. I would use the falling edge interrupt, but that is a matter of taste.

Once B has the token, it can do one of two things. If it wants to send data, then it sets x high knowing that nobody else can (or should) do this. And then it sends the data like you said. After it is finished sending the data, it sends the token to the next machine.

If B doesn't want to send any data, then it immediately sends the token.

Yes, I know that I've badly reinvented the token-ring network, but this works in preventing race conditions and data collisions.

Improve this answer
3
  • With your system, I wouldn't actually need X, right? since only the Pi having the Token could send it.
    – Quantumwhisp
    Jun 11, 2018 at 17:05
  • Correct. I thought that X was part of the message.
    – NomadMaker
    Jun 11, 2018 at 17:47
  • I should probably ask another question on the second part of my question (serial connections between 3 or more parties)
    – Quantumwhisp
    Jun 12, 2018 at 5:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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