bugfest
Posts: 2
Joined: Wed May 05, 2021 7:36 pm

Communication between multiple pico's

Wed May 05, 2021 7:49 pm

Hi all,

I'm trying to setup a communication between multiple picos. I've tried UART and I2C, but it looks like that does not fit our needs.

I'm building multiple puzzles that needs to be solved in a limited time. I want to have one master pico that is responsible for the countdown, and distribute to the slaves when the time is up. The slaves need to send to the master when the puzzle is solved.

I've tried UART, but that looks impossible when there are more slaves than UART ports on the pico. I've also tried I2C, but this way the master always need to ask the slaves if there is any data and blocks everything until any data is received. It feels like I2C and SPI are not fully grown up yet. :P

So simply stated; I want to communicate between multiple pico's in both ways, what is the best protocol that I could use?

DarkElvenAngel
Posts: 1695
Joined: Tue Mar 20, 2018 9:53 pm

Re: Communication between multiple pico's

Thu May 06, 2021 5:16 pm

If you use UART with multiple slave device look at rs485 and a suitable protocol.

Maybe modbus might fit the bill.

The advantages are long runs and noise immunity*

The disadvantage would be the extra components.

So in your setup you would have the master poll the other puzzles to check for the complete flag. And if time runs out you can write to all device simultaneously that time is up.

hippy
Posts: 9957
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Communication between multiple pico's

Thu May 06, 2021 5:53 pm

I would use UART.

The master farmer can talk to all slaves sheep in parallel so that's not a problem All slaves sheep can have their outputs diode-mixed to the single master farmer UART input and there won't be a problem so long as the slaves sheep only respond when polled by the master farmer.

An alternative is similar but using a simple token message passing ring style affair arrangement which can actually be wired configured as a star network. That can be better if the master farmer needs to ID each slave sheep.

There's no reason I can see that polling should detrimentally block the master farmer. That should just be a matter of coding, ensuring the slaves sheep do respond in a timely manner.

PiGraham
Posts: 4733
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Communication between multiple pico's

Thu May 06, 2021 6:16 pm

RS485
Key phrase 'multidrop'
Shared data line driven with tri-stable outputs. All devices listen but only one talks at a time.

If you are only communicating between Picos you control over short distances you can simply set the Tx pin of listen only devices to INPUT which is tri-state or floating. That allows any other device to talk on the bus and all devices can listen to it.
Keep the Rx pin as UART all the time but switch the Tx pin to UART to talk.
If you need distance or need to talk to other devices at typical RS485 levels use a RS485 line transceiver on each device and use another gpio to control the bus direction.

You could also look into CANBUS

lurk101
Posts: 590
Joined: Mon Jan 27, 2020 2:35 pm
Location: Cumming, GA (US)

Re: Communication between multiple pico's

Thu May 06, 2021 8:05 pm

PiGraham wrote:
Thu May 06, 2021 6:16 pm
RS485
Key phrase 'multidrop'
Shared data line driven with tri-stable outputs. All devices listen but only one talks at a time.

If you are only communicating between Picos you control over short distances you can simply set the Tx pin of listen only devices to INPUT which is tri-state or floating. That allows any other device to talk on the bus and all devices can listen to it.
Keep the Rx pin as UART all the time but switch the Tx pin to UART to talk.
If you need distance or need to talk to other devices at typical RS485 levels use a RS485 line transceiver on each device and use another gpio to control the bus direction.

You could also look into CANBUS
Yes, CANBUS would be a likely choice. A rather complex protocol though. Could it be implemented on PIO?
The old semiconductor paradigms are rapidly becoming a thing of the past.
Today, it's about the best transistors, architectures, and accelerators for the job.

User avatar
nick.mccloud
Posts: 1228
Joined: Sat Feb 04, 2012 4:18 pm

Re: Communication between multiple pico's

Thu May 06, 2021 8:58 pm

bugfest wrote:
Wed May 05, 2021 7:49 pm
I've also tried I2C, but this way the master always need to ask the slaves if there is any data and blocks everything until any data is received. It feels like I2C and SPI are not fully grown up yet.
I use I2C to communicate with a Pi as master and multiple Arduino or Pico slaves. If the slave code is picking up pre-prepared data, it should be really really quick. If the slave is nipping off to do some thinking, checking or measurement, you're doing it wrong. The I2C slave routine should be on an interrupt, so the the slave can spend most of the time doing the thinking etc.

