Post by thread:[PIC] RS485 multi-master protocol + transceiver qu

Hey all. 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 ] -- http://solar-blogg.blogspot.com/

The way I use that transceiver is to allow only ONE master to issue commands, and everyone on the network listens. Then the INTENDED slave (ONLY) answers. So sometimes a slave may not be interrogated for hours. My communications protocol is simple: the first byte is the DESTINATION (intended slave) , the next byte is the COMMAND, and data pertaining to that data follows. To make sure the slaves received the command correctly, there is a CHECKSUM byte (or bytes) sent that represent a simple sum of all characters in the message (except the checksum chars themselves). All slaves monitor the checksum, and if they receive a bad checksum, they must IGNORE the message because its data was corrupted. It might sound difficult, but in fact it is very simple to implement. Even a better checksum scheme, such as CRC8 or CRC16 can be used to improve reliability; with CRC16 you can send data on telephone lines for 1000 meters or more with very few repeats(if the slave fails to respond, you REPEAT the command). --Bob A On Mon, May 11, 2009 at 2:12 PM, solarwind <spam_OUTx.solarwind.xTakeThisOuTgmail.com> wrote: {Quote hidden}> Hey all. 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 ] -- http://solar-blogg.blogspot.com/ > -

I typically tie the receiver enable (active low) and the transmitter enable (active high) together, then drive them with one pic pin. Connect a pull-up resistor on the receiver output. Then, when you transmit, you won't hear your own data. This cuts down on the amount of work your pic needs to do, since it will then not need to interpret and throw out its own data. I generally form a packet and use a simple state machine to receive it. Packets are of the form: 0xaa55 - flag start of packet LengthByte - How many bytes follow this CRC or Checksum PacketType data It is more common to put the CRC or checksum at the end, but I find it easier to find at a fixed location. I just use a union of structures to take the packet apart. When caculating the crc or checksum, I set that field to 0, then calculate, then save the value. On receive, I pull the checksum 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 in interpreting the data. One trick on sending the data, is I enable the transmitter, then send 0xff, then my packet (aa55, etc.). I follow the packet with another 0xff, then turn off the transmitter. This is because the uart is double buffered. If you turn the transmitter during the interrupt after you put in your last byte, the last byte will be lost, since it is then moving from the holding register to the shift register and has not yet been shifted out. Good luck! Harold -- FCC Rules Updated Daily at http://www.hallikainen.com - Advertising opportunities available!

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: .....brent.brownKILLspam@spam@clear.net.nz

2009/5/12 Brent Brown <brent.brownKILLspamclear.net.nz>: {Quote hidden}> 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: .....brent.brownKILLspam.....clear.net.nz > > One way to slightly simplify reception is to use a checksum that is the 2's complement of the sum of the bytes sent. That way, on receive you just keep adding the bytes and if the total equals zero at the end, then then it's OK. (In this case the checksum is included in the calculation). As Brent says, it's common to tie the transmit and receive lines together and run as a common "transmit enable" control. You need to make sure that you don't disable the transmit side until all the bits have been shuffled out. It is possible to have a circuit to control this driven off the transmit data but at high speeds it gets a bit tricky to not loose part of the start bit. If you connect the enable line directly to the transmit signal (as suggested elsewhere) you loose either the pull-down or pull-up capability and are likely to get more bit errors. In theory you can keep the receiver enabled during transmit and use this to check on data corruption due to collisions & noise, but I've never had much success with getting this to work properly. We just either control transmit and receive together or just control the transmitter and ignore any data received while transmitting. RP

On Tue, May 12, 2009 at 5:12 AM, solarwind <EraseMEx.solarwind.xspam_OUTTakeThisOuTgmail.com> 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 own multi-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 not be worth the efforts. One example here: http://www.keil.com/forum/docs/thread8794.asp -- Xiaofan http://mcuee.blogspot.com

On Mon, May 11, 2009 at 10:46 PM, Xiaofan Chen <xiaofancspam_OUTgmail.com> 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. > It is possible to make RS485 multi-master but the hassle may not > be worth the efforts. One example here: > http://www.keil.com/forum/docs/thread8794.asp 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.

On Tue, May 12, 2009 at 10:57 AM, solarwind <@spam@x.solarwind.xKILLspamgmail.com> wrote: > On Mon, May 11, 2009 at 10:46 PM, Xiaofan Chen <KILLspamxiaofancKILLspamgmail.com> 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/avoidence protocol 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: >> http://www.keil.com/forum/docs/thread8794.asp > > 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 http://mcuee.blogspot.com

