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

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.

"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 

On Sun, 10 Sep 2006 00:09:58 +0100, "Steve at fivetrees"
<steve@NOSPAMTAfivetrees.com> wrote:

>"rickman" <gnuarm@gmail.com> wrote in message 
>news:1157836725.357645.139340@d34g2000cwd.googlegroups.com...
><snippety>
>> 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.

This may seem to be a problem from the application layer point of
view, however, the application layer that will process the data must
know what type of devices there are on the bus. This usually requires
some configuration in the application layer, so the node numbers can
also be decided in advance. Thus, you can simply set the address for
each node (e.g. with DIP switches), before connecting the node to the
line.

Polling all possible addresses would be useful only if all the
possible devices respond with a type code or serial number which is
available from a well known address in each slave. For PLCs and other
programmable devices, you would also have to obtain the information of
what software each devices are running and if multiple nodes with the
same software, into which real word sensor cabling each device is
connected. From this, the application layer can then build a map,
which node number is connected to which external sensor cable. To be
practical, this would require reserving some PLC input pins just for
identification by wiring some jumpers differently in each sensor
cabling.

While most fieldbus systems have a well specified way to identify the
device type (usually device profile) by inquiring it on-line, for
instance in Modbus RTU, devices have no standard way to identify the
device type, so a lot of heuristics is usually needed to find out
which device is which, even from a limited selection of types.

Thus, whatever you do, you have to configure the node information in
one way or other. Thus, specifying the node numbers in the application
and setting the device physical address accordingly is still a viable
option and no polling for nev nodes is required.

Paul

"rickman" <gnuarm@gmail.com> wrote in message 
news:1157836725.357645.139340@d34g2000cwd.googlegroups.com...
<snippety>
> 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.

However, I think there are simpler ways...

Steve
http://www.fivetrees.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?


> 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.


> 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?

On the other hand, while E1 would be very impractical to implement, a
round robin approach could be used if you did not want to have a single
bus master.  Each node would have a unique address.  The address is
used at the start of a header for a message to be sent.  Each node
sends a message when it is their turn, even if it is a NULL message.
If a node does not respond to its timeslot, the next node times out and
sends a message.  The node at time slot 0 would be able to recognize
the size of the network and respond with its message when the last node
in the system had transmitted.  An enumeration scheme could be
implemented at this boundary time to allow a new node to join the
network and have a node number assigned dynamically.  Even the
assignment of a node number assignment "master" could be done when the
system is turned on.  Each node would wait a random amount of time
(beyond some minimum) and the first one to query the network would be
node 0.  The next one would be node 1, etc.

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.

> 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.

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..

.
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.

If you just want RS-485 over UART, then maybe the AT91 UART still can be 
interesting
due to its H/W support for the RS-485 enable signal.
It supports manchester encoding as well.


> 2. I have read that may be ModBus protocol could be used. Can I
> communicate directly to the RS-232 send and receive routines from the
> Modbus module or do I need more layers of software in between ?
>
> Please help.
>
> Thanks and regards,
> Mehul
>



-- 
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 

Grant Edwards wrote:

> Or use async-hdlc framing like PPP does.  That's simple.

Yep. PPP HDLC solves frame delimiting, error detection,
and transparency issues.


-- 
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
Kennesaw, GA, USA 30144    http://mnmoran.org

"So often times it happens, that we live our lives in chains
  and we never even know we have the key."
The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

Grant Edwards wrote:
>
> It [ModBus] burns a lot of CPU at high baud rates since you've got to
> run an interrupt-per-byte.  If you've got to do multiple
> interfaces at high baud rates, it starts to seriously suck.

Well, you have to compare the interrupt-per-byte loading with the
message-processing loading.  If you've got high-speed messages coming
and going on multiple interfaces, you've got to devote more CPU time to
processing these messages anyway.  The interrupt-per-byte cost is going
to remain nearly the same relative to the message-processing cost
regardless of how high or low your baud rate, or how many ports you're
running.  So the key question is, how much processing time does the
average message require?  Once you attach a number to that, you can get
an idea how much more your interrupt-per-byte will cost you.

"mehulag" <mehul@hcl.in> wrote in message 
news:oqudnVQsvqtXbZ_YnZ2dnUVZ_s6dnZ2d@giganews.com...
>
> Thanks for your valuable suggestions.
>
> Can you let me know of some other workable solutions which are easier to
> implement. I just read about Modbus being used for RS485 and asked. I dont
> know of it's advantages and disadvantages.

Don't let the details here put you off. A roll-your-own RS-485 system isn't 
hard - yes, there are a few pitfalls for the unwary, but nothing really 
hard. I've dealt with this stuff a lot, as have others here. If you have 
specific questions, ask away.

> Also if you know of any
> controllers which offer RS485 support, please let me know.

RS-485 is a hardware standard, so it's nothing really to do with the 
controller as such. Beyond what you'd need for RS-232, you'd need a line to 
turn the bus around (which you might have needed for h/w handshaking 
anyway), and you'll almost certainly need a timer. Otherwise, it's just 
plain-vanilla async serial NRZ comms.

Steve
http://www.fivetrees.com