centralware
Posts: 15
Joined: Thu Apr 02, 2015 8:57 am

Shared I2C Slaves With Multiple Pi?

Tue Jan 24, 2017 3:33 pm

Would it be possible to connect multiple RasPi boards (I2C bus) to, say, a single Real Time Clock where the RTC could be polled by each of the Pi's separately?

Theoretical Layout:

* A dozen or so RaPi2B/3B boards
* One or more I2C slave devices
* All devices powered by the same supply

I don't have RTC chips or modules in stock at the moment, but was considering a project which would need it and granted, they're cheap enough to add to each Pi without issue, but I was curious as to whether or not the Pi's could all "share" slave devices on I2C (secondary) such as RTC, E2PROM and expanders (assume Read-Only as only one master would be given permission to write to a given slave device.)

User avatar
DougieLawson
Posts: 36331
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: Shared I2C Slaves With Multiple Pi?

Tue Jan 24, 2017 3:43 pm

centralware wrote:Would it be possible to connect multiple RasPi boards (I2C bus) to, say, a single Real Time Clock where the RTC could be polled by each of the Pi's separately?
Not possible.

Run just one Raspberry with the RTC as an NTP master. Run the other Raspberries as NTP clients.

Master /etc/ntp.conf

Code: Select all

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
driftfile /var/lib/ntp/ntp.drift

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server 0.ubuntu.pool.ntp.org burst iburst maxpoll 11
server 1.ubuntu.pool.ntp.org burst iburst maxpoll 11
server 2.ubuntu.pool.ntp.org burst iburst maxpoll 11
server 3.ubuntu.pool.ntp.org burst iburst maxpoll 11

server ntp.ubuntu.com

restrict 127.0.0.1
restrict -6 ::1
restrict 192.168.1.0 mask 255.255.255.0

# IPv6 prefix goes in here
restrict 2001:pppp:pppp:pppp:: mask ffff:ffff:ffff:ffff::
broadcast 192.168.1.255
broadcast ff05::101
keysdir /etc/ntp
crypto
Client /etc/ntp.con

Code: Select all

driftfile /var/lib/ntp/ntp.drift

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server 192.168.1.11

# IPv6 server address goes here
server 2001:pppp:pppp:pppp::1

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery
restrict 127.0.0.1
restrict ::1
keysdir /etc/ntp
crypto
broadcastclient
multicastclient
manycastclient
That's running on my small collection of eleven Raspberries. They all sync to the master machine (which syncs to the 'Net).
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

centralware
Posts: 15
Joined: Thu Apr 02, 2015 8:57 am

Re: Shared I2C Slaves With Multiple Pi?

Tue Jan 24, 2017 4:44 pm

Any hint as to the why it's not possible would be very helpful. (Theoretically, using a shared GPIO to act like an RTS signal, I've already come up with a possible way to prevent cross-talk between masters, I just haven't put a test cluster together yet to prove concept.)

Having a single Pi within the cluster act as NTP "probably" wouldn't pan out well in my situation (as noted, all devices under the same PSU - once the PSU launches, all Pi's would boot simultaneously and by the time NTP service was running, there's a good chance most of the other Pi's would be well past the point of polling ntpdate) but I appreciate the thought.

User avatar
mikronauts
Posts: 2729
Joined: Sat Jan 05, 2013 7:28 pm
Contact: Website

Re: Shared I2C Slaves With Multiple Pi?

Tue Jan 24, 2017 5:12 pm

While I2C can support multiple masters, I seriously doubt the default driver supports multi-master mode, and I am certain the RTC driver would not support it.

This would result in occasional data corruption, if slave output stream was disrupted, or lack of a response from the slave if one master clobbered another master's request.

The only way I can see of doing this without corruption is for only one Pi to act as the master, while the other Pi's watched the I2C bus for slave responses.

