RS-485 addressing - Page 2

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: RS-485 addressing

Quoted text here. Click to load it
     Oh, OK, I missed the fact that you need 0.5ms silence after the
last byte in order to declare the packet correct. However, didn't you
say that the packet length is fixed? In that case, you could know that a
potentially good packet has arrived, after receiving its last byte and
verifying the checksums (this is what I meant in my previous message).
Well, at that point, set a timer to generate an interrupt after, say,
0.6ms. The response routine to that interrupt can check if no more bytes
have arrived in the meantime, and if so, officially declare the packet
correct and start the response.
     All this is moot, of course, unless the processor you're using is
fast enough to handle such high interrupt rates.

Quoted text here. Click to load it


Re: RS-485 addressing
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

IMO that is a sign of a bad protocol.  Consider sending something
like:

   sync sequence
   senderid
   receiverid
   packetlgh
   cksumhdr
   optional further data with final cksumdata.

and the minimum transmission ends on cksumhdr, identified by a
packet lgh value of 0.  Now you always know when the transmission
ends, and need no time outs.  By ensuring that the sync sequence
never can occur in the message body (outside the sync proper) you
have the ability to abort transmissions at any time.  No gap
detection needed.

You can arrange any reliability level of error detection by
selecting the cksum mechanism(s).

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: RS-485 addressing
Quoted text here. Click to load it

I agree but that is the task at hand, for the moment.

Quoted text here. Click to load it


How do you do this?  By restricting the rest of the bytes to 7 bits or
some such?  Is that what you meant?  Or perhaps by using Mark parity
for the first byte and Space parity for the rest (or vice versa).  I'm
not sure if the chipset I'm stuck with supports changing the parity
bit dynamically.


Quoted text here. Click to load it

I would still need gap detection to detect if there were trailing "bad
byte(s)" tacked on to the end of the message packet (the message
packet is not valid if there are extra bytes at the end).  I agree
this is not a good way to do it but for now my task is to find the
best way subject to these requirements.

You (and others) have made some excellent suggestions.

Quoted text here. Click to load it

Re: Serial message framing, was: RS-485 addressing


--- clip clip ---

Quoted text here. Click to load it

I already answered once. Please get the RFC 1662
(<http://www.faqs.org/rfcs/rfc1662.html ) and read its part 4. There is a
method where the flag byte (0x7e) never appears in the payload without
restricting the transfer to 7 bits.

Please note also that it's not possible to reliably detect the gaps if there
is any FIFO in the serial interface. The same applies to generating proper
gaps on transmit side.

Tauno Voipio
tauno voipio @ iki fi




Re: RS-485 addressing
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

Why?  Once a message is received and validated, what possible
difference does later line noise make?  You can also always avoid
some particular characters by using escape sequences, thus
reserving synchronization abilities.

--
Chuck F ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: RS-485 addressing


--- clip clip ---

Quoted text here. Click to load it

Please *do not* base your packet framing on time gaps between characters in
a message transferred on an asynchronous interface (like Modbus binary
format). It's nearly impossible to stick to the spec in a PC (especially if
it's running Windows of any flavour).

Use a flag byte based scheme instead - like that of PPP in HDLC-like framing
(RFC 1662, part 4, Octet-stuffed Framing).

Been bitten by Modbus framing.

HTH

Tauno Voipio
tauno voipio @ iki fi




Re: RS-485 addressing

Quoted text here. Click to load it

Me too.  The only way to do it is with an interrupt on _every_
rx byte.  At high baud rates, that sucks royally.  The whole
gap-timing debacle made ASCII modbus look like a good design --
at least there was a unique delimiter byte.

--
Grant Edwards                   grante             Yow!  You were s'posed
                                  at               to laugh!
We've slightly trimmed the long signature. Click to see the full one.
Re: RS-485 addressing
Quoted text here. Click to load it

You could use a periodic timer interrupt to look at your receive data
buffer. If the amount of data in it is less than or equal to the last
time the ISR ran, there's gap. In that case, read any data remaining
in the uart receive fifo into your buffer. Then check the message to
see if it is valid, and reply if it is. The timer interval must be
less than 1 msec and greater than 500 usec plus the number of bytes in
the receive fifo times the transmission time per byte.

Jim McGinnis

Re: RS-485 addressing
Quoted text here. Click to load it

I was thinking about this idea.  The problem is, I'm not sure there is
enough time at the timer interrupt level (once the gap is detected) to
do all the processing (read the bytes out of the FIFO into RAM, do all
the error checking, process the data, construct a response, and stuff
the transmit buffer).  It seems a well-written RTOS would be needed to
create a task which could be called to do all this processing when the
timer interrupt detects a gap.  Is there some other way?

Re: RS-485 addressing
Quoted text here. Click to load it

Some RTOSes, SMX comes to mind for one, have a queue of ISR completion
function calls that run at a priority lower than any interrupt, but
higher than any normal task. (I think SMX called these "LSRs".)  An
ISR records minimal information in the completion queue and exits,
decrementing a interrupt nesting counter.. When the counter goes to
zero, the completion queue is checked and anything in it is executed
until it's empty, at which point control returns to non-interrupt
processing. Depending on your processor and/or interrupt controller,
you may have to either lower the current priority while executing the
completion functions, or play some tricks with the return stack to so
that you can execute the completion functions in a non-interrupt
context. Although there are certainly some subtle points in
implementing the queue yourself, it shouldn't be too much work.

A simpler but less elegant approach is to set a flag -- an event flag
if you're using a RTOS -- that signals -- or awakens -- a routine to
validate and reply to the message.

BTW, my original idea was a bit _too_ simple. You'd need to look at
the total amount of data in the fifo plus the buffer, and also
distinguish between starting versus the continuing a gap.

Jim McGinnis





Re: RS-485 addressing
On 13 Nov 2003 19:31:44 -0800, in msg

Quoted text here. Click to load it

Inside your receive character interrupt do the following:

 Restart a timer each time a character is received by your UART
 interrupt routine.  Set the timer to go off in 1ms, also set
 a flag indicating "Character Received". Each character
 received restarts the timer, and sets the flag.

 As long as characters are being received with a less than
 a 1ms gap, the timer will not trigger. If a gap of 1ms occurs
 between characters, the timer will trigger an interrupt
 indicating an end of packet gap.

1) To start looking for a packet, set the same timer used above to 30ms, and
reset the "Character Received" flag.

