On Tue, Jul 17, 2001 at 07:59:05AM -0400, Olin Lathrop wrote: > > For my project that uses an RS485 network I was planning to use a token > > ring system so I don't have to deal with collision detection. > > That's going to be tough because RS-485 is a multidrop bus, not a ring. You > could implement a ring from individual point to point RS-232 connections, > but that would require two UARTs per node. Actually it doesn't. A true single direction ring can be made with a single USART. Consider this: ----------+ +-----------+ +----------+ +----------- | | | | | | ________ ________ ________ | R X| | R X| | R X| -------- -------- -------- Each node has a single USART where the transmitter of one is paired with the receiver of the next. It can even be done with EIA-485 but each node would require two transceivers instead of one. It can be done. Probably isn't practical for the application though. > > > The solutions I've seen posted so far (and on piclist.com) all seem to > > be of the bitbang variety. Since I'm using 16F877's for this project it > > seems like a waste to bitbang stuff when I have a nice USART to use. Has > > anybody done this yet? > > I'm not exactly sure what your question is but, yes, of course, many people > have written code for the built in UART. I've done this many times myself, > including some RS-485 bus applications. I think he was referring to collisions, not using the USART itself. > > > I'm thinking that if I leave the receiver enabled > > (im using a max487) the USART should receive a byte for every byte that > > it sends. If the two bytes are different a collision has occured. > > RS-485 isn't designed electrically for this sort of thing. For one thing, > the local node may see its own output signal correctly, but other nodes that > are also driving the bus might not. Secondly, multiple transmitters can > cause high currents. Basically, I wouldn't do this. Agreed. > > > Second, whats a good way of handling back-off > > and retransmission? > > RS-485 isn't suited for this. If you want arbitrary peer to peer > communication with no master, look into CAN. It is designed for exactly > this kind of operation. I wouldn't go this far. EIA-485 can work fine if a token bus protocol is implemented on top of standard multidrop connection. It can simulate arbitrary peer to peer quite easily. However as I pointed out in my other post, that adding a signalling channel out of band from the data can reduce the amount of negotiating time and the amount of dead time from passing the token to nodes who don't need to transmit. > > > If all the devices are set for the same back off time, or time > > increment, they'll just collide again. I guess I could implement a > > random number generator, but I'd rather not. Is there a good way to > > handle this? > > > > How should retransmission be handled? Obviously the sending device needs > > to retransmit the lost data, but how does the receiving device know that > > a collision has occured? If it doesn't know there's been a collision it > > might think the corrupted data is valid. > > This wheel has already been invented a few times. Check out how ethernet > and CAN do it, or the "global serial bus" on some Intel embedded processors > like the 80C152, although I don't know if that last one is still supported. But each of these implement collisions in the hardware level. EIA-485 does not. So those solutions will not apply. BAJ -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics