"rickman" <gnuarm@gmail.com> skrev i meddelandet news:1157836725.357645.139340@d34g2000cwd.googlegroups.com...> Ulf Samuelsson wrote: >> > I need to implement a proprietary network of various devices connected >> > over the RS-485. No third party device needs to be interfaced, all the >> > devices will contain the firmware written by me. >> > >> > 1. Is there any specification which tells me how the devices can be >> > addressed over the network and messages can be accepted by them ? Also, >> > are there any error correction methods recommendable for this network. >> > >> >> One possibility is to use a time slot bus. >> The time slot bus consists of >> >> * a clock >> * a frame sync >> * data >> >> Each device is allocated a time slot where it will drive the bus. >> A master will drive the clock and the time sync signal and the devices >> will >> then >> drive the data output during its allocated time slot. > > Doesn't this type of shared bus have at least a separate data and clock > and often a separate frame sync signal? >Yes, but it is only neccessary when you have significant delays on the bus. Telecom buses are there to handle km's of distance.>> A typical example are the E1 bus used in European Telecom equipment - >> also >> called 30B + D running at 2,048 MHz. >> The data is divided into frames of 256 bits (and you get 8000 frames per >> second) >> Each 256 bit frame is divided into 32 timeslots of 8 bits. >> 1 timeslot (T0) is used for sync, 1 timeslot for internal communication >> (T16) using the HDLC protocol >> and on top of the HDLC, a higher level protocol called SS7. >> The remaining 30 timeslots are for telephone calls using PCM coded >> Audio.. > > Yes, but E1 is not a multipoint bus. The signal is unidirectional with > multiple sources being multiplexed through a device, sharing a single > bus to the destination where the bus is broken out into multiple > signals again. This is way beyond the type of RS-485 application I > think the OP is asking about.No but it illustrates how the time slot principle is used.> >> The number of nodes and communication speed will determine if this is a >> useable approach. >> The SSC of the AT91SAM7 family and certain Telecom oriented PowerPC woudl >> be >> useable for this. > > How would you make this work with even just three nodes, each having a > single serial port connected to a shared RS-485 bus? >The master generates the clock and framesync and the all three send receive on the data bus. The Framesync is used to determine when the frame starts, and then each inidividual needs to make sure it only drives the bus when it is allowed to send. A normal UART cannot do this, but the SSC can. -- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may not be shared by my employer Atmel Nordic AB
Implementing communication over RS-485
Started by ●September 9, 2006
Reply by ●September 10, 20062006-09-10
Reply by ●September 11, 20062006-09-11
Ulf Samuelsson wrote:> "rickman" <gnuarm@gmail.com> skrev i meddelandet > news:1157836725.357645.139340@d34g2000cwd.googlegroups.com... > > Doesn't this type of shared bus have at least a separate data and clock > > and often a separate frame sync signal? > > > > Yes, but it is only neccessary when you have significant delays on the bus. > Telecom buses are there to handle km's of distance.No, you need a separate frame sync and separate clock to make this work. You could embed the frame sync and clock in the data stream if you are unidirectional, but this protocol has no way to turn the bus around for RS-485. The difference between RS-485 and other busses is the fact that it is half duplex, bi-directional. The type of interface you are describing does nothing to solve the issues that are part of this interface.> >> A typical example are the E1 bus used in European Telecom equipment - > >> also > >> called 30B + D running at 2,048 MHz. > >> The data is divided into frames of 256 bits (and you get 8000 frames per > >> second) > >> Each 256 bit frame is divided into 32 timeslots of 8 bits. > >> 1 timeslot (T0) is used for sync, 1 timeslot for internal communication > >> (T16) using the HDLC protocol > >> and on top of the HDLC, a higher level protocol called SS7. > >> The remaining 30 timeslots are for telephone calls using PCM coded > >> Audio.. > > > > Yes, but E1 is not a multipoint bus. The signal is unidirectional with > > multiple sources being multiplexed through a device, sharing a single > > bus to the destination where the bus is broken out into multiple > > signals again. This is way beyond the type of RS-485 application I > > think the OP is asking about. > > No but it illustrates how the time slot principle is used.To use time slots you need a master timing control. That is what the sync and clock signals are for. These do not exist in RS-485 and are impractical to add.> > How would you make this work with even just three nodes, each having a > > single serial port connected to a shared RS-485 bus? > > > > The master generates the clock and framesync and the all three send receive > on the data bus. > The Framesync is used to determine when the frame starts, and then each > inidividual > needs to make sure it only drives the bus when it is allowed to send. > A normal UART cannot do this, but the SSC can.So you would add another pair of signals so that all three parties can transmit in their assigned time slot? That is simply not what RS-485 is about. RS-485 is intended for low end applications (or at least this is the only place I have seen it used) where the number of wires was kept to a minimum. The concept is not hard to understand, it is the implementation using commonly available UARTs that gets messy. The newer MCUs properly support detection of the end of the stop bit so that the bus can be turned around. But many of the older devices still toggle the TxMT flag as soon as the last data bit is shifted out to the pin which is often way too soon. One way around this is to receive your own transmission. If you have received the last bit of the transmitted word, I would assume that it must include the stop bit to properly flag framing errors. So you can be assured that you have at least reached the middle of the stop bit (at least this is true for the devices I have tested). This is typically good enough timing to turn off the bus driver.
Reply by ●September 16, 20062006-09-16
Steve at fivetrees wrote:>> I am sure there would need to be a bit more detail ironed out, but I >> think this would allow for nodes to be added and removed dynamically >> and automatically. > > This is often a pain in "straight" RS-485 networks. Usually, the master has > to be told the bus population, or have a start-up poll phase. Simply waiting > for a node timeout on every possible address quickly stacks up to > $stupid_time.You can reduce "$stupid_time" by being a little clever - you don't have to poll for new nodes every time 'round, and you don't have to poll every address every time you poll for new nodes. Peter