On Tue, May 12, 2009 at 7:55 AM, Gerhard Fiedler <RemoveMElistsTakeThisOuTconnectionbrazil.com> wrote: > 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 <spamBeGoneharoldspamBeGonehallikainen.org> wrote: {Quote hidden}> 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 > (louise.hallikainen.org/BroadcastHistory/index.php/HallikainenAndFriends > ) > > Harold > -- Xiaofan http://mcuee.blogspot.com

> This looks really cool: > > http://www.bdmicro.com/code/robin/ > > What I really like is the idea on the bottom of the page for multi > master collision detection. > > Now the only thing left is to detect if the line is busy or not... Hmm... 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. 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. /Ruben ============================== Ruben Jönsson AB Liros Electronic Box 9124, 200 39 Malmö, Sweden TEL INT +46 40142078 FAX INT +46 40947388 RemoveMErubenTakeThisOuTpp.sbbs.se ==============================

Ruben Jönsson ha scritto: > 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. same here, as I probably already wrote. But I found I can almost live with it.

solarwind ha scritto: > This looks really cool: > > http://www.bdmicro.com/code/robin/ > > 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 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? thanks Dario

"Ruben Jönsson" wrote: > 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. Yes, using passive pull ups/downs to one state with lower impedence active drive to the other state does limit the top speed compared to active drive in both directions, but you can still get very useful results. CAN does exactly this and can go to 1Mbit/S. The NMEA2000 spec defines a CAN implementation for ships that runs at 200Kbit/S. With fully active drivers and dedicated point to point connections, like ethernet, you can get a lot faster than that, but a few 100 Kbit/S is quite usable in a lot of local telemetry applications. RS-485 is so 1990s. I haven't seen a new design with RS-485 in quite a while. I don't get why so many here are intent on riding the old dinosaur instead of using a modern replacement like CAN. The low level electrical layer is essentially the same if you want multi-master and collision detection. RS-485 ends there. CAN continues and defines collision detection, retry, packetizing, checksum, and message ID or address in the protocol with various silicon implementations cheaply available and accessible. With a 18F4580 both the hardware and software is simpler with CAN than RS-485. If anyone is afraid of CAN because they have to (gasp) read the data sheet carefully and think that using the peripheral is somehow complicated, they've got a rude surprise coming when they start trying to implement all that functionality in firmware. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000.

2009/5/15 Ruben Jönsson <rubenEraseME.....pp.sbbs.se>: > 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. > > 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're saying. At this point, the level you're talking at is probably too high for me.

Dario Greggio wrote: {Quote hidden}> solarwind ha scritto: >> This looks really cool: >> >> http://www.bdmicro.com/code/robin/ >> >> 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 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 have to be part of the <data> payload and handled one level up for the cases where it is needed. Gerhard

part 1 3393 bytes content-type:TEXT/PLAIN; charset=UTF-8 (decoded quoted-printable) On Fri, 15 May 2009, Olin Lathrop wrote: {Quote hidden}> "Ruben Jönsson" wrote: > > 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. > > Yes, using passive pull ups/downs to one state with lower impedence active > drive to the other state does limit the top speed compared to active drive > in both directions, but you can still get very useful results. CAN does > exactly this and can go to 1Mbit/S. The NMEA2000 spec defines a CAN > implementation for ships that runs at 200Kbit/S. With fully active drivers > and dedicated point to point connections, like ethernet, you can get a lot > faster than that, but a few 100 Kbit/S is quite usable in a lot of local > telemetry applications. > > RS-485 is so 1990s. I haven't seen a new design with RS-485 in quite a > while. I don't get why so many here are intent on riding the old dinosaur > instead of using a modern replacement like CAN. Baby steps! It's easy for old timers like us who have already aquired low level experience to progress to more complicated stuff like CAN. Going the low level RS232 and RS485 is kind of like starting on assembler before moving up to 'C'. You get to understand what's happening, laying down solid foundations of knowledge to build on so that you can debug the more complcated stuff. > The low level electrical > layer is essentially the same if you want multi-master and collision > detection. RS-485 ends there. CAN continues and defines collision > detection, retry, packetizing, checksum, and message ID or address in the > protocol with various silicon implementations cheaply available and > accessible. With a 18F4580 both the hardware and software is simpler with > CAN than RS-485. If anyone is afraid of CAN because they have to (gasp) > read the data sheet And pray that device works exactly as described (including the reference code in the app notes)... > carefully and think that using the peripheral is somehow > complicated, they've got a rude surprise coming when they start trying to > implement all that functionality in firmware. Yes but when you've got a black box running really fast (your CAN peripheral) doing all the magic without (or minimal) intervension it gets really hard to debug stuff unless you are really experienced and even then you sometimes need to use expensive kit like logic analysers and storage scopes. Doing it the hard way using firmware lets you slow things down even simulate them if you need to and best of all it gives you an appriciation of what the "black box" is doing when it comes time to migrate up to it. Regards Sergio Masci part 2 35 bytes content-type:text/plain; charset="us-ascii" (decoded 7bit)

