RS-485 addressing

No, you will respond right after the last byte of a correct packet has been received, on the interrupt it (the last byte) generates. The wait will be only if the packet is incomplete for some reason, and then you can safely discard it (the partial packet) on the first rec'd byte after the gap.

Reply to
Elko Tchernev
Loading thread data ...

I've obviously used this approach, on a UART that had no FIFO (8251A). There was no other way to service that. True, the BAUD rate was much lower ;)

The OP didn't mention what CPU he'll be using, or what RTOS, if any. _I_ could design a system to service that, YMMV.

That depends on who is doing the assuming ;)

Not the only, but it sounds like a nice and easy way out.

Reply to
Elko Tchernev

IIRC, the MC68302 can get the bytes silently into internal ram and give you an interrupt after something like 3 bit idle. If you are using UART mode, of course. No need to track single chars.

Andreas

--
Good judgment comes from experience.  Unfortunately, the experience
usually comes from bad judgment.
Reply to
Andreas Hadler

Given a fast enough processor, it can be done IMO. When you program a hardware timer to interrupt on overflow, you can relod load the timer each time a character is received. When the timer expires, your gap has arrived.

Meindert

Reply to
Meindert Sprang

That sounds a useful trick if you want to try to make a product that can connect to a broad range of industrial busses, with a single "universal" serial port. RS232/485/CAN.

--

John Devereux
Reply to
John Devereux

NB: I've never thried the above setup -- it's just something I've read about. And I don't remember that anybody claimed the RS-485 dominant/recessive scheme would inter-operate with a real CAN transceiver.

--
Grant Edwards                   grante             Yow!  Where's th' DAFFY
                                  at               DUCK EXHIBIT??
 Click to see the full signature
Reply to
Grant Edwards

OK. I just wanted to make sure I wasn't missing something really obvious before I made a fool of myself and questioned the approach being proposed.

Thanks for the detail. I'm not a EE, but I think I get the gist of what you're saying, and now it makes more sense to me. I didn't understand before how 485 could be used for this. Is there a FAQ or a technical article that you are aware of that goes into greater detail? For example, I'd like to understand how the bits are monitored for arbitration in this scheme.

Thanks.

Reply to
RT

The problem is, I don't know if it's the last byte until I detect a time gap after it. Maybe I'm not understanding what you are saying.

Reply to
RT

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?

Reply to
RT

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

Reply to
Jim McGinnis

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.
Reply to
Elko Tchernev

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

formatting link

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

Reply to
Zonn

... snip ...

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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

The IX1 chip from M2C in Hamburg may still be available. It is a fieldbus controller which can emulate (in software) any serial protocol at up to 1 Mbps. Most implementation I have seen had 8-pin sockets for the physical layer interface.

Stephen

-- Stephen Pelc, snipped-for-privacy@INVALID.mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time

133 Hill Lane, Southampton SO15 5AF, England tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691 web:
formatting link
- free VFX Forth downloads
Reply to
Stephen Pelc

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

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.

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.

Reply to
EJ

--- clip clip ---

I already answered once. Please get the RFC 1662 () 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

Reply to
Tauno Voipio

... snip ...

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 (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
 Click to see the full signature
Reply to
CBFalconer

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.