Do keep in mind the I2C signal length limits.
centralware wrote:Any hint as to the why it's not possible would be very helpful. (Theoretically, using a shared GPIO to act like an RTS signal, I've already come up with a possible way to prevent cross-talk between masters, I just haven't put a test cluster together yet to prove concept.)

Having a single Pi within the cluster act as NTP "probably" wouldn't pan out well in my situation (as noted, all devices under the same PSU - once the PSU launches, all Pi's would boot simultaneously and by the time NTP service was running, there's a good chance most of the other Pi's would be well past the point of polling ntpdate) but I appreciate the thought.
http://Mikronauts.com - home of EZasPi, RoboPi, Pi Rtc Dio and Pi Jumper @Mikronauts on Twitter
Advanced Robotics, I/O expansion and prototyping boards for the Raspberry Pi

User avatar
DougieLawson
Posts: 36331
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: Shared I2C Slaves With Multiple Pi?

Tue Jan 24, 2017 5:40 pm

mikronauts wrote:While I2C can support multiple masters, I seriously doubt the default driver supports multi-master mode, and I am certain the RTC driver would not support it.
The hardest part would be the synchronisation and locking so that two masters didn't attempt to read the sensor simultaneously. You'd also need to tie all the board ground lines together to prevent stray voltages causing strange effects on the I²C bus.
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

centralware
Posts: 15
Joined: Thu Apr 02, 2015 8:57 am

Re: Shared I2C Slaves With Multiple Pi?

Tue Jan 24, 2017 6:07 pm

