-
Multi Master Serial Protocol카테고리 없음 2020. 2. 23. 03:31
I just got 10 samples of MAX485 (half duplex RS485transceiver) today. I want to try and make a simple multi masternetwork using RS485 and PICs with hardware UARTs. Can anyone recommendwhere I can get started in terms of the protocol?I need a protocol driver for PICs or at least some information on howto implement my own. I have a general idea on how to send data betweenPICs but the largest concern is collision.
I don't know how toimplement collision detection/avoidance. How do you check if the lineis busy anyway?Also, the MAX485 has a receiver enable and driver enable pins.
This iswhat the data sheet says:-RE: Receiver Output Enable. RO sends data INTO the PIC is enabledwhen RE is low; RO ishigh impedance when RE is high.DE: Driver Output Enable sends data OUT from the PIC. The driveroutputs, Y and Z, are enabledby bringing DE high. They are high impedance when DE is low. Ifthe driver outputs are enabled, the parts function as line drivers.While they are high impedance, they function as line receivers ifRE is low.-So does this mean that the receiver and the driver should be kept inhigh impedance when I'm not doing anything? If it does, then how do Iknow when I should enable the receiver?- solarwind - -PIC/SX FAQ & list archiveView/change your membership options at.
The way I use that transceiver is to allow only ONE master to issuecommands, andeveryone on the network listens. Then the INTENDED slave (ONLY)answers. So sometimesa slave may not be interrogated for hours.My communications protocol is simple: the first byte is theDESTINATION (intended slave),the next byte is the COMMAND, and data pertaining to that datafollows.
To make sure theslaves received the command correctly, there is a CHECKSUM byte (orbytes) sent that represent a simple sum of all characters in themessage (except the checksum chars themselves). All slaves monitor thechecksum, and if they receive a bad checksum, they must IGNORE themessage because its data was corrupted. It might sound difficult, butin fact it is very simple to implement.
Even a better checksum scheme,such as CRC8 or CRC16 can be used to improve reliability; with CRC16you can send data on telephone lines for 1000 meters or more with veryfew repeats(if the slave fails to respond, you REPEAT the command).-Bob AOn Mon, May 11, 2009 at 2:12 PM, solarwind wrote. I just got 10 samples of MAX485 (half duplex RS485 transceiver) today.
I want to try and make a simple multi master network using RS485 and PICs with hardware UARTs. Can anyone recommend where I can get started in terms of the protocol?
I need a protocol driver for PICs or at least some information on how to implement my own. I have a general idea on how to send data between PICs but the largest concern is collision. I don't know how to implement collision detection/avoidance. How do you check if the line is busy anyway?
Also, the MAX485 has a receiver enable and driver enable pins. This is what the data sheet says: - RE: Receiver Output Enable. RO sends data INTO the PIC is enabled when RE is low; RO is high impedance when RE is high. DE: Driver Output Enable sends data OUT from the PIC.
The driver outputs, Y and Z, are enabled by bringing DE high. They are high impedance when DE is low. If the driver outputs are enabled, the parts function as line drivers. While they are high impedance, they function as line receivers if RE is low. So does this mean that the receiver and the driver should be kept in high impedance when I'm not doing anything?
If it does, then how do I know when I should enable the receiver? - solarwind - - PIC/SX FAQ & list archive View/change your membership options at -PIC/SX FAQ & list archiveView/change your membership options at. I typically tie the receiver enable (active low) and the transmitterenable (active high) together, then drive them with one pic pin. Connect apull-up resistor on the receiver output. Then, when you transmit, youwon't hear your own data. This cuts down on the amount of work your picneeds to do, since it will then not need to interpret and throw out itsown data.I generally form a packet and use a simple state machine to receive it.Packets are of the form:0xaa55 - flag start of packetLengthByte - How many bytes follow thisCRC or ChecksumPacketTypedataIt is more common to put the CRC or checksum at the end, but I find iteasier to find at a fixed location. I just use a union of structures totake the packet apart.
When caculating the crc or checksum, I set thatfield to 0, then calculate, then save the value. On receive, I pull thechecksum or crc out, set the field to zero, then calculate. If it matches,I've got a good packet.Packet Type tells me which structure in the union of structures to use ininterpreting the data.One trick on sending the data, is I enable the transmitter, then send0xff, then my packet (aa55, etc.). I follow the packet with another 0xff,then turn off the transmitter. This is because the uart is doublebuffered. If you turn the transmitter during the interrupt after you putin your last byte, the last byte will be lost, since it is then movingfrom the holding register to the shift register and has not yet beenshifted out.Good luck!Harold-FCC Rules Updated Daily at - Advertisingopportunities available!-PIC/SX FAQ & list archiveView/change your membership options at. - RE: Receiver Output Enable.
RO sends data INTO the PIC is enabled when RE is low; RO is high impedance when RE is high. DE: Driver Output Enable sends data OUT from the PIC. The driver outputs, Y and Z, are enabled by bringing DE high.
They are high impedance when DE is low. If the driver outputs are enabled, the parts function as line drivers. While they are high impedance, they function as line receivers if RE is low. So does this mean that the receiver and the driver should be kept in high impedance when I'm not doing anything? If it does, then how do I know when I should enable the receiver?No point in keeping both disabled, enable the receiver when you want to receive,enable the transmitter when you want to transmit.
As the two enable lines useopposite logic it is quite common to tie the two enable lines together so you onlyneed one control line from the micro. That way receiver is disabled whentransmitting, and when transmit is done you go back to listening to the bus. Easiestprotocols have one master, slaves are not allowed to transmit until they areaddressed and commanded to by the master.-Brent Brown, Electronic Design Solutions16 English Street, St Andrews,Hamilton 3200, New ZealandPh: +64 7 849 0069Fax: +64 7 849 0071Cell: +64 27 433 4069eMail:-PIC/SX FAQ & list archiveView/change your membership options at. Solarwind wrote: I need a protocol driver for PICs or at least some information on how to implement my own. I have a general idea on how to send data between PICs but the largest concern is collision. I don't know how to implement collision detection/avoidance.I don't remember who that was, but on one of the recent threads aboutthis issue that you started, someone posted a list of 4 methods whichseemed reasonably complete. Find that message before you continue.Gerhard-PIC/SX FAQ & list archiveView/change your membership options at.
On 11 May 2009 at 17:12, solarwind wrote: - RE: Receiver Output Enable. RO sends data INTO the PIC is enabled when RE is low; RO is high impedance when RE is high.
DE: Driver Output Enable sends data OUT from the PIC. The driver outputs, Y and Z, are enabled by bringing DE high. They are high impedance when DE is low. If the driver outputs are enabled, the parts function as line drivers. While they are high impedance, they function as line receivers if RE is low.
So does this mean that the receiver and the driver should be kept in high impedance when I'm not doing anything? If it does, then how do I know when I should enable the receiver? No point in keeping both disabled, enable the receiver when you want to receive, enable the transmitter when you want to transmit. As the two enable lines use opposite logic it is quite common to tie the two enable lines together so you only need one control line from the micro. That way receiver is disabled when transmitting, and when transmit is done you go back to listening to the bus. Easiest protocols have one master, slaves are not allowed to transmit until they are addressed and commanded to by the master.
Brent Brown, Electronic Design Solutions 16 English Street, St Andrews, Hamilton 3200, New Zealand Ph: +64 7 849 0069 Fax: +64 7 849 0071 Cell: +64 27 433 4069 eMail:One way to slightly simplify reception is to use a checksum that isthe 2's complement of the sum of the bytes sent. That way, on receiveyou just keep adding the bytes and if the total equals zero at theend, then then it's OK. (In this case the checksum is included in thecalculation).As Brent says, it's common to tie the transmit and receive linestogether and run as a common 'transmit enable' control. Thank you very much to EVERYONE who posted. You all have been very helpful.@Bob Axtell, Harold Hallikainen:This is exactly how I imagined the single master bus would work.
Now Igotta impliment the multi master protocol. Your ideas are reallyhelpful. Thank you.@Brent Brown: That logic is awesome.
Into my circuit it goes.@Gerhard: I'll find it:)@Richard Prosser: Thanks. I'll avoid using the circuitry though, untilI get more proficient with 'that kind' of electronics.- solarwind - -PIC/SX FAQ & list archiveView/change your membership options at. On Tue, May 12, 2009 at 5:12 AM, solarwind wrote: I need a protocol driver for PICs or at least some information on how to implement my own. I have a general idea on how to send data between PICs but the largest concern is collision.
I don't know how to implement collision detection/avoidance. How do you check if the line is busy anyway?I think the easier way is not to use RS485 and invent your ownmulti-master protocol. For example, in the previous threads,CAN or Ethernet are both recommended.It is possible to make RS485 multi-master but the hassle may notbe worth the efforts. One example here:-Xiaofan -PIC/SX FAQ & list archiveView/change your membership options at.
On Mon, May 11, 2009 at 10:46 PM, Xiaofan Chen wrote: I think the easier way is not to use RS485 and invent your own multi-master protocol. For example, in the previous threads, CAN or Ethernet are both recommended.What do you mean? Isn't RS485 the physical layer specification? I'mgoing to write my protocol over RS485. It is possible to make RS485 multi-master but the hassle may not be worth the efforts. One example here: It was done with CAN via a twisted pair half duplex line, so I want totry to do it over RS485.
For hobby purposes and low speeds, I shouldbe able to cook something up.-PIC/SX FAQ & list archiveView/change your membership options at. On Tue, May 12, 2009 at 10:57 AM, solarwind wrote: On Mon, May 11, 2009 at 10:46 PM, Xiaofan Chen wrote: I think the easier way is not to use RS485 and invent your own multi-master protocol. For example, in the previous threads, CAN or Ethernet are both recommended. What do you mean?
Isn't RS485 the physical layer specification? I'm going to write my protocol over RS485.I mean it is more difficult to define your own collision detection/avoidenceprotocol for multi-master RS485 than to switch to CAN/Ethernet. It is possible to make RS485 multi-master but the hassle may not be worth the efforts. One example here: It was done with CAN via a twisted pair half duplex line, so I want to try to do it over RS485. For hobby purposes and low speeds, I should be able to cook something up.-Xiaofan -PIC/SX FAQ & list archiveView/change your membership options at. solarwind wrote: I need a protocol driver for PICs or at least some information on how to implement my own.
I have a general idea on how to send data between PICs but the largest concern is collision. I don't know how to implement collision detection/avoidance.
I don't remember who that was, but on one of the recent threads about this issue that you started, someone posted a list of 4 methods which seemed reasonably complete. Find that message before you continue.This one from Harold Hallikainen?On Sun, May 10, 2009 at 4:34 AM, Harold Hallikainen wrote. Using a 485 bus, there are a variety of options for device to device communications without going through a master device. Here are some possibilities.
1. Use Aloha protocol where each device just transmits when it has something to send. If the overall traffic is low, most of the time there will be no collision. If missed data is not critical (the next sample is fine), only error checking on the receive side is required.
No retransmit is required. 2.
A master grants permission to each device to transmit in turn. This avoids collisions, but fails when the master dies. 3. Slotted network. Each node is granted a time slot when it is allowed to transmit. Each node has a timer that keeps track of which slot we're on. Received data (including that destined elsewhere) synchronizes the slot counter.
4. Mini-Slotted network. A sequence of short time slots (shorter than required for a message, but long enough for a node to start transmitting), are allocated, one to each node. As in slotted, each node has a timer and a mini-slot counter. When the mini-slot counter matches the node number, this node is allowed to start transmitting and does start transmitting if it has anything to say. On detecting data, all other nodes stop their mini-slot timers and hold off advancing the mini-slot counter until mini-slot time after the last byte is received. Then, they all start advancing the mini-slot counters again.
As with a slot system, each node synchronizes its mini-slot counter based on received traffic. I've also called this an 'absence of data token passing system.' A lack of data transmission passes the permission to transmit on to the next node. This is the system I used using Bell 202 modems on voice grade wire and radio circuits in the DRC190 ( ) Harold-Xiaofan -PIC/SX FAQ & list archiveView/change your membership options at.
Microcontroller Communication Protocols
Solarwind ha scritto: This looks really cool: What I really like is the idea on the bottom of the page for multi master collision detection.I read this with interest.I have gone kind of deep in developing a 485 multi master protocol,since 1997 or so. I started with some ideas of mine, then took a lookand 220V network modems, and CAN, and Ethernet, and else. I basicallywanted something useful for home automation (i.e. Not-so-high datarate), scalable (meaning 220V, 485, or wireless), low overhead etc.What I am currently up to, 'skynet' (I published it @ Microchip forumhere & there) is very similar to the above.I wanted to place a question for you all. I can't see a 'frame id' i.e.a counter in the above protocol: I found it mandatory to deal withrepeated packets and retransmission.What do you think about this?thanksDario-PIC/SX FAQ & list archiveView/change your membership options at. There is a problem with the collision detection method on an RS485 bus where the sender also controlls if there was a collision with it's own receiver.
As I wrote in another thread, when I tried this I found that the receiver often just sees the transmitted data from the closest transmitter, especially if they are on the same board (and chip) and there are some distance between the two colliding transmitters. Also having transient protection components on the board for the bus makes this harder. This means that both senders can see their message as valid and ignore the collision backoff.
Multi Master Serial Protocol Lookup
This may work fine if you set the bus up to have one dominant state and one recessive state by clamping the bus to the recessive state and just activate the transmitter when it is transmitting the dominant state. You can do this by connecting the transmitter enable signal to the uart tx signal and hard clamp the data input for the transmitter to the level that gives the dominant state. This method may however degrade EMI performance, reduce maximum cable length and reduce maximum data rate since one of the transmitted states is now passively pulled with resistors instead of actively driven with the driver.That sounds really cool and useful, but I have no idea what you'resaying. At this point, the level you're talking at is probably toohigh for me.-PIC/SX FAQ & list archiveView/change your membership options at. solarwind ha scritto: This looks really cool: What I really like is the idea on the bottom of the page for multi master collision detection.
I read this with interest. I have gone kind of deep in developing a 485 multi master protocol, since 1997 or so.
Spi Protocol
I started with some ideas of mine, then took a look and 220V network modems, and CAN, and Ethernet, and else. I basically wanted something useful for home automation (i.e. Not-so-high data rate), scalable (meaning 220V, 485, or wireless), low overhead etc.
What I am currently up to, 'skynet' (I published it @ Microchip forum here & there) is very similar to the above. I wanted to place a question for you all. I can't see a 'frame id' i.e. a counter in the above protocol: I found it mandatory to deal with repeated packets and retransmission. What do you think about this?I think they leave that up to the application; the frame id would haveto be part of the payload and handled one level up for the caseswhere it is needed.Gerhard-PIC/SX FAQ & list archiveView/change your membership options at.