As for how grown up these are, I2C is 39 and SPI is 42 ...

... that's years old.

I have a puzzle "thing" - I used NRF24L01 modules so I went wireless. And a bigger one with a central Pi3 and slave Pi Zero W's on WiFi.
Pico/RP2040 ≠ Arduino
Pico = hot rod kit car, Arduino = hot rod kit car wrapped in cotton wool with buoyancy aids & parachute

User avatar
joan
Posts: 15622
Joined: Thu Jul 05, 2012 5:09 pm
Location: UK

Re: Communication between multiple pico's

Thu May 06, 2021 9:00 pm

How many slave devices? If less than 20 or so you could use SPI/I2C and give each slave a dedicated interrupt line to request service.

lurk101
Posts: 590
Joined: Mon Jan 27, 2020 2:35 pm
Location: Cumming, GA (US)

Re: Communication between multiple pico's

Thu May 06, 2021 9:02 pm

nick.mccloud wrote:
Thu May 06, 2021 8:58 pm
bugfest wrote:
Wed May 05, 2021 7:49 pm
I've also tried I2C, but this way the master always need to ask the slaves if there is any data and blocks everything until any data is received. It feels like I2C and SPI are not fully grown up yet.
I use I2C to communicate with a Pi as master and multiple Arduino or Pico slaves. If the slave code is picking up pre-prepared data, it should be really really quick. If the slave is nipping off to do some thinking, checking or measurement, you're doing it wrong. The I2C slave routine should be on an interrupt, so the the slave can spend most of the time doing the thinking etc.

As for how grown up these are, I2C is 39 and SPI is 42 ...

... that's years old.

I have a puzzle "thing" - I used NRF24L01 modules so I went wireless. And a bigger one with a central Pi3 and slave Pi Zero W's on WiFi.
If I understand correctly the OP has ruled out I2C and SPI since he does not want a single master bus. I can think of many situations where constant poling of multiple slaves by a master is undesirable.
The old semiconductor paradigms are rapidly becoming a thing of the past.
Today, it's about the best transistors, architectures, and accelerators for the job.

User avatar
iiot2k
Posts: 29
Joined: Thu May 23, 2019 1:59 pm
Location: On Earth.
Contact: Website

Re: Communication between multiple pico's

Thu May 06, 2021 10:47 pm

I dont know how many clients you have and how long the distance is.
I remember there was a arduino keypad display shield, where the keys scanned with resistors connected
to analog input of arduino.
You can use resistors in series and use the three adc inputs of pico.
Ok, there isn't farmer and sheeps, but simple.
Or you use a tm1638 module and displays the time in display.
keys.png
keys.png (4.8 KiB) Viewed 825 times

PiGraham
Posts: 4733
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Communication between multiple pico's

Fri May 07, 2021 9:32 am

lurk101 wrote:
Thu May 06, 2021 9:02 pm
If I understand correctly the OP has ruled out I2C and SPI since he does not want a single master bus. I can think of many situations where constant poling of multiple slaves by a master is undesirable.
That does seem to be the objection
bugfest wrote:
Wed May 05, 2021 7:49 pm
I've also tried I2C, but this way the master always need to ask the slaves if there is any data and blocks everything until any data is received.

But maybe based on a misunderstanding. Nothing need block for any significant time.

There is a coordinating timing 'master' device and multiple puzzle 'slaves'
It seems likely that a single master scheme could work well without blocking.

You can use i2c multimaster if you arbitrate access to the bus. Any shared bus will need arbitration and handle collisions.

jayben
Posts: 277
Joined: Mon Aug 19, 2019 9:56 pm

Re: Communication between multiple pico's

Fri May 07, 2021 9:55 am

The grinding noise you hear is the sound of a wheel being reinvented; didn't we solve this problem decades ago using networking? RS422, RS485, Ethernet etc....