@mikronauts: Thank you for your reply.
Yes, after six hours of researching/"Googling" IIC protocol at the driver level, sadly, specifying Raspberry Pi in the search query made the results limiting to a fault; removing Pi from the equation I finally came across MultiMaster protocols which are not intended for Pi (which from what I understand simply doesn't support arbitration, but does claim to support clock stretching) however, just because the drivers don't support it doesn't mean the missing arbitration can't be scripted in! :D

A single, shared GPIO is sufficient to act as BUSY (as if the active Master were to say "Hey, I've got the line, now!") yet a second may be prudent to help ensure a Master who THINKS is in control can test to try and make sure of it, as opposed to two or more Masters trying to grab the line at the same time. The logic "should" be somewhat simple, considering collision prevention being more of a priority than response speed.

@anyone: Opinions requested to see if this logic can be improved:
Assume: GPIO #1 (BUSY) OUTPUT, #2 (VERIFY) OUTPUT used in the boot sequence of RasPis
Using RTC example shared between 16+ RasPi and a few different slave devices on Pi i2c Secondary bus all being utilized during this cycle:

Code: Select all

<CYCLE>
     GPIO #1: Set INPUT and READ, if HIGH, start over
     GPIO #2: Set INPUT and READ, if HIGH, start over
     GPIO #1: Set OUTPUT, VALUE=HIGH

     X=RAND(1-5) (Number of Loops) and Y=RAND(1-5) (Duration x50ms)
     Loop/Sleep X*Y, READ GPIO#2, IF HIGH, start over
     GPIO #2: SET OUTPUT, VALUE=HIGH
     <Tend to I2C slave communication needs here>
     Reset both GPIO to INPUT and EXIT CYCLE
</CYCLE>

centralware
Posts: 15
Joined: Thu Apr 02, 2015 8:57 am

Re: Shared I2C Slaves With Multiple Pi?

Tue Jan 24, 2017 6:10 pm

DougieLawson wrote:You'd also need to tie all the board ground lines together to prevent stray voltages causing strange effects on the I²C bus.
Feedback ("stray voltage") is tended to in the description above - all boards and devices are fed from the same regulated power supply.

User avatar
mikronauts
Posts: 2729
Joined: Sat Jan 05, 2013 7:28 pm
Contact: Website

Re: Shared I2C Slaves With Multiple Pi?

Tue Jan 24, 2017 6:18 pm

You are most welcome.

Yes, using a shared GPIO, set up as open collector and checking for multiple masters trying to pull it low "simultaneously", would work fine as a hardware semaphore.
centralware wrote:@mikronauts: Thank you for your reply.
Yes, after six hours of researching/"Googling" IIC protocol at the driver level, sadly, specifying Raspberry Pi in the search query made the results limiting to a fault; removing Pi from the equation I finally came across MultiMaster protocols which are not intended for Pi (which from what I understand simply doesn't support arbitration, but does claim to support clock stretching) however, just because the drivers don't support it doesn't mean the missing arbitration can't be scripted in! :D

A single, shared GPIO is sufficient to act as BUSY (as if the active Master were to say "Hey, I've got the line, now!") yet a second may be prudent to help ensure a Master who THINKS is in control can test to try and make sure of it, as opposed to two or more Masters trying to grab the line at the same time. The logic "should" be somewhat simple, considering collision prevention being more of a priority than response speed.
http://Mikronauts.com - home of EZasPi, RoboPi, Pi Rtc Dio and Pi Jumper @Mikronauts on Twitter
Advanced Robotics, I/O expansion and prototyping boards for the Raspberry Pi

User avatar
DougieLawson
Posts: 36331
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: Shared I2C Slaves With Multiple Pi?

Tue Jan 24, 2017 6:28 pm

mikronauts wrote:You are most welcome.

Yes, using a shared GPIO, set up as open collector and checking for multiple masters trying to pull it low "simultaneously", would work fine as a hardware semaphore.
I have to say I think my master/client NTP software configuration is going to be a billion times easier.
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

User avatar
mikronauts
Posts: 2729
Joined: Sat Jan 05, 2013 7:28 pm
Contact: Website

Re: Shared I2C Slaves With Multiple Pi?

Tue Jan 24, 2017 8:28 pm

totally agreed!
DougieLawson wrote:
mikronauts wrote:You are most welcome.

Yes, using a shared GPIO, set up as open collector and checking for multiple masters trying to pull it low "simultaneously", would work fine as a hardware semaphore.
I have to say I think my master/client NTP software configuration is going to be a billion times easier.
http://Mikronauts.com - home of EZasPi, RoboPi, Pi Rtc Dio and Pi Jumper @Mikronauts on Twitter
Advanced Robotics, I/O expansion and prototyping boards for the Raspberry Pi

centralware
Posts: 15
Joined: Thu Apr 02, 2015 8:57 am

Re: Shared I2C Slaves With Multiple Pi?

Wed Jan 25, 2017 1:29 am

Easier: This may be true in a networked environment, but in some instances ethernet isn't going to be an option thus I need to consider more "direct" approaches where applicable. Also bare in mind that the OS being utilized is very "bare bone" (Tiny Core Linux with a custom kernel and boot image) and though it wouldn't take much to add networking back into the mix, it wasn't planned for.

PLUS... it's also the point of doing things people say can't/shouldn't be done. :D

Note: The actual project will eventually have six Pi boards, no ether/bt/wireless and the only need for RTC and E2PROM would be accurate time-stamping in the log files and reading PROM bits to determine the task needing to be done for a given board, both being done through I2C would simplify having to dedicate separate externals per board. The boards themselves are launched (powered up) by a momentary SPST which latches a set of SCRs (one per pi); when the board completes its task, it shuts down its SCR and therefore kills power to that board. (HDMI, LEDs, etc. all being shut down to prevent wasted resources.)

User avatar
DougieLawson
Posts: 36331
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website Twitter

Re: Shared I2C Slaves With Multiple Pi?

Wed Jan 25, 2017 9:55 am

They're so cheap that one RTC per Raspberry is really the best hardware option.

A DS3231 on a simple carrier board costs a fiver https://thepihut.com/products/mini-rtc- ... spberry-pi

The Chinese are knocking those out for half that @ £2.41
http://www.ebay.co.uk/itm/DS3231-Precis ... 2007012738
Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Any DMs sent on Twitter will be answered next month.

This is a doctor free zone.

Return to “Interfacing (DSI, CSI, I2C, etc.)”