2) When the timer interrupt occurs, check the "Character Received" flag, if it
is not set, then nothing has been received for 30ms, do error recovery...
If it has be set, then it has been 1ms from the end of the last packet.

3) Once a packet is received, reset the "Character Received" flag, and set the
timer to 8ms.

4) When the timer interrupt occurs, check the "Character Received" flag, if it
is set, then character(s) were received before the 8ms gap, do error recovery...
If the flag is still reset, then set the timer for 22ms.

Go to state 2...

Each state is triggered by an interrupt and no polling is required.

If you use fixed length packets, or a beginning/end of packet flag, or send the
packet length as part of the packet's header, an intelligent "receive character"
interrupt routine would be able to detect complete packets without having to
wait for the 1ms interrupt.

(If the 1ms is too long, use 0.5ms, but you get the picture...)

-Zonn
--------------------------------------------------------
Zonn Moore
Zektor, LLC
www.zektor.com

Remove the ".AOL" from the email address to reply.

Re: RS-485 addressing

Quoted text here. Click to load it

As a previous poster has intimated that such serial standard is the hardware
layer.

It is only a suggestion but why don't you implement a UDP scheme since the
header has all the information you require to sent a small packet from one
device to another?  It has source and destination addresses, no of bytes.  I
think only the header has a checksum but you can ignore this if you wish.
At least it is a recognised standard which anyone associated with networks
will know.  It also doesn't require any unusual features such as having an
extra data bit.  For instance, the Rabbit 2000 can't even cope properly with
8 bits data and parity.  Only a suggestion!



Re: RS-485 addressing

Quoted text here. Click to load it

As the others say or imply, you are pretty much on your own.

If you send me an email and convince me this isn't a homework assignment, I
can send you portions of a spec we have used.  It will work on any processor
with either RS-485 or RS-232 and does not require 9-bit capability.

Scott



Re: RS-485 addressing

Quoted text here. Click to load it

However you want it to.  RS-485 is a physical layer spec that states things
like volts and milliamps and ohms.

Quoted text here. Click to load it

No.  You can impliment any number of protocols, all of which use different
addressing methods.

Quoted text here. Click to load it

No.


Then you already know that RS-485 doesn't define any addressing.

Quoted text here. Click to load it

You can run CAN bus'es MAC layer on RS-485 if you want.

--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
We've slightly trimmed the long signature. Click to see the full one.
Re: RS-485 addressing
snipped-for-privacy@etherjones.us (EJ) wrote in message
Quoted text here. Click to load it

As others has pointed out, RS485 just defines physical interface.
Others have proposed some solutions based on some UART's capabilities
(that 9 bit scheme I mean). I used RS485 in a three pairs (one for
data, two for handshake) multi-drop poll select scheme and implemented
a fairly complex protocol on top of it. If I were to design it today,
I would use SDLC and an 82C30 (or some more modern similar). The real
solution will depend on how robust your system has to be.

Regards.

Elder.

Re: RS-485 addressing
snipped-for-privacy@yahoo.com (Mad@Spammers) wrote in message
Quoted text here. Click to load it

Thanks for all the responses.  It was just what I needed.

Your responses confirmed what I already thought to be the case,
but what I lacked was specific experience with RS-485,
and thought maybe I was missing something obvious.  Guess not.

I love the usenet community.

Re: RS-485 addressing
snipped-for-privacy@etherjones.us says...
Quoted text here. Click to load it

Have look at:

http://www.microtrol.com.au/hdlc.htm

Regards
Zoran


Site Timeline