On Thu, 18 Apr 2002 09:54:25 +1000, Tony Nixon wrote:


>The trouble with software UARTs (bit banged I assume) is that you always
>have to be ready to receive a byte 'before' it gets there. If you are
>too late then you miss it, or half of it and thus mess up the rest of
>your data stream.
>

The flip side of the 'too late' problem is the 'too early' problem. If
you get back to the software uart while you're still in the last half
of the last bit, the code can mis-interpret a low as the start bit. To
ensure that this hasn't happened, you need to first check for a high
and then wait for the high-to-low transition. (Most examples of
software uarts that I've seen don't do this.)


>You may not afford to have interrupts enabled, because while that is
>executing, the receive code may be denied the chance to recognise a
>valid start bit. Same with WDT timeouts.
>

Too true.


>If you are expecting to receive more than one byte, buffer the incoming
>data stream then act on it after receiving it all.
>

While I agree on this point as a good general practice, don't forget
that you do have at least 1 and 1/2 bit times (last half of the last
bit plus the stop bit) available before the next start bit can
possibly occur.


>Of course, if you have an interrupt enabled (RB0INT for example) to
>catch the start bit, then that may make things easier.
>

Amen.

>Perhaps backtrack a little and only test that your RX routine is
>actually grabbing the bytes - echo them back maybe.
>

Just be sure to buffer the characters until you get a a specific
character (carriage-return or line-feed perhaps)  and then echo the
whole string. If you're not echoing them with the hardware uart, you
won't be able to echo each character as it is received.


Regards, Bob

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads