RS485 multimaster protocol

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm looking for multimaster RS485 protocol implemented on AVR. Do you know something like that?
If not, maybe someone can share with experience about developing it? It shouldn't be so hard, but I don't want to invent the wheel again.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Haven't tried this but have a look

http://www.bdmicro.com/code/robin/

Btw: BD is/was an AVRDUDE contributor .. I even think inventor.

/Bingo

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks, I’ve found it but the ROBIN implementation has a serious drawback – for collision detection it compares sent byte with received, and if comparison fail packet is resend. The problem is that it will fail only in short RS485 bus, if you have longer bus sender typically correctly receives his own bytes (generally locally transmitted bytes). But not necessary slaves on the other end of the bus. So collision detection will fail. That’s why I need something which is based rather on ACK/NACK mechanism. But maybe this implementation is a good starting point.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree.
In my opinion, ROBIN is incorrect. It is not possible to implement collision detection on RS485. Only error detection at the receiver is possible.

Collision detection requires dominant and recessive states, which RS485 does not have.

Consider the following: (1) Is multi master protocol really necessary for my application, (2) The ULAN protocol (3) J1939 (4) CAN Bus.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CANBus is ok, but it is expensive, and what is worse – it needs additional bus controller. Only AVR with 32k FLASH or more exist with build-in CAN controller. uLAN looks fine, but arbitration takes a long time, ant the protocol is relatively complicated. I'm thinking about frames 16-32 bytes long, so error detecting is ok for me, I don't need true collision detection. I only want to lower collision probability. I will try to make a compilation of uLAN and ROBIN and will see.
Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TFrancuz wrote:
CANBus is ok, but it is expensive, and what is worse – it needs additional bus controller.
What does this mean?

Each differential CAN bus node requires a single interface transceiver/driver chip.

Each RS485 bus node (differential by specification) also requires a single interface transceiver/driver chip. The RS485 interface chip typically has a Tx driver enable input pin, requiring an extra control signal line that CAN doesn't need or use.

The CAN bus doesn't require any additional bus "controller". The processor chip (when the CAN is integrated into the processor) and transceiver chip package count is identical for both CAN and RS485 implementations.

CAN has functional collision detection that requires limiting the total CAN bus length according to the CAN baud rate and bus propagation delays (worst case CAN bit time period sample window -vs- worst case CAN bus propagation delay). Typically this CAN bus length limit is around 30+ to 40 meters for 1 mbps baud, 100 meters for 500 kbps baud, 500 meters for 100 kbps baud..... up to 5000 meters for 10 kbps baud (YMMV).

CAN bus collisions in the arbitration field are transparent (no retries needed, the lower priority looser simply goes back into Rx mode).

The new ATmega16M1 chip is a 16k FLASH with CAN, but unfortunately these chips are not in the supply chain yet. The ATmega16C1 is a little less timer specialized, but is only available as an automotive chip (usually only in really high volumes).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Mike, that’s what I said – to implement CAN I need additional controller – for my purpose I need something like ATMega8, with small footprint. The only available AVR with integrated CAN controller is AVR with at least 32k, 16k version is not available to me, and I don’t have time to wait.
External CAN controller chip costs, and takes a precious space. I can redesign my circuit, so TxD will go to DE pin of RS485 transceiver, so I will functionally get something like CAN (RS485 with high level as recessive state). So I will be able to detect collisions. But it is not something I don’t want to do. So till now I’m searching for a solution which gives me a simple arbitration.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Is there one 'master' that can be the "master master"? If so, perhaps a variation of "Slotted Aloha" could work for you, and there would be no collisions.

Tom Pappano
Tulsa, Oklahoma

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks. I will try to implement a modification of CSMA/CA protocol. It seems to be easy and should work with RS485.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

TFrancuz wrote:
Mike, that’s what I said – to implement CAN I need additional controller - ...
No what you said was:
TFrancuz wrote:
CANBus is ok, but it is expensive, and what is worse – it needs additional bus controller.
That is what I was responding to. It doesn't matter if the CAN hardware exists in the processor chip or in an additional chip package, there is still only one single CAN controller per CAN bus node. I understand what you meant now.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

CDBUS is a collision avoidance protocol for RS485, it's an open source project and very easy to use: https://github.com/dukelec/cdbus_doc

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A 9 year dormant thread need to know this now?

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

‘World first’! That’s a bold statenent. There doesn’t seem to be technical stuff on github. When do we get to see that?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
A 9 year dormant thread need to know this now? Jim

 

Yes, actually.  I found it interesting.  I have an RS-485 network gadget in the testing phase right now, although collisions won't be a problem (only one master, and it dictates all communication) but it's an interesting addition to an old and apparently not-quite-solved problem.

 

So there.  ;-P   S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Scroungre wrote:
So there.  ;-P   S.

Well nah nah nah to you too! LOL:)

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The technical stuff is at the end of that page, I move it here for you: https://github.com/dukelec/cdbus_ip
The technical wasn't new, but you really can't find any controller for RS485 do things like this, isn't it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Long time ago I implemented a multi-master protocol over an RS485 network. It was in fact just a dual-master protocol. It was quite simple, the masters passed a "token" to each other.  They had addresses like any other slaves, and they knew each other's address. Based on that it was quite simple.

The funny thing is that the solution was dictated by the situation in the field. There were two identical distributed control systems (DCS) that was needed to be connected to a central PC that had a single COM port. The PC was untouchable/unchangeable. Also, the masters of the DCS didn't have any serial port other than the RS485 for the i/o devices.

We came with an RS232-RS485 converter for the PC and we connected both RS485 networks to it in a single bigger RS485 network. The PC wasn't the third master, it was a slave. This way it was easier.