Minimal token-passing network via RS485?

Thread Starter

John P

Joined Oct 14, 2008
2,025
I've set up an RS485 network with 4 nodes + my computer, which communicates via a USB-to-RS485 unit. The nodes are PIC16F345 processors, each with a MAX485 transceiver chip. It all works well in master-slave mode, with the computer as master, initiating every exchange. Now I'm wondering how difficult it would be to run the network as a token-passing system not requiring a computer. I've tried to find out whether anyone has done this before, in a minimal manner. It seems that token-passing schemes are quite complicated, and I don't want to use much of the processors' resources for this. How simple could a setup be, and still function robustly? It would need to start itself up, allow for nodes entering or leaving the bus, handle corrupted attempts at token-handling, and no doubt some other requirements I haven't thought of.

First of all, has this particular wheel been invented yet? I'd have thought that someone would have felt motivated to do it--but maybe it turns out to be so complex that a small processor can't handle it. Please don't say "Modbus"; that's master-slave only.

Second, is there any publication (preferably online) which describes the full requirements for such a system? If it hasn't been done already, I'd at least like to understand the features that a working system would need to have. Maybe then I'd decide that it's not worth trying, but at least I'd know why.

Here's my 4-node setup, with unit 25 controlling a couple of hobby servos, a reset switch on unit 40, and power to drive all the processors coming in on unit 26. The boards are meant to be linked by RJ12 connectors and cables, but I didn't have enough hardware to do it that way, so there are some other wires installed.

fournode.jpg
 

Thread Starter

John P

Joined Oct 14, 2008
2,025
P2P leads mostly to computer techniques, and what I'm looking for is connections that small microcontrollers can handle. But it just occurred to me that if anyone has done something like this, they very likely did it on an Arduino. So now I'm trolling the Arduino discussion groups! Here's one implementation that has some interest, for instance, though it uses assigned time slots rather than a token-passing scheme:
http://www.gammon.com.au/forum/?id=11428
 

MrChips

Joined Oct 2, 2009
30,707
I have implemented industrial RS-485 networks but they are all master-slave, not peer-to-peer.
Not having done P2P, here is how I would attempt a solution.

1) Choose a suitable baud. Determine typical message length and rate of usage.

2) All nodes are in receive mode.

3) Before a node can use the network the node will transmit a predetermined byte or sequence of bytes (RTS = Request To Send). The TX node will have its RX enabled and will read back the transmitted message. All RX nodes on receiving any transmission will inhibit any transmissions from itself for a duration determined by (1) plus a random number.

4) Should the TX node receive a corrupted message, it will delay resending RTS as per (1). Subsequent failures on RTS will increase the delay before attempting to resend RTS.

5) Should the TX node succeed in sending RTS, it will proceed to transmit its payload while monitoring its own TX.

6) Each TX message (excluding RTS) will adhere to the following protocol:

<START><TX ID><RX ID><COMMAND><MESSAGE><CHECKSUM><END>

7) Each RX with the correct RX ID will respond with:

<START><TX ID><RX ID><ACK><CHECKSUM><END>

(I have not decided if TX_ID and RX_ID should be swapped in the ACK confirmation.)
 

Thread Starter

John P

Joined Oct 14, 2008
2,025
NSASpook, I have looked at CDbus, and it has some ideas that I considered independently. Especially the use of signaling on the RS485 bus by manipulating the TX enable, to simulate a "wired-OR" condition, and copy CANbus's technique of putting a unit's address on the line and checking for errors (if two units do it at the same time). The trouble with that is that it's unpredictable how well an RS485 network would work in that mode--if it has maximum length, signaling that way would have to be slow. And in this publication, I see that the CDbus guy (whoever he is) does suggest using a lowered baud rate for that function, though he doesn't say how low:
https://dukelec.com/files/cdctl_bx_v12_200317.pdf

Ian0, I looked at BACnet too. That's specialized for air-conditioning and other machinery in buildings, and although it allows for multiple masters, apparently each one controls its own slaves and they don't communicate, except to stay out of each other's way. But I'm not sure if I got the idea right, because it seems very complex and although they say it's public domain, nobody explains what the protocol is. And the literature talks in terms of "objects" and "properties" when I just wanted to communicate between small processors! At least CDbus is on the kind of scale I was thinking of.

I'm coming to the conclusion that CAN Bus has swept the world because it's really good, and maybe we should all use it and stop thinking about alternatives. It certainly doesn't need to cost much:
https://www.ebay.com/itm/For-Arduin...160560?hash=item42020baab0:g:KvAAAOSwv2FfQ60y
 

Ian0

Joined Aug 7, 2020
9,667
Yes, CAN is fantastic - any node can send at any time, and with collision detection, checksums etc. every message gets through without errors, and plenty of microcontrollers with the hardware built in; which only loads the messages it is interested in. The downside is that it is limited to 8-byte messages. I can't say that the documentation that comes with the microcontrollers is the greatest. I took me a good week with the scope to understand what all the control bits did and to get it working.
It's low-power too, as when the data is "recessive" there is no driver dissipation power in the termination resistor.