If it has to be a cabled network I'd use cheap Ethernet modules, but wireless would be easiest. There are some projects using the EspressIF parts, but I'm using Microchip WINC1500 modules, which are cheap, fast, and remarkably capable; hope to publish code for the Pico in a few weeks time.

bobtrex
Posts: 27
Joined: Mon Jan 25, 2021 6:24 pm

Re: Communication between multiple pico's

Fri May 07, 2021 10:02 am

Don't forget you have the PIOs. So in theory you could have an extra 8 independent RX channels via PIO + the 2 UARTs.
Assuming the picos are local to each other you could send the work payload out on a TX connected to all the slave picos (each with an isolator) and the slaves could reply back via their independent RX.

danjperron
Posts: 3790
Joined: Thu Dec 27, 2012 4:05 am
Location: Québec, Canada

Re: Communication between multiple pico's

Fri May 07, 2021 10:28 am

So simply stated; I want to communicate between multiple pico's in both ways, what is the best protocol that I could use?
How far away each pico are from each other?
are they more than 3 meters ? No then use I2C or uart pin directly . You could disable the TX pin to create a modbus without RS-485.

Othwerwise use RS-485 or canbus. I'm using canbus on a small PIC microcomputer and at 125K baud I'm up to 100m without problem.
Last edited by danjperron on Fri May 07, 2021 1:48 pm, edited 1 time in total.

hippy
Posts: 9957
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Communication between multiple pico's

Fri May 07, 2021 10:59 am

PiGraham wrote:
Thu May 06, 2021 6:16 pm
Key phrase 'multidrop'
Shared data line driven with tri-stable outputs. All devices listen but only one talks at a time.
Given the OP's specification it might be that nothing more than digital signalling is needed; open collector outputs pulling the shared line low when a puzzle is completed.

The need for anything more has not been revealed.

PiGraham
Posts: 4733
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Communication between multiple pico's

Fri May 07, 2021 11:40 am

hippy wrote:
Fri May 07, 2021 10:59 am
PiGraham wrote:
Thu May 06, 2021 6:16 pm
Key phrase 'multidrop'
Shared data line driven with tri-stable outputs. All devices listen but only one talks at a time.
Given the OP's specification it might be that nothing more than digital signalling is needed; open collector outputs pulling the shared line low when a puzzle is completed.

The need for anything more has not been revealed.
The OP isn't all that clear, but "communication" "protocol" "UART" and "i2c" are all mentioned. Maybe there is more information to be exchanged than has been indicated.

You are quite right that simple signalling over multiple gpio lines would probably do the job. One master run/stop/reset gate signal from master to all slaves and one result signal per slave back to the controller seems to fit the task described.

User avatar
nick.mccloud
Posts: 1228
Joined: Sat Feb 04, 2012 4:18 pm

Re: Communication between multiple pico's

Fri May 07, 2021 11:53 am

lurk101 wrote:
Thu May 06, 2021 9:02 pm
If I understand correctly the OP has ruled out I2C and SPI since he does not want a single master bus. I can think of many situations where constant poling of multiple slaves by a master is undesirable.
So can I. But there are too many questions raised (like actual response time) plus the rather questionable observation on the maturity of I2C and SPI.
Pico/RP2040 ≠ Arduino
Pico = hot rod kit car, Arduino = hot rod kit car wrapped in cotton wool with buoyancy aids & parachute

lurk101
Posts: 590
Joined: Mon Jan 27, 2020 2:35 pm
Location: Cumming, GA (US)

Re: Communication between multiple pico's

Fri May 07, 2021 4:26 pm

PiGraham wrote:
Fri May 07, 2021 11:40 am
You are quite right that simple signalling over multiple gpio lines would probably do the job. One master run/stop/reset gate signal from master to all slaves and one result signal per slave back to the controller seems to fit the task described.
I understand that a single master individually poling a number of slaves is most often the easiest approach, but it fails badly when near instantaneous response is required at the master in response to events occurring at the slaves. What is the required poling interval? How small does it need to be to meet response delay requirements, and will that overburden the master with a poling task that will mostly receive negative responses?
The old semiconductor paradigms are rapidly becoming a thing of the past.
Today, it's about the best transistors, architectures, and accelerators for the job.

