Searching \ for '16C63 Serial Port problem' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/ios.htm?key=serial
Search entire site for: '16C63 Serial Port problem'.

Truncated match.
PICList Thread
'16C63 Serial Port problem'
1998\05\12@122054 by Jennifer Wilson

picon face
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]

1998\05\12@140551 by Richard Nowak

picon face
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:
{Quote hidden}

1998\05\12@164418 by Joe Little

flavicon
face
    How about leaving the UART set for rx... and bitbanging the TX out
    another pin.


    -----------------
    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] >

1998\05\12@170540 by Richard Nowak

picon face
oops,

SPBRG=1

Rich

At 10:00 AM 5/12/98 -0700, you wrote:
<snipped>
>I use a clock oscillator at 14.7456 MHz, BRGH=0, SPBRG=0 producing a baud
>rate of 115200 bps.
>
>Rich

1998\05\12@173255 by Andy Kunz

flavicon
face
>  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?

You _should_ be able to:

       a) disable the USART completely
       b) initialize it at new baud rate
       c) start speaking (or listening)

You will probably have more problems on the PC side than on the PIC side,
from my experience.

I suggest you have two PC's for testing - one to talk at low speed, the
other to listen at high speed.

Either that, or choose a weird xtal so that you can run at BRGH=0.

If you go to the '66/67 chips, it isn't an issue any more.

Andy


==================================================================
Andy Kunz - Statistical Research, Inc. - Westfield, New Jersey USA
==================================================================

1998\05\13@004434 by tjaart

flavicon
face
>      >  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 :-)

Try to check for frame errors on both sides first.
After you've changed the baudrate, wait a while so the PC can re-sync on the first startbit. Same
applies to comms in the other direction.
Try sending a zero byte first.

--
Friendly Regards

Tjaart van der Walt
spam_OUTtjaartTakeThisOuTspamwasp.co.za

|--------------------------------------------------|
|                WASP International                |
|R&D Engineer : GSM peripheral services development|
|--------------------------------------------------|
|SMS .....0832123443KILLspamspam@spam@wasp.co.za  (160 chars max)|
|     http://www.wasp.co.za/~tjaart/index.html     |
|Voice: +27-(0)11-622-8686  Fax: +27-(0)11-622-8973|
|          WGS-84 : 26¡10.52'S 28¡06.19'E          |
|--------------------------------------------------|

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...