RS232 using MCC18

I have an application that needs to receive messages via RS232 of
variable length and without any control characters or EOF/EOT markers.
The problem I encounter is that if the application is in a tight loop
checking for more characters, it executes fast enough so that the next
character has not yet arrived, so it exits. So I thought the only way
to be sure that the end of the message has not been received is to
delay for about half the baud rate and check again. But this seems
rather fragile, as I'm not sure how stable it will be at different
baud rates. But I do NOT have the option of imposing fixed-length
messages or specifying that the messages have some kind of start and
stop sequence. Any ideas?

Cheers,
Josh Fitzgerald
SP Controls, Inc.
San Francisco, CA

>The problem I encounter is that if the application is in a tight loop
>checking for more characters, it executes fast enough so that the next
>character has not yet arrived, so it exits. So I thought the only way
>to be sure that the end of the message has not been received is to
>delay for about half the baud rate and check again. But this seems
>rather fragile, as I'm not sure how stable it will be at different
>baud rates. But I do NOT have the option of imposing fixed-length
>messages or specifying that the messages have some kind of start and
>stop sequence. Any ideas?

Why not have your loop check a timeout flag. It exits when the flag gets set.
Use a timer to set the flag. If you get a character, you reset the timer. You
can vary the timer value for whatever baud rate you are using.

Josh wrote:
> 
> I have an application that needs to receive messages via RS232 of
> variable length and without any control characters or EOF/EOT markers.
> The problem I encounter is that if the application is in a tight loop
> checking for more characters, it executes fast enough so that the next
> character has not yet arrived, so it exits. So I thought the only way
> to be sure that the end of the message has not been received is to
> delay for about half the baud rate and check again. But this seems
> rather fragile, as I'm not sure how stable it will be at different
> baud rates. But I do NOT have the option of imposing fixed-length
> messages or specifying that the messages have some kind of start and
> stop sequence. Any ideas?

   while (DATAREADYBIT & uartstatus()) {
      inputandprocesschar();
      count = DELAYTIME;
      do {
         --count;
      } while (count && !(DATAREADYBIT & uartstatus()));
   }

-- 
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
   <http://cbfalconer.home.att.net>  USE worldnet address!

On 10 Mar 2004 10:16:25 -0800, josh@spcontrols.com (Josh) wrote:

>I have an application that needs to receive messages via RS232 of
>variable length and without any control characters or EOF/EOT markers.

Like Modbus ?

>The problem I encounter is that if the application is in a tight loop
>checking for more characters, it executes fast enough so that the next
>character has not yet arrived, so it exits. So I thought the only way
>to be sure that the end of the message has not been received is to
>delay for about half the baud rate and check again. 

This is one way of doing it.

>But this seems
>rather fragile, as I'm not sure how stable it will be at different
>baud rates. 

If you can check at least twice during a single bit time at the
highest bit rate you should be OK, since at lower speeds you simply
use the n'th sample to determine if a new character has been started.

The worst practical problem is that the _transmitter_ must be able to
deliver each character without any inter-character delays.

With half duplex point to point systems this is not really an issue,
since even if the checking time (for idle state) has been delayed for
any reason, you still get the correct result, although the throughput
will suffer.

Paul
  

Josh <josh@spcontrols.com> wrote:
> I have an application that needs to receive messages via RS232 of
> variable length and without any control characters or EOF/EOT markers.

IMHO, you have a pretty silly system surrounding your application,
then.  Not providing any other sign of end-of-message except "no
further characters are sent for (some time)" is total confusion
waiting to hit you.  That technique is known to fail even in
face-to-face communication among human beings, occasionally --- how
can anybody possibly expect it to work using a no-feedback serial
line?  

A: "I'm _fed_up_ with your always having to have the last word, dammit!"
B: "Yeah, right --- and how am *I* supposed to guess *you* don't have 
    anything more to say, heh?"
A: ...stares at the skies in silent disbelief...

> The problem I encounter is that if the application is in a tight loop
> checking for more characters, it executes fast enough so that the next
> character has not yet arrived, so it exits. 

Well, as the proverbial doctor would put it: don't do that, then!
Don't exit before you've waited at least long enough for that next
byte to have come in, if it is coming.  Yes, this will mean you need a
time-calibrated delay of some kind.  Prime a timer and trigger it ---
that's what you have timers for.

If, OTOH, that "(some time)" mentioned before is not at least about
one or two byte transmission times long (... bit times, if you're
bit-banging RS232), you're completely toast anyway---it might then be
best to put that project back wherever you found it and _run_.

-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

On 11 Mar 2004 00:41:55 GMT, Hans-Bernhard Broeker
<broeker@physik.rwth-aachen.de> wrote:

>Josh <josh@spcontrols.com> wrote:
>> I have an application that needs to receive messages via RS232 of
>> variable length and without any control characters or EOF/EOT markers.
>
>IMHO, you have a pretty silly system surrounding your application,
>then.  Not providing any other sign of end-of-message except "no
>further characters are sent for (some time)" is total confusion
>waiting to hit you. 

This is a pretty normal situation in ethernet/serial line converters.
The converter does not know anything about the protocol running on the
serial line, but still it must send the ethernet frame containing the
last few bytes when the serial side traffic has stopped. 

Using too long timeout will cause a large latency for serial line
protocols, while using a too short timeout will cause a lot of small,
inefficient frames being sent, if there is some gaps between the bytes
on the serial line (e.g. due to transmitter side overload).

Paul
  

On 2004-03-11, Paul Keinanen <keinanen@sci.fi> wrote:

>>> I have an application that needs to receive messages via RS232
>>> of variable length and without any control characters or
>>> EOF/EOT markers.
>>
>>IMHO, you have a pretty silly system surrounding your
>>application, then.  Not providing any other sign of
>>end-of-message except "no further characters are sent for (some
>>time)" is total confusion waiting to hit you. 

Life's like that.

> This is a pretty normal situation in ethernet/serial line
> converters. The converter does not know anything about the
> protocol running on the serial line, but still it must send
> the ethernet frame containing the last few bytes when the
> serial side traffic has stopped.

It's also pretty common in some widely used industrial
protocols.  Modbus RTU mode, for example, uses a 3+ byte time
gap to delimit frames.  Other industrial protocols that I know
of (e.g. HART) also require you to send a frames as a
continuous stream of data and reject frames with gaps in them.

-- 
Grant Edwards                   grante             Yow!  Not SENSUOUS... only
                                  at               "FROLICSOME"... and in
                               visi.com            need of DENTAL WORK... in
                                                   PAIN!!!