DarkElvenAngel
Posts: 1695
Joined: Tue Mar 20, 2018 9:53 pm

Re: Communication between multiple pico's

Fri May 07, 2021 5:55 pm

Well the master excuse me the farmer could simply listen on the line for one of his sheep to call out, this would replace the need to poll. The sheep in question could shout out it's ID then if needed the farmer could check on it and see it's status.

If you use a four wire full duplex RS 485 then you don't have to worry as much about bus conflicts and if you modify your protocol correctly this wouldn't be an issue.

lurk101
Posts: 590
Joined: Mon Jan 27, 2020 2:35 pm
Location: Cumming, GA (US)

Re: Communication between multiple pico's

Fri May 07, 2021 6:09 pm

DarkElvenAngel wrote:
Fri May 07, 2021 5:55 pm
Well the master excuse me the farmer could simply listen on the line for one of his sheep to call out, this would replace the need to poll. The sheep in question could shout out it's ID then if needed the farmer could check on it and see it's status.
Sorry, at my age I don't feel compelled to follow all the latest PC memes. So what happens if two slaves decide to call home at the same time? I believe coordination by a master node is still required for protocols like RS485. I like the master-less CANBUS model but I don't think it can be implemented on Pico without adding external circuitry. It requires that a pin be able to detect three different states, ground, VCC, and 1/2 VCC.
The old semiconductor paradigms are rapidly becoming a thing of the past.
Today, it's about the best transistors, architectures, and accelerators for the job.

DarkElvenAngel
Posts: 1695
Joined: Tue Mar 20, 2018 9:53 pm

Re: Communication between multiple pico's

Fri May 07, 2021 7:36 pm

I agree trying to make old conventions political correct is not something I do. The old naming scheme for better or worse is what it is.

However to answer your question about what to do if two nodes try to call the master device at the same time. Yes you would have a bus conflict but you should check the buses status to see that it's clear before using it. This still can lead to a conflict. That's where you need to have a protocol in place to deal with this case.

This is a simple protocol: The Server can send broadcast messages to all the nodes these are Initialize ; Shutdown ; ACK ; NACK. The nodes are able to send there ID if the puzzle is complete and the node is in an ONLINE State or a NACK or ACK to reply to a direct message.

To address bus conflict this is the scenario: (Lets Assume we are using an 8 bit Odd parity 1 stop bit UART setting)
When puzzle A finishes it will transmit "A" assuming the bus check is clear, at the same time puzzle F is finished and it checks and the bus is clear so it sends "F" the Server will receive the codes "A" and "F" anded together. The server is required to ACK each puzzle with it's ID and ACK now if Parity fails it will send NACK if parity is successful it will send the ID + ACK if a node doesn't receive a reply with in a defined time out it will send again. if a node is ACKnowleaged that didn't transmit it will send an NACK.

This might cause more problems this is just a quick off the top of my head protocol it could be better.

So each node needs to have a bus transceiver IC to deal with a 4 wire bus this needs to have the ability to check that the TX lines are not in use. Only the Server Node has access to write on to all nodes on the RX lines.

This all assumes that the OP only wants to know when a puzzle node is completed and can tell those node to reset and startup or shutdown time is up, it would be possible to send the ID ACK and have the puzzle respond with a ACK for solved or NACK for not solved as well

Like I said it's a dirty protocol that could use improvement. You could set it all up with CAT5 network cables and have room for extra signals if you wish as the described setup only needs 5 wires.

I don't know anything about CAN bus so it could be a good alternative.

User avatar
nick.mccloud
Posts: 1228
Joined: Sat Feb 04, 2012 4:18 pm

Re: Communication between multiple pico's

Fri May 07, 2021 7:58 pm

lurk101 wrote:
Fri May 07, 2021 4:26 pm
I understand that a single master individually poling a number of slaves is most often the easiest approach, but it fails badly when near instantaneous response is required at the master in response to events occurring at the slaves.
For an interactive puzzle what would be an appropriate response time?

At 400kHz with, say 10 bytes as a response to a read request, it's going to be very roughly 50ns, which implies, with some more padding (like 50%), 10,000 slaves ...
Pico/RP2040 ≠ Arduino
Pico = hot rod kit car, Arduino = hot rod kit car wrapped in cotton wool with buoyancy aids & parachute

