Alan B. Pearce <A.B.Pearce@RL.AC.UK> wrote:
>I am aware that many moons ago there were hardware uart chips that did
>sample on absolutely every baud rate clock pulse, but what do you really do
>with all this data? Any sort of majority logic is just as likely to make a
>wrong decision as a right decision if there is that much noise.

Michael Rigby-Jones <Michael.Rigby-Jones@BOOKHAM.COM> wrote:
>All hardware UARTs that I am aware of sample multiple times through the bit
>with a majority decision.  The line wouldn't have to be particularly noisy
>for a single point sample strategy to fail, just one glitch in the wrong
>place would produce an error.  Of course, you have to weigh up what the
>application is, there must be thousands of simple bit bashed UARTS working
>happily all over the world.

Thanks for continuing to bite on this.  I'm finding it an interesting
debate as I have seen several sides of this coin over the years.

Out of interest, I dug out my PIC16C84 based project which used a timer
interrupt at 8x the baud rate to drive a software UART to remind myself
why I designed it the way I did.

There were several factors:

1.  The INT pin was needed for another purpose (as were RB4-RB7).
2.  The PIC16C84 only has one timer/counter.
3.  The serial interface had to operate full-duplex.

Without an interrupt-on-change for the serial input, I polled this line in
a timer interrupt routine at 8x the baud rate to check for the edge of a
start bit.  I chose an 8x rate so that sampling of subsequent data bits
would be within +/- 6% of the nominal centre of the bit time.

I chose to keep the timer interrupt running continuously at 8x the baud
rate at all times because I needed it as a time base for other purposes.
For full-duplex transmission and reception of serial data, I put a little
state machine in the interrupt handler which kept track of the relative
phase of receive and transmit bits, and shifted them in and out during the
appropriate one of the eight possible time-slices.

Fortunately, this application only needed a 1200 baud serial line rate,
which was well within the processing capabilities of a 4MHz PIC16C84.
That was 9 years ago, and most of the same code is alive and well in
products using a PIC16F628 today.  Of course, the F628 has an in-built
hardware UART, but I chose to ignore this because I didn't want to change
the PCB layout to move the serial lines to the "correct" port pins.

I guess the point that I'm trying to make is that serial bit-banging is
good in some applications and not-so-good in others, depending on the
environment and the resources available.  I'd suggest that:

1.  Foreground serial "bit-banging" (with timing loops) is fine for
applications which operate half-duplex and don't mind waiting around for
incoming data to arrive.

2.  Background serial "bit-banging" (using interrupts) is especially good
if you are operating half-duplex and can spare a hardware interrupt and a
timer for the purpose (timer interrupt at 1x baud rate).  For full-duplex
operation, a second timer *or* a higher timer interrupt rate is usually
needed because the phase of the incoming data bits can be arbitrary with
respect to the outgoing data bits (*).

(*) I have also written a full-duplex software UART which gets by with a
single timer by manipulating the timer to anticipate transmit and receive
"events" with an arbitrary phase difference, but I would say this isn't
for the faint-hearted!

3.  A hardware UART is probably the best solution in other circumstances.

I'd also suggest that over-sampling of data bits is useful in environments
where occasional noise "spikes" can occur, but is much less useful in the
presence of lower-frequency noise since, by definition, the samples have
to be taken close together.  I would not wish to rely on over-sampling to
get me out of trouble on a noisy link - I'd look instead at signal levels,
noise margins and perhaps the use of a more robust coding scheme.

I think it is also important to consider the possible characteristics of
the other end of the link.  When I need to interface to a "black box", I
prefer to use a hardware UART with crystal-controlled timing, because I
don't know what liberties the designers of the black box may have taken
with their serial interface.  On the other hand, I'm happy to use less
tight approaches with equipment that I understand.

All of the above is IMHO, of course.

Any more thoughts?  Have I missed some good tricks?
--
Ian Chapman
Chapmip Technology, UK

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listserv@mitvma.mit.edu with SET PICList DIGEST in the body