trying to adapt Nick Gammon's RS485 Rolling Master

using examples from Nick's RS485 page.

to be honest, i have read through the rolling master code several times, and my mind just can't seem to grasp what exactly it is doing, so it is difficult to adapt it.

firstly, i am not crazy about having to store in EEPROM the total number of devices. i think it needs just one device to broadcast the setting at initiation, or whenever needed. this would save upgrade headaches.

my intended use of the project is for a model train layout, where i will have remote modules around the layout. each remote module will be configured for it's locations needs. in other words, each device will have some common code for the RS485 protocol, but what it does with it will be independently coded. but there will really only need to be one master, so to speak. it will receive commands via a serial port, and then broadcast the data to the RS485 bus (when it has it's turn), the device that has been coded to use the data will parse it, while all others ignore it.

the data will be simple, in that it will have a function ID, a command number, and a value. the device is responsible for figuring out what this data tells it to do. and if needed, such as checking a sensor value, or a group of values, the device will wait it's turn to send back the needed data. again, the function ID, so it knows where it came from, the command number that requested it, and the value, or perhaps a set of values.

now i just have to figure out how to apply this all to the code from Nick's example.

i haven't ventured out of the "Bar" in a while, so please go easy on me ;)

On this project i have just gotten so mentally overwhelmed trying to figure it out that i am not sure where to even start.


Nick's system is great for guaranteed delivery. Every device has a timeslot and it can always talk in that timeslot.

For a more dynamic network, like the WiFi at the local Starbucks, you can't do this. You don't know in advance which devices are going to arrive or leave.

For a model train layout, I would go with the guaranteed-timeslot version. The only problem is you may find that one device has more data to send than it has timeslot available. The master controller is sending commands to many trains and switches. If that's really a problem, give that device two timeslots.

The EEPROM idea is really powerful. I have a number of devices all working together on a network where the networking code is about 50% of each Arduino's job. So I made one big program (network is now 10% of the code) and then every one is configured by manually entering a few menu options which the Arduino stores in its EEPROM. Now I can upload fresh code to every device (like I updated some network code) and I don't need to check that I loaded the display code onto the display. The display knows that it is the display.

If you always leave one spare slot at the end of the known devices transmitting then a new device can join the network. All devices can update their maximum-number-of-devices and the next set of transmissions will have a new slot at the end.

But what if a device leaves the network? Do you leave its slot open for a minute and then close up the gap? How do all devices synchronise closing the gap? Does #1 self-select as the master to command a gap closing? What if it's #1 which has left?

Addresses are now dynamic. Depending on which order they powered up, your different controllers will have different MAC addresses, so they need another identifier to say what they actually are. Nick's system always makes #2 the hall light, so you don't have to know anything more to send a message to the hall light.

You also lose guaranteed delivery by doing this. If an unlimited number of glitches can "join" the network, the original devices don't get any time to say anything. If you expect that you can never connect more than 32 devices then set the address space at 32 and just leave a lot of spare capacity while you're starting up with just 5 devices.

If you look at how CAN works, you will see that the network is considered to be overloaded when it reaches 50% utilisation of the wire.

With AVRDUDE you can upload a hex file to the EEPROM directly.

But why would you develop the hex file on the PC? It’s much easier to have the Arduino save the various parameters to the EEPROM and use a human-readable interface. My usual system will have a “dump EEPROM” option which doesn’t dump the EEPROM at all - it just writes out longhand the variables which are dependent on the EEPROM. That makes it very easy to grab any unit from the field, kick it into command mode and then see what kind of device it thinks it is. It reports version number, what it is and all the other configuration parameters.

If you just need to change a configured time delay from 20sec to 50sec, then it is really nice to be able to see and change that in the serial interface, rather than having to get the raw EEPROM data, interpret it, change one value, re-save as hex and then re-upload with your custom uploader.

The menu code which drives this gets kind of messy but I’ve got devices controlling motors that can still control their motor while they’re servicing the configuration menu. I can make a config change and see the result while it’s still plugged in to the laptop.