PiGraham
Posts: 4733
Joined: Fri Jun 07, 2013 12:37 pm
Location: Waterlooville

Re: Communication between multiple pico's

Fri May 07, 2021 9:33 pm

nick.mccloud wrote:
Fri May 07, 2021 7:58 pm
lurk101 wrote:
Fri May 07, 2021 4:26 pm
I understand that a single master individually poling a number of slaves is most often the easiest approach, but it fails badly when near instantaneous response is required at the master in response to events occurring at the slaves.
For an interactive puzzle what would be an appropriate response time?

At 400kHz with, say 10 bytes as a response to a read request, it's going to be very roughly 50ns, which implies, with some more padding (like 50%), 10,000 slaves ...
Exactly. It seems very unlikely there would be any issues with blocking on a timescale that means anything to human players.

lurk101
Posts: 590
Joined: Mon Jan 27, 2020 2:35 pm
Location: Cumming, GA (US)

Re: Communication between multiple pico's

Sat May 08, 2021 1:14 am

PiGraham wrote:
Fri May 07, 2021 9:33 pm
nick.mccloud wrote:
Fri May 07, 2021 7:58 pm
lurk101 wrote:
Fri May 07, 2021 4:26 pm
I understand that a single master individually poling a number of slaves is most often the easiest approach, but it fails badly when near instantaneous response is required at the master in response to events occurring at the slaves.
For an interactive puzzle what would be an appropriate response time?

At 400kHz with, say 10 bytes as a response to a read request, it's going to be very roughly 50ns, which implies, with some more padding (like 50%), 10,000 slaves ...
Exactly. It seems very unlikely there would be any issues with blocking on a timescale that means anything to human players.
Agreed. Sorry for diverging a little. Much of this I've been thinking over as it applies to my own application.
The old semiconductor paradigms are rapidly becoming a thing of the past.
Today, it's about the best transistors, architectures, and accelerators for the job.

hippy
Posts: 9957
Joined: Fri Sep 09, 2011 10:34 pm
Location: UK

Re: Communication between multiple pico's

Sat May 08, 2021 10:06 am

lurk101 wrote:
Fri May 07, 2021 6:09 pm
I like the master-less CANBUS model but I don't think it can be implemented on Pico without adding external circuitry. It requires that a pin be able to detect three different states, ground, VCC, and 1/2 VCC.
The Pico has ADC so detecting three states isn't exactly hard. As comms distances will probably be room sized any bit rates will likely need to be on the low side anyway unless hardware drivers and specific cabling requirements come into play, but because it's game playing related I can't see that as a problem or there being that much data to communicate.

Master to all slaves on a single fanned-out line means no issues there, so it's only slave to master of any concern.

I still think polling for a response is the best solution. If slaves share a multi-drop line it doesn't matter if there's any collision; each slave finishing just brings that line low, the master can then tell all slaves to relinquish that signal, poll in sequence to ask if they signalled finishing.

That then moves us to how slaves can be ID'd. One way to do it is how 1-wire devices do it; ask for what Unique ID each Pico has a bit at a time. Algorithms for doing that which handle collisions are well defined. Then the master can allocate a 0..N number to each, tell each slave with its Unique ID what its 0..N ID is, run with that. That may be a little involved but it's not complicated and it only needs to be done at start-up of the network.

This has all been implemented with 8-bit micros far more constrained than the Pico so I can't see any problem for the Pico.

Don't forget we are likely in a scenario where low-cost and adding only resistors and diodes is desirable and compromise will be acceptable. It's not a fly-by-wire system.

bugfest
Posts: 2
Joined: Wed May 05, 2021 7:36 pm

Re: Communication between multiple pico's

Mon May 10, 2021 7:16 am

PiGraham wrote:
Thu May 06, 2021 6:16 pm
RS485
Key phrase 'multidrop'
Shared data line driven with tri-stable outputs. All devices listen but only one talks at a time.
After some experimenting I've implemented this. I wanted a simple solution and there will always be only one device (The master/farmer or slave/sheep :P ) that is talking.

Thanks for all the information provided!

Return to “General”