I can't see how CDBus can do collision avoidance so well. EIA485 drivers drive both ways, so when there is a collision, one will be driving directly into another.

BacNET, which I'm just learning, gets around the collision by passing tokens, with only the owner of the token allowed to be master. And yes, you do have to BUY a copy of the standard!
 

Thread Starter

John P

Joined Oct 14, 2008
2,025
At this point my thinking has shifted to the point where I'm not going to try anything like a token-passing multi-master scheme on RS485. Fortunately I haven't put much time into it! A master-slave setup is fine--could be Modbus--but for anything more complicated, CAN Bus seems like the way to go. It just appealed to me more to let a processor's built-in UART handle interactions immediately, and I'm not so happy with the latency involved in CAN. But maybe that's just the way it has to work, if you want maximum robustness. I'm particularly attracted by the way CAN tolerates devices being added to or removed from a network. I've ordered a few of those modules I linked to earlier, but because they come from China, I can't try them out very soon.
 

Ian0

Joined Aug 7, 2020
9,667
I used the LPC11C24 and LPC1517 MCUs, they have built in CAN drivers, which eliminates the latency. They even store commonly used messages, so a single write to a single register sends the complete message. The 11C24 even includes the CAN driver. The way it filters the messages so only the ones that the processor is interested in actually interrupt the processor, is really smart. I use it in a very noisy environment, with contractors switching 100 Amps of 3-phase mains and it never misses a message, even on unscreened cable.
 
Last edited:

Thread Starter

John P

Joined Oct 14, 2008
2,025
I don't see how you can eliminate the latency in a CAN network, because a message gets transmitted after a delay that depends on how busy the bus is and what the message's priority is. With something like RS485, you know that what's on the line is what the processor's UART is sending, which I think is reassuring. But hey, the CAN scheme was designed by experts and refined over years of use, so of course it can never fail.
 

Ian0

Joined Aug 7, 2020
9,667
I suppose it depends a lot on how busy it is. If the bus is relatively quiet, CAN will send immediately, (8 bit times from the end of the last message), however, with token passing, it has to wait until it gets the token again, and even if no node has anything to say, the bus is still busy with token passing messages. True, the bus data reflects the UART’s output, but how much software overhead is required to detect and ignore irrelevant token-passing messages? With CAN the processor is free to get on with its main task unhindered.
 

Thread Starter

John P

Joined Oct 14, 2008
2,025
I suppose if there's a serial port, we're simply used to budgeting time in the software for the processor to deal with communication that way. But you're right, every byte that comes in has to be handled, and every packet evaluated to decide if it's relevant.

Incidentally, a serial network using the most common interface chips like MAX485 requires 3 processor pins on each node--RX, TX and TX enable. If you use an external CAN interface like the MCP2515, which communicates with the processor via SPI, you need 5 pins--data each way, clock, CE and interrupt. That might be more pins than you can spare. But then again, if you're already using SPI for something else, the port can probably be shared.
 
Last edited:

Ian0

Joined Aug 7, 2020
9,667
But with an INTERNAL CAN interface (like on the LPC1517) it only takes two pins (Rx and Tx) which connect to the MCP2551 transceiver (not MCP2515), and it generates an interrupt when it has received something relevant.
There's another bonus - it also keeps track of the number of bus errors
 

Thread Starter

John P

Joined Oct 14, 2008
2,025
I had to look up the LPC1517, and I see that it's a 32-bit ARM Cortex device! I'm using an 8-bit PIC processor, not even at the PIC18 level, so I think we're working at different scales. There actually are PIC processors with built-in CAN hardware, but I'm going to stick with an external interface for the moment. The boards that I've ordered from China have the MPC2515 for the logic, and a TJA1050 transceiver.
 

Ian0

Joined Aug 7, 2020
9,667
ARMs are nothing to be scared of (unlike the x86s that run Windows machines). I swapped from PICs to ARMs a few years ago. If you know the Atmel ATTINY and ATMEGA devices, then the ARM Cortex-M0 devices will seem very familiar.
The biggest plus is that you don't run out of numbers at 255.
The main difficulty in getting started is that they are designed for low power and so every peripheral can be switched on and off by a bit in a register SOMEWHERE. Finding it can be tricky!
 

Ian0

Joined Aug 7, 2020
9,667
They got the SAM devices when they bought Atmel. The PIC32s are something different.
My choice of the NXP devices was because their development software would run on my Apple iBook, and Microchip's MPLAB woudn't (at the time, but it now does)
 

nsaspook

Joined Aug 27, 2009
13,079
They got the SAM devices when they bought Atmel. The PIC32s are something different.
My choice of the NXP devices was because their development software would run on my Apple iBook, and Microchip's MPLAB woudn't (at the time, but it now does)
Sure, the SAM devices are now under the PIC32 umbrella. The MIPS PIC32s are the originals. The MIPS 4K hardware/software architecture is lean and to the point for small embedded programming.
Nothing wrong with ARM Cortex but it has the feeling of this at times.
327.jpg

A little too much of the bells and whistles.
 
Top