I'm using a '65 which talks to a PC. The baud rate is determined by the
user in the hardware, and any change is detected by the PC software and is
reset to match that of the hardware. I use the technique provided in the
app notes and it does work.

I never tried doing what you're trying to do but I think it'll be
difficult.  Both Tx and Rx baud rates are determined by the same clocking
arrangement and I don't see how the baud rate can be changed on the fly
with asynch communication. When switching from a higher speed to a lower
one you will get  frame errors which will add to your overhead.  When doing
the switch you need to add delays to ensure enough time for both sides to
get in sync with each other. This will make the protocol more difficult as
well - how would either side know when to switch?

I use a clock oscillator at 14.7456 MHz, BRGH=0, SPBRG=0 producing a baud
rate of 115200 bps.

Rich



At 11:47 AM 5/12/98 -0400, you wrote:
>Hello everyone,
>
>  We've run into an interesting problem while trying to optimize an
>interface using the 16C63 serial port.
>
>  The application involves sending just a few bytes to the PIC and then
>returning a much larger number from the micro.
>
>  So, we hit on the (seemingly) clever idea of running the forward
>communication at 19K Baud thus avoiding the known BRGH=1 receive
>anomalies and the reverse at 115K maximizing our transfer rate.
>
>  The problem is that it doesn't work!  ...using the suggest coding from
>the data book.
>  Does anyone have any experience with changing the serial port baud rate
>"on the fly"?   Is there some mystic sequence necessary to "reset" or
>"re-initialize" the port beyond what is disclosed in the data book?
>
>Thanks in advance for any suggestions,
>   Jen :-)
>
>_____________________________________________________________________
>You don't need to buy Internet access to use free Internet e-mail.
>Get completely free e-mail from Juno at http://www.juno.com
>Or call Juno at (800) 654-JUNO [654-5866]
>