On Fri, 15 May 2009, Dario Greggio wrote: {Quote hidden}> solarwind ha scritto: > > This looks really cool: > > > > http://www.bdmicro.com/code/robin/ > > > > 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 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? Yes I also belive it should be mandatory. For one thing it helps acknowledgement of packets that arrive out of sequence. For multi master collision detection, have you considered sending back the CRC as part of the ACK. If two masters have both sent packets and have not seen a collision and a slave has also seen a valid packet from one of the masters, sending back the CRC will inform (probably) one of the masters that there was a collision. Maybe include the ID of the node that the ACK is intended for? Regards Sergio Masci

sergio masci ha scritto: >> 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? > > Yes I also belive it should be mandatory. For one thing it helps > acknowledgement of packets that arrive out of sequence. Yep, I've been about this in the night, and actually Gerhard reply, saying that it can be placed at a higher level in the Protocol, makes sense. In my case it's not like this, at the moment. of course the overall result is the same, just a matter of cleanness of protocol and level. > For multi master collision detection, have you considered sending back the > CRC as part of the ACK. If two masters have both sent packets and have not > seen a collision and a slave has also seen a valid packet from one of the > masters, sending back the CRC will inform (probably) one of the masters > that there was a collision. Maybe include the ID of the node that the ACK > is intended for? Not sure what you mean here , Sergio. In my case, the ACK is a message on its own and not barely a flag in the Frame. If 2 masters send a packet to the same slave, there will be either a collision or the slave may receive only one of them and miss the other. In the 1st case, both masters will retry (maybe after a random delay - though often the devices will send packets after a human event, say a button press, which is random inherently), with the same FrameID and will wait for ACK again; in the 2nd case, the 1st master will be ok and the second will retry and, then, get a reply. So, yes, the replied ACK includes the destination ID (the master who sent the command in first place). Dario

sergio masci wrote: > Baby steps! > [...] >> [...] and think that using the peripheral is somehow complicated, >> they've got a rude surprise coming when they start trying to >> implement all that functionality in firmware. > > Yes but when you've got a black box running really fast (your CAN > peripheral) doing all the magic without (or minimal) intervension it > gets really hard to debug stuff unless you are really experienced and > even then you sometimes need to use expensive kit like logic > analysers and storage scopes. Doing it the hard way using firmware > lets you slow things down even simulate them if you need to and best > of all it gives you an appriciation of what the "black box" is doing > when it comes time to migrate up to it. There's no need to run CAN fast. I agree that setting up a CAN module is quite a bit more challenging than setting up a UART, but once you are at implementing a multi-master configuration, you're way past baby steps. I don't think Olin advocated for a complete beginner to implement his first single peer-to-peer connection with CAN. Gerhard

>> This looks really cool: >> >> http://www.bdmicro.com/code/robin/ >> >> What I really like is the idea on the bottom of the page for multi >> master collision detection. >> >> Now the only thing left is to detect if the line is busy or not... Hmm... > > Also found this: http://bacnet.sourceforge.net/ > > Token ring based Another token-passing bus: "ARCNET, The Engineer's Secret Weapon " http://electronicdesign.com/Articles/Index.cfm?AD=1&ArticleID=7702 >From the article: "ARCNET is one of the best-kept secrets in the world of embedded systems." "So if you're looking for a networking solution that's simpler to use than Ethernet and has higher performance than CAN, ARCNET is the answer. The secret is out." :-)

