Peter Peres wrote:
>Tony Nixon wrote:
>>I don't know how you can measure the start bit time if the 1st and or
>>subsequent data bits are the same state.
>
>You measure the time of the whole character (knowing the protocol and the
>character !) and discard it. The next chaacter will be received correctly.
>The data source should use pacing when sending initial training chars.
>Terminals pace after '\r' by default ....
>

Tony,

I pretty much agree with Dave Van Horn, and others, that the worst
case scenario that might just *barely* work is 10% error - meaning no
more than 5% error on each end - transmitter and receiver. Personally,
in situations like this, I try to apply a rule of thumb of allowing
*at least* a 2:1 safety margin over worst case - or 2.5% here.

You will notice from the PIC datasheets that using the built-in
UART, you get nominal errors to 3% or so with most xtals shown
[ignoring cases with > 5%]. The UARTs only give < 1% in certain
cases - not many.

On my ICTC - In-Circuit Test Chip (aka PIC Monitor chip)

http://www.sni.net/~oricom/ictc.htm

I use an autobaud boot routine that will allow the chip to operate
with a range of xtals, and also match the host baudrate:

    crystal             RS-232 Baudrates Available
   frequency
     (Mhz)        300  600   1200  2400  4800  9600  19200 38400
       5                       x     x     x     x
      10                             x     x     x     x
      20                                   x     x     x     x

       1            x    x     x
       2                 x     x     x
       4                       x     x     x
       8                             x     x     x
      16                                   x     x     x

       3.58                          x     x     *          (* = default)
       7.16                                x     x     *
      14.32                                      x     x     *

Similar to what Peter indicated, I have the host send several
CR [0Dh] characters, and I cycle the chip thru a series of SPBRG
divider values until it recognizes a valid CR. This is essentially
a 10-bit timing check, rather than just the start bit. It rarely
fails, except in some cases at 3.57 Mhz [don't know why ?????????]

I have also found that the chip will normally boot ok with many xtal
values that are within a couple % of those shown in the table, eg,
1.024, 4.09, 4.9152, 19.6 Mhz, etc, so this adds another 2% or so
to the errors given in the table.

best regards,
- Dan Michaels
Oricom Technolgies
==================

--
http://www.piclist.com hint: To leave the PICList
mailto:piclist-unsubscribe-request@mitvma.mit.edu