On Sat, 16 May 2009, Dario Greggio wrote: {Quote hidden}> sergio masci ha scritto: > >> 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? > > > > Yes I also belive it should be mandatory. For one thing it helps > > acknowledgement of packets that arrive out of sequence. > > Yep, I've been about this in the night, and actually Gerhard reply, > saying that it can be placed at a higher level in the Protocol, makes > sense. In my case it's not like this, at the moment. of course the > overall result is the same, just a matter of cleanness of protocol and > level. I am not contradicting Gerhard here. Yes the packet ID could be placed at a higher level in the protocol stack but so could many other things. Personally I'd push it way down and have fewer layers. I would justify this by saying: if every packet has X, Y and Z components and these components can be easily maintained by a low level layer then why bother extracting one of these componets into a higher layer. When talking about tiny MCUs more layers tends to equal more cost (code and variable space). {Quote hidden}> > > > For multi master collision detection, have you considered sending back the > > CRC as part of the ACK. If two masters have both sent packets and have not > > seen a collision and a slave has also seen a valid packet from one of the > > masters, sending back the CRC will inform (probably) one of the masters > > that there was a collision. Maybe include the ID of the node that the ACK > > is intended for? > > Not sure what you mean here , Sergio. > In my case, the ACK is a message on its own and not barely a flag in the > Frame. Many protocols I have encountered simply involve sending a packet from node A to node B and node B responds with a simple ACK or NACK (or sometimes just times out) and then node A retransmits or proceads with the next packet. I've even seen this where multiple nodes can start talking at the same time. > If 2 masters send a packet to the same slave, there will be > either a collision or the slave may receive only one of them and miss > the other. In the 1st case, both masters will retry As has already been mentioned, neither master might see the collision. > (maybe after a > random delay - though often the devices will send packets after a human > event, say a button press, which is random inherently), with the same > FrameID and will wait for ACK again; in the 2nd case, the 1st master > will be ok and the second will retry and, then, get a reply. > > So, yes, the replied ACK includes the destination ID (the master who > sent the command in first place). So we think the same here. Does the ACK include the packet ID of the packet being ACKed? Regards Sergio Masci

On Sat, 16 May 2009, Gerhard Fiedler wrote: {Quote hidden}> sergio masci wrote: > > > Baby steps! > > > [...] > > >> [...] and think that using the peripheral is somehow complicated, > >> they've got a rude surprise coming when they start trying to > >> implement all that functionality in firmware. > > > > Yes but when you've got a black box running really fast (your CAN > > peripheral) doing all the magic without (or minimal) intervension it > > gets really hard to debug stuff unless you are really experienced and > > even then you sometimes need to use expensive kit like logic > > analysers and storage scopes. Doing it the hard way using firmware > > lets you slow things down even simulate them if you need to and best > > of all it gives you an appriciation of what the "black box" is doing > > when it comes time to migrate up to it. > > There's no need to run CAN fast. I agree that setting up a CAN module is > quite a bit more challenging than setting up a UART, but once you are at > implementing a multi-master configuration, you're way past baby steps. I disagree. Getting point to point working is trivial compared with a multi master network. Once you get PtP working yes you have some experience which will help you with the network but getting the network working also requires baby steps. > I > don't think Olin advocated for a complete beginner to implement his > first single peer-to-peer connection with CAN. My mistake, this is exactly what I thought Olin was advocating. Regards Sergio Masci

sergio masci ha scritto: > > I am not contradicting Gerhard here. Yes the packet ID could be placed at > a higher level in the protocol stack but so could many other things. > Personally I'd push it way down and have fewer layers. I would justify > this by saying: if every packet has X, Y and Z components and these > components can be easily maintained by a low level layer then why bother > extracting one of these componets into a higher layer. When talking about > tiny MCUs more layers tends to equal more cost (code and variable space). Yep, same thought as mine - at least in the past years. Now that I've been dealing with MiWi, which means bigger PICs and mor horsepower (and also more knowledge by my side :) I *could* go with more levels etc. {Quote hidden}>>> For multi master collision detection, have you considered sending back the >>> CRC as part of the ACK. If two masters have both sent packets and have not >>> seen a collision and a slave has also seen a valid packet from one of the >>> masters, sending back the CRC will inform (probably) one of the masters >>> that there was a collision. Maybe include the ID of the node that the ACK >>> is intended for? >> Not sure what you mean here , Sergio. >> In my case, the ACK is a message on its own and not barely a flag in the >> Frame. > > Many protocols I have encountered simply involve sending a packet from > node A to node B and node B responds with a simple ACK or NACK (or > sometimes just times out) and then node A retransmits or proceads with the > next packet. I've even seen this where multiple nodes can start talking at > the same time. ok >> If 2 masters send a packet to the same slave, there will be >> either a collision or the slave may receive only one of them and miss >> the other. In the 1st case, both masters will retry > > As has already been mentioned, neither master might see the collision. Yep, this is true, in fact I'm not relying on that. ACK/NACK is the only thing that matters. >> So, yes, the replied ACK includes the destination ID (the master who >> sent the command in first place). > > So we think the same here. Does the ACK include the packet ID of > the packet being ACKed? No, not yet at least. In fact I believe that it would be useful - also because the FrameID in an ACK packet (as it is now) is almost useless, and could be replaced by the Original (master's) Frame ID. Dario

Xiaofan Chen ha scritto: > On Sun, May 17, 2009 at 9:05 AM, Russell McMahon > <spamBeGoneapptechSTOPspamEraseMEparadise.net.nz> wrote: >>> What I am currently up to, "skynet" ... >> Are you with Cyberdyne corporation*? > > Thanks. Now I know why Dario names the protocol "skynet". ;-) > And he is indeed with Cyberdyne corporation according to his > profile in the web. He must be a terminator movie fan. ;-) > http://en.wikipedia.org/wiki/Cyberdyne_Systems Yep, I'm a long time Terminator fan, since 1985 :) I used to belong in a company named "ADPM" for 17 years, last year we broke up and I went on my own with "Cyberdyne" :) That Skynet thing was born in 1992 with my first experimenting with a wired home automation network. Dario

solarwind ha scritto: > On Sat, May 16, 2009 at 8:39 PM, Dario Greggio <KILLspamadpm.tospamBeGoneinwind.it> wrote: >> www.microchip.com/forums/tm.aspx?m=221869&mpage=2 > > Hmm. All that's on that thread is an image. Do you have any code? > > Also, what kind of protocol is it? (Is it token ring type, for example)? It's a Multi-Master RS485 network. It's not a token ring, rather a CSMA-CD (ethernet like). Every node can transmit as wished. There is a network collision method (unfortunately, not working soooo good on 485 as others stated), and then a robust ACK/NACK and retransmission mechanism). 8bytes max data payload, currently implemented @250Kbaud over several installations with up to 400-500mt of cable (CAT-5). It seems to be rather tolerant of "stubs" and topology. I'm also using it with Nordic and other 2.4GHz devices (and 433MHz as well). Good for portability of code and/over devices. Average Packets take 1mS-2mS, and the ACKs always take some 1mS. This leads to some 1000bytes/sec of data throughput, which is good enough even for small LCD panels. I published the Packet format. I then have a full bunch of C++ classes to be used on PC (that I can share if interested) - think of them as Zigbee "classes for devices". At the PIC's (devices') side I've gone more low-level, as I said, mostly because this all began in Z80 assembler ad then ST6 assembler and 16F628 assembler... so there was not much room to "make it too smart" :) Dario

On Sun, May 17, 2009 at 7:03 AM, Dario Greggio <EraseMEadpm.toEraseMEinwind.it> wrote: {Quote hidden}> It's a Multi-Master RS485 network. It's not a token ring, rather a > CSMA-CD (ethernet like). > Every node can transmit as wished. There is a network collision method > (unfortunately, not working soooo good on 485 as others stated), and > then a robust ACK/NACK and retransmission mechanism). > > 8bytes max data payload, currently implemented @250Kbaud over several > installations with up to 400-500mt of cable (CAT-5). It seems to be > rather tolerant of "stubs" and topology. > I'm also using it with Nordic and other 2.4GHz devices (and 433MHz as > well). Good for portability of code and/over devices. > Average Packets take 1mS-2mS, and the ACKs always take some 1mS. This > leads to some 1000bytes/sec of data throughput, which is good enough > even for small LCD panels. > > I published the Packet format. I then have a full bunch of C++ classes > to be used on PC (that I can share if interested) - think of them as > Zigbee "classes for devices". > At the PIC's (devices') side I've gone more low-level, as I said, mostly > because this all began in Z80 assembler ad then ST6 assembler and 16F628 > assembler... so there was not much room to "make it too smart" :) It sounds really cool. Could you please share your source code with me? I would really appreciate it.