12F675 | 16F628 | 16F84 | 16f877 | 16F877A | 16F88 | 18F458 | ADC | AVR | Bootloader | CAN | CCS | CRC | EAGLE | EEPROM | ICD | ICSP | IDE | JDM | LED | Macros | Microchip | MPLAB | PCB-CAD | PIC10F | Pic12f675 | PIC16F84 | PIC16F84A | PIC16F877 | PIC18 | PIC18F452 | PicBasic | PICC | PICSTART | PWM | RS-485 | RS232 | SMT | SPI | UART | USART | USB | Wireless | Wisp628 | Xilinx

Hi all,

I've tried the Microchip forums and have an open support ticket but
in two days I've heard nothing on this.

I've got an interesting problem. I am running a 18F6680 at 40MHz. If
I have the BRG set for 9600 baud and I will often get data that has
bit 7 set when it shouldn't. The Tx data going out is fine, no odd
bits set, but the Rx data has this issue if I am sending data faster
than just typing it in by hand. IOW, if I send data out with a
script, just as fast as the data can be sent, I get these errors, but
just typing in by hand is fine. Since this is an automated process,
this just won't fly.

However, if I have set up for 115200 then there are no problems. I've
not checked every possible BRG setting to see which ones goof up and
which do not. I am using the formula given in the data sheet and have
checked to make sure that my divisors are correct, they are, or, at
least they match the example numbers given in the data sheet.

Has anyone else seen this kind of oddness with the 18F USART? Has
anyone found out what causes it? I use an ISR to pull in my Rx data
and "regular" code to send data out. I am not losing data, I'm having
bit 7 of the data byte being set. This means that if I SHOULD be
getting 0x0D I will instead sometimes get 0x8D, etc.

This seems to point that the USART is sampling the stop bit instead of
the last bit cell. I've confirmed that this is the case by using two
stop bits instead of one. BUT, this is not a solution, I'm talking to
a third party device where I do not have this luxury to change the rules.

Does anyone have any suggestions?

thanks,
DLC



to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

How's your processor clock? If you look at data transmitted by the pic
usart on a scope, does the bit timing look right? I've reliably sent data
at 9600bps using an 18F at 40MHz (using a 10MHz resonator and the PLL
clock multiplier).

Good luck!

Harold

> Hi all,
>
> I've tried the Microchip forums and have an open support ticket but
> in two days I've heard nothing on this.
>
> I've got an interesting problem. I am running a 18F6680 at 40MHz. If
> I have the BRG set for 9600 baud and I will often get data that has
> bit 7 set when it shouldn't. The Tx data going out is fine, no odd
> bits set, but the Rx data has this issue if I am sending data faster
> than just typing it in by hand. IOW, if I send data out with a
> script, just as fast as the data can be sent, I get these errors, but
> just typing in by hand is fine. Since this is an automated process,
> this just won't fly.
>
> However, if I have set up for 115200 then there are no problems. I've
> not checked every possible BRG setting to see which ones goof up and
> which do not. I am using the formula given in the data sheet and have
> checked to make sure that my divisors are correct, they are, or, at
> least they match the example numbers given in the data sheet.
>
> Has anyone else seen this kind of oddness with the 18F USART? Has
> anyone found out what causes it? I use an ISR to pull in my Rx data
> and "regular" code to send data out. I am not losing data, I'm having
> bit 7 of the data byte being set. This means that if I SHOULD be
> getting 0x0D I will instead sometimes get 0x8D, etc.
>
> This seems to point that the USART is sampling the stop bit instead of
> the last bit cell. I've confirmed that this is the case by using two
> stop bits instead of one. BUT, this is not a solution, I'm talking to
> a third party device where I do not have this luxury to change the rules.
>
> Does anyone have any suggestions?
>
> thanks,
> DLC
--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!


to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

I'm running a 40Mhz clock (10MHz xtal). There is plenty of speed and
divisor since I'm using the 16 bit BRG. The transmit is fine, no
garbling at all, just the receive data has bit 7 set on a random
selection of the incoming data.

DLC

Harold Hallikainen wrote:
> How's your processor clock? If you look at data transmitted by the pic
> usart on a scope, does the bit timing look right? I've reliably sent data
> at 9600bps using an 18F at 40MHz (using a 10MHz resonator and the PLL
> clock multiplier).
>
> Good luck!
>
> Harold
>>Hi all,
>>
>> I've tried the Microchip forums and have an open support ticket but
>>in two days I've heard nothing on this.
>>
>>I've got an interesting problem. I am running a 18F6680 at 40MHz. If
>>I have the BRG set for 9600 baud and I will often get data that has
>>bit 7 set when it shouldn't. The Tx data going out is fine, no odd
>>bits set, but the Rx data has this issue if I am sending data faster
>>than just typing it in by hand. IOW, if I send data out with a
>>script, just as fast as the data can be sent, I get these errors, but
>>just typing in by hand is fine. Since this is an automated process,
>>this just won't fly.
>>
>>However, if I have set up for 115200 then there are no problems. I've
>>not checked every possible BRG setting to see which ones goof up and
>>which do not. I am using the formula given in the data sheet and have
>>checked to make sure that my divisors are correct, they are, or, at
>>least they match the example numbers given in the data sheet.
>>
>>Has anyone else seen this kind of oddness with the 18F USART? Has
>>anyone found out what causes it? I use an ISR to pull in my Rx data
>>and "regular" code to send data out. I am not losing data, I'm having
>>bit 7 of the data byte being set. This means that if I SHOULD be
>>getting 0x0D I will instead sometimes get 0x8D, etc.
>>
>>This seems to point that the USART is sampling the stop bit instead of
>>the last bit cell. I've confirmed that this is the case by using two
>>stop bits instead of one. BUT, this is not a solution, I'm talking to
>>a third party device where I do not have this luxury to change the rules.
>>
>>Does anyone have any suggestions?
>>
>>thanks,
>>DLC
>>
>
--
-------------------------------------------------
Dennis Clark TTT Enterprises
www.techtoystoday.com
-------------------------------------------------


to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

You might try a baud rate crystal. Even divisor for no error.
11.0592 MHz or 22.1184 MHz

11.0592 MHz x4 is a bit above spec but if room temperature may be
ok.

Norm
--- In p...@yahoogroups.com, dlc wrote:
>
> I'm running a 40Mhz clock (10MHz xtal). There is plenty of speed
and
> divisor since I'm using the 16 bit BRG. The transmit is fine, no
> garbling at all, just the receive data has bit 7 set on a random
> selection of the incoming data.
>
> DLC
>
> Harold Hallikainen wrote:
> > How's your processor clock? If you look at data transmitted by
the pic
> > usart on a scope, does the bit timing look right? I've reliably
sent data
> > at 9600bps using an 18F at 40MHz (using a 10MHz resonator and
the PLL
> > clock multiplier).
> >
> > Good luck!
> >
> > Harold
> >
> >
> >>Hi all,
> >>
> >> I've tried the Microchip forums and have an open support
ticket but
> >>in two days I've heard nothing on this.
> >>
> >>I've got an interesting problem. I am running a 18F6680 at
40MHz. If
> >>I have the BRG set for 9600 baud and I will often get data that
has
> >>bit 7 set when it shouldn't. The Tx data going out is fine, no
odd
> >>bits set, but the Rx data has this issue if I am sending data
faster
> >>than just typing it in by hand. IOW, if I send data out with a
> >>script, just as fast as the data can be sent, I get these
errors, but
> >>just typing in by hand is fine. Since this is an automated
process,
> >>this just won't fly.
> >>
> >>However, if I have set up for 115200 then there are no
problems. I've
> >>not checked every possible BRG setting to see which ones goof up
and
> >>which do not. I am using the formula given in the data sheet
and have
> >>checked to make sure that my divisors are correct, they are, or,
at
> >>least they match the example numbers given in the data sheet.
> >>
> >>Has anyone else seen this kind of oddness with the 18F USART?
Has
> >>anyone found out what causes it? I use an ISR to pull in my Rx
data
> >>and "regular" code to send data out. I am not losing data, I'm
having
> >>bit 7 of the data byte being set. This means that if I SHOULD be
> >>getting 0x0D I will instead sometimes get 0x8D, etc.
> >>
> >>This seems to point that the USART is sampling the stop bit
instead of
> >>the last bit cell. I've confirmed that this is the case by
using two
> >>stop bits instead of one. BUT, this is not a solution, I'm
talking to
> >>a third party device where I do not have this luxury to change
the rules.
> >>
> >>Does anyone have any suggestions?
> >>
> >>thanks,
> >>DLC
> >>
> >>
> >>
> >>
> >
> >
> > --
> -------------------------------------------------
> Dennis Clark TTT Enterprises
> www.techtoystoday.com
> -------------------------------------------------
>



to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

The clock is not negotiable, the device is part of a series of devices
with a common code source and uses the CAN bus, so I can't diddle with
that part. I think that 0.03% error is pretty darn close, so I'm not
concerned with that. I've used bit banging successfully with 10X higher
error. I'm thinking that there is something odd in the USART timing
that is causing the sample times to get messed up. Anyone else got that
idea? I've seen many posts on the Microchip forums also complaining
about problems with the USART timing, but this is my first experience
with a really bad one. The 115200 bps rate works just fine with no
problems, also, if I make the data with 2 stop bits there is no problem.
This tends to make me think that it is an internal timing issue.

DLC

normnet2003 wrote:
> You might try a baud rate crystal. Even divisor for no error.
> 11.0592 MHz or 22.1184 MHz
>
> 11.0592 MHz x4 is a bit above spec but if room temperature may be
> ok.
>
> Norm
> --- In p...@yahoogroups.com, dlc wrote:
>
>>I'm running a 40Mhz clock (10MHz xtal). There is plenty of speed
>
> and
>
>>divisor since I'm using the 16 bit BRG. The transmit is fine, no
>>garbling at all, just the receive data has bit 7 set on a random
>>selection of the incoming data.
>>
>>DLC
>>
>>Harold Hallikainen wrote:
>>
>>>How's your processor clock? If you look at data transmitted by
>
> the pic
>
>>>usart on a scope, does the bit timing look right? I've reliably
>
> sent data
>
>>>at 9600bps using an 18F at 40MHz (using a 10MHz resonator and
>
> the PLL
>
>>>clock multiplier).
>>>
>>>Good luck!
>>>
>>>Harold
>>>
>>>
>>>
>>>>Hi all,
>>>>
>>>> I've tried the Microchip forums and have an open support
>
> ticket but
>
>>>>in two days I've heard nothing on this.
>>>>
>>>>I've got an interesting problem. I am running a 18F6680 at
>
> 40MHz. If
>
>>>>I have the BRG set for 9600 baud and I will often get data that
>
> has
>
>>>>bit 7 set when it shouldn't. The Tx data going out is fine, no
>
> odd
>
>>>>bits set, but the Rx data has this issue if I am sending data
>
> faster
>
>>>>than just typing it in by hand. IOW, if I send data out with a
>>>>script, just as fast as the data can be sent, I get these
>
> errors, but
>
>>>>just typing in by hand is fine. Since this is an automated
>
> process,
>
>>>>this just won't fly.
>>>>
>>>>However, if I have set up for 115200 then there are no
>
> problems. I've
>
>>>>not checked every possible BRG setting to see which ones goof up
>
> and
>
>>>>which do not. I am using the formula given in the data sheet
>
> and have
>
>>>>checked to make sure that my divisors are correct, they are, or,
>
> at
>
>>>>least they match the example numbers given in the data sheet.
>>>>
>>>>Has anyone else seen this kind of oddness with the 18F USART?
>
> Has
>
>>>>anyone found out what causes it? I use an ISR to pull in my Rx
>
> data
>
>>>>and "regular" code to send data out. I am not losing data, I'm
>
> having
>
>>>>bit 7 of the data byte being set. This means that if I SHOULD be
>>>>getting 0x0D I will instead sometimes get 0x8D, etc.
>>>>
>>>>This seems to point that the USART is sampling the stop bit
>
> instead of
>
>>>>the last bit cell. I've confirmed that this is the case by
>
> using two
>
>>>>stop bits instead of one. BUT, this is not a solution, I'm
>
> talking to
>
>>>>a third party device where I do not have this luxury to change
>
> the rules.
>
>>>>Does anyone have any suggestions?
>>>>
>>>>thanks,
>>>>DLC
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>--
>>-------------------------------------------------
>>Dennis Clark TTT Enterprises
>>www.techtoystoday.com
>>-------------------------------------------------
>> to unsubscribe, go to http://www.yahoogroups.com and follow the instructions
>



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Dennis,
I've used the -442 at 9600 and have had no problems.
Maybe its not the PIC but the transmitter that causing the problem ?
Dennis Clark wrote:

> Hi all,
>
> I've tried the Microchip forums and have an open support ticket but
> in two days I've heard nothing on this.
>
> I've got an interesting problem. I am running a 18F6680 at 40MHz. If
> I have the BRG set for 9600 baud and I will often get data that has
> bit 7 set when it shouldn't. The Tx data going out is fine, no odd
> bits set, but the Rx data has this issue if I am sending data faster
> than just typing it in by hand. IOW, if I send data out with a
> script, just as fast as the data can be sent, I get these errors, but
> just typing in by hand is fine. Since this is an automated process,
> this just won't fly.
>
> However, if I have set up for 115200 then there are no problems. I've
> not checked every possible BRG setting to see which ones goof up and
> which do not. I am using the formula given in the data sheet and have
> checked to make sure that my divisors are correct, they are, or, at
> least they match the example numbers given in the data sheet.
>
> Has anyone else seen this kind of oddness with the 18F USART? Has
> anyone found out what causes it? I use an ISR to pull in my Rx data
> and "regular" code to send data out. I am not losing data, I'm having
> bit 7 of the data byte being set. This means that if I SHOULD be
> getting 0x0D I will instead sometimes get 0x8D, etc.
>
> This seems to point that the USART is sampling the stop bit instead of
>
> the last bit cell. I've confirmed that this is the case by using two
> stop bits instead of one. BUT, this is not a solution, I'm talking to
> a third party device where I do not have this luxury to change the
> rules.
>
> Does anyone have any suggestions?
>
> thanks,
> DLC
>
--
*******************************************
VISIT MY HOME PAGE:

LAST UPDATED: 23/08/2003
*******************************************
Regards
Eirik Karlsen


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Hi Dlc,

Any chance you're disabling the receive or swapping a half duplex line
around? This could crunch the last bit.

10Mhz Xtal should be fine.

Alan KM6VV

> -----Original Message-----
> From: p...@yahoogroups.com [mailto:p...@yahoogroups.com] On Behalf
> Of dlc
> Sent: Thursday, July 20, 2006 9:15 PM
> To: p...@yahoogroups.com
> Subject: Re: [piclist] Re: 18F6680 at 9600 USART garbles read data
>
> The clock is not negotiable, the device is part of a series of devices
> with a common code source and uses the CAN bus, so I can't diddle with
> that part. I think that 0.03% error is pretty darn close, so I'm not
> concerned with that. I've used bit banging successfully with 10X higher
> error. I'm thinking that there is something odd in the USART timing
> that is causing the sample times to get messed up. Anyone else got that
> idea? I've seen many posts on the Microchip forums also complaining
> about problems with the USART timing, but this is my first experience
> with a really bad one. The 115200 bps rate works just fine with no
> problems, also, if I make the data with 2 stop bits there is no problem.
> This tends to make me think that it is an internal timing issue.
>
> DLC



to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Same here. And the 552 and the 252 and the ... But here things just
aren't working. I'm having problems with two different transmitters - A
Teraterm or Realterm on my laptop and an ESI drapery controller. If I
run the data rate up to 115200, the max I can do, then it works fine, if
I make it two stop bits at 9600 it works fine. But 8n1 at 9600 does NOT
work fine. I have a 356 byte circular buffer on an ISR that pulls in
the data, that ISR also handles timing pulses every 8.33ms and the whole
worst case time in the ISR is 7.5us, more common is in the 4us range. If
the digits come in slowly, like hand typing, it tends to be fine, but
when the data is streaming, I get the first few characters up until a
CR, after that, random junk appears.

I just don't get it - It MUST be some other code interaction, but for
the life of me I don't understand what.

DLC
Eirik Karlsen wrote:
> Dennis,
> I've used the -442 at 9600 and have had no problems.
> Maybe its not the PIC but the transmitter that causing the problem ?
>
>
> Dennis Clark wrote:
>
>> Hi all,
>>
>> I've tried the Microchip forums and have an open support ticket but
>> in two days I've heard nothing on this.
>>
>> I've got an interesting problem. I am running a 18F6680 at 40MHz. If
>> I have the BRG set for 9600 baud and I will often get data that has
>> bit 7 set when it shouldn't. The Tx data going out is fine, no odd
>> bits set, but the Rx data has this issue if I am sending data faster
>> than just typing it in by hand. IOW, if I send data out with a
>> script, just as fast as the data can be sent, I get these errors, but
>> just typing in by hand is fine. Since this is an automated process,
>> this just won't fly.
>>
>> However, if I have set up for 115200 then there are no problems. I've
>> not checked every possible BRG setting to see which ones goof up and
>> which do not. I am using the formula given in the data sheet and have
>> checked to make sure that my divisors are correct, they are, or, at
>> least they match the example numbers given in the data sheet.
>>
>> Has anyone else seen this kind of oddness with the 18F USART? Has
>> anyone found out what causes it? I use an ISR to pull in my Rx data
>> and "regular" code to send data out. I am not losing data, I'm having
>> bit 7 of the data byte being set. This means that if I SHOULD be
>> getting 0x0D I will instead sometimes get 0x8D, etc.
>>
>> This seems to point that the USART is sampling the stop bit instead of
>> the last bit cell. I've confirmed that this is the case by using two
>> stop bits instead of one. BUT, this is not a solution, I'm talking to
>> a third party device where I do not have this luxury to change the rules.
>>
>> Does anyone have any suggestions?
>>
>> thanks,
>> DLC
>>
> --
> *******************************************
> VISIT MY HOME PAGE:
>
> LAST UPDATED: 23/08/2003
> *******************************************
> Regards
> Eirik Karlsen
>

--
---------------------------------------
Dennis Clark TTT Enterprises
---------------------------------------


to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Hmm,

Not unless the hardware is doing it itself. The USART is configured
and not touched again. I'd read someone state that the baud rate clock
is reset when a new byte is transmitted, but I have not confirmed that
in any document that I have - If this is so then the unit is not truly
duplex since I can't guarantee no incoming data before transmitting - So
far this has not seemed to be part of my problem.

DLC

Alan Marconett wrote:
> Hi Dlc,
>
> Any chance you're disabling the receive or swapping a half duplex line
> around? This could crunch the last bit.
>
> 10Mhz Xtal should be fine.
>
> Alan KM6VV
>>-----Original Message-----
>>From: p...@yahoogroups.com [mailto:p...@yahoogroups.com] On Behalf
>>Of dlc
>>Sent: Thursday, July 20, 2006 9:15 PM
>>To: p...@yahoogroups.com
>>Subject: Re: [piclist] Re: 18F6680 at 9600 USART garbles read data
>>
>>The clock is not negotiable, the device is part of a series of devices
>>with a common code source and uses the CAN bus, so I can't diddle with
>>that part. I think that 0.03% error is pretty darn close, so I'm not
>>concerned with that. I've used bit banging successfully with 10X higher
>>error. I'm thinking that there is something odd in the USART timing
>>that is causing the sample times to get messed up. Anyone else got that
>>idea? I've seen many posts on the Microchip forums also complaining
>>about problems with the USART timing, but this is my first experience
>>with a really bad one. The 115200 bps rate works just fine with no
>>problems, also, if I make the data with 2 stop bits there is no problem.
>> This tends to make me think that it is an internal timing issue.
>>
>>DLC
>
> to unsubscribe, go to http://www.yahoogroups.com and follow the instructions
>



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

I got it to work folks, however...

I've found that the USART mode that uses the 16 bit divisor does not
work well for lower baud rates. How low? I don't know, I've got to
quantify it.

If I use either of these two configurations:
BRG16=0, BRGH=0, SPBRG=64 (error = 0.16%)
BRG16=0, BRGH=1, SPBRG=255 (error = 1.73%)
Everything at 9600 bps works fine. Where is the breakover point? Now
my code isn't so clean because I've got to decide how to set the bits
and divide the values depending upon the rate instead of using the
ever-so-nice 16 bit divisor method which covered all my bases. This
wouldn't be so bad but I have about 16 bytes of FLASH left to do this
fix with.

I think this pretty clearly points to a hardware problem in the PIC
USART.

have fun all,
DLC



to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

You ARE aware that if you get above +/-5% error there is a very
high risk of getting bit error, which is most likely to happend at the
last bit...?
Dennis Clark wrote:

> I got it to work folks, however...
>
> I've found that the USART mode that uses the 16 bit divisor does not
> work well for lower baud rates. How low? I don't know, I've got to
> quantify it.
>
> If I use either of these two configurations:
> BRG16=0, BRGH=0, SPBRG=64 (error = 0.16%)
> BRG16=0, BRGH=1, SPBRG=255 (error = 1.73%)
> Everything at 9600 bps works fine. Where is the breakover point? Now
> my code isn't so clean because I've got to decide how to set the bits
> and divide the values depending upon the rate instead of using the
> ever-so-nice 16 bit divisor method which covered all my bases. This
> wouldn't be so bad but I have about 16 bytes of FLASH left to do this
> fix with.
>
> I think this pretty clearly points to a hardware problem in the PIC
> USART.
>
> have fun all,
> DLC
>
--
*******************************************
VISIT MY HOME PAGE:

LAST UPDATED: 23/08/2003
*******************************************
Regards
Eirik Karlsen


(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Further addendum. If I use BRGH=0 and BRG16=1 for using the /16 clock
then I can get 300 to 115200 with less than 2% error - All appear to
work properly. The 115200 has the worst clock error in this mode at
about 1.4%. All receive rates appear to work in this range.

I'm posting all of this for posterity. While I have seen numerous
reports of USART problems with the PIC on this forum, it appears that
no one ever posts a resolution, leaving the rest of us to wonder. So,
here is a resolution to this problem that _I_ had at any rate.

FYI,
DLC

--- In p...@yahoogroups.com, "Dennis Clark" wrote:
>
> I got it to work folks, however...
>
> I've found that the USART mode that uses the 16 bit divisor does not
> work well for lower baud rates. How low? I don't know, I've got to
> quantify it.
>
> If I use either of these two configurations:
> BRG16=0, BRGH=0, SPBRG=64 (error = 0.16%)
> BRG16=0, BRGH=1, SPBRG=255 (error = 1.73%)
> Everything at 9600 bps works fine. Where is the breakover point? Now
> my code isn't so clean because I've got to decide how to set the bits
> and divide the values depending upon the rate instead of using the
> ever-so-nice 16 bit divisor method which covered all my bases. This
> wouldn't be so bad but I have about 16 bytes of FLASH left to do this
> fix with.
>
> I think this pretty clearly points to a hardware problem in the PIC
> USART.
>
> have fun all,
> DLC
>



to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

--- In p...@yahoogroups.com, Eirik Karlsen wrote:
>
> You ARE aware that if you get above +/-5% error there is a very
> high risk of getting bit error, which is most likely to happend at the
> last bit...?
>

Please read all of the posts in this thread.

You will note that I have been using the highest precision
configuration that the PIC has on this device and it was not working.
I have moved to lower resolution, slightly higher clock error and now
the USART receive _IS_ working. So, no your assertion does not
qualify in this problem report.

My assertion, based on three days of head banging an optimally
provided suggestion from a fellow worker solved the issue, is thus:

****
Do NOT use the BRGH=1 and BRG16=1 combination on the PIC18F6680. The
receive data is not reliable at anything but 15200 bps (and perhaps
higher). At lower clock rates the read data is unreliable when
streaming bits back-to-back. It works fine if you have either 2 stop
bits or long delays between characters.
****

This information may be of value to others working with similar 18F parts.

FYI,
DLC

> Dennis Clark wrote:
>
> > I got it to work folks, however...
> >
> > I've found that the USART mode that uses the 16 bit divisor does not
> > work well for lower baud rates. How low? I don't know, I've got to
> > quantify it.
> >
> > If I use either of these two configurations:
> > BRG16=0, BRGH=0, SPBRG=64 (error = 0.16%)
> > BRG16=0, BRGH=1, SPBRG=255 (error = 1.73%)
> > Everything at 9600 bps works fine. Where is the breakover point? Now
> > my code isn't so clean because I've got to decide how to set the bits
> > and divide the values depending upon the rate instead of using the
> > ever-so-nice 16 bit divisor method which covered all my bases. This
> > wouldn't be so bad but I have about 16 bytes of FLASH left to do this
> > fix with.
> >
> > I think this pretty clearly points to

a hardware problem in the PIC
> > USART.
> >
> > have fun all,
> > DLC
> >
> --
> *******************************************
> VISIT MY HOME PAGE:
>
> LAST UPDATED: 23/08/2003
> *******************************************
> Regards
> Eirik Karlsen
>



to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

HI Scott,

It's just p...@yahoogroups.com There is also a new pic_group, but you
won't see much activity there.

I got the impression that there was more to it then the errata acknowledged.
There have been a lot of discussions about "tailgating" RX/TX operations.
We probably don't have that problem. A review of the messages on yahoo
might help if you run into anything curious.

Alan

> -----Original Message-----
> From: p...@yahoogroups.com [mailto:p...@yahoogroups.com] On Behalf
> Of Dennis Clark
> Sent: Friday, July 21, 2006 2:00 PM
> To: p...@yahoogroups.com
> Subject: [piclist] Re: 18F6680 at 9600 USART garbles read data
>
> Further addendum. If I use BRGH=0 and BRG16=1 for using the /16 clock
> then I can get 300 to 115200 with less than 2% error - All appear to
> work properly. The 115200 has the worst clock error in this mode at
> about 1.4%. All receive rates appear to work in this range.
>
> I'm posting all of this for posterity. While I have seen numerous
> reports of USART problems with the PIC on this forum, it appears that
> no one ever posts a resolution, leaving the rest of us to wonder. So,
> here is a resolution to this problem that _I_ had at any rate.
>
> FYI,
> DLC
>
> --- In p...@yahoogroups.com, "Dennis Clark" wrote:
> >
> > I got it to work folks, however...
> >
> > I've found that the USART mode that uses the 16 bit divisor does not
> > work well for lower baud rates. How low? I don't know, I've got to
> > quantify it.
> >
> > If I use either of these two configurations:
> > BRG16=0, BRGH=0, SPBRG=64 (error = 0.16%)
> > BRG16=0, BRGH=1, SPBRG=255 (error = 1.73%)
> > Everything at 9600 bps works fine. Where is the breakover point? Now
> > my code isn't so clean because I've got to decide how to set the bits
> > and divide the values depending upon the rate instead of using the
> > ever-so-nice 16 bit divisor method which covered all my bases. This
> > wouldn't be so bad but I have about 16 bytes of FLASH left to do this
> > fix with.
> >
> > I think this pretty clearly points to a hardware problem in the PIC
> > USART.
> >
> > have fun all,
> > DLC
> >
> to unsubscribe, go to http://www.yahoogroups.com and follow the
> instructions
>



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Hi,

I've also been having weird problems with the divisor. I'm using a
PIC18F4550 with a 20 MHz crystal. I've been trying to get ANY serial
communications working (I'm using the PICDEM FS USB board). I finally
broke down and wrote a program that tried every possible value for
SPBRG (and the program outputs text and an ascii table at each
discrete SPBRG value), and I set my terminal program to 9600 (8N1).
The weird thing is that the SPBRG values that worked were from 0x4A to
0x51 (!!). According to the calculation in the datasheet, it should
be ~31 (20000000/9600/64 - 1) -- that certainly explains all the
framing errors I was seeing when I had it set at 31. Now for the life
of my I cannot understand how these values could possibly work. I
verified that SYNC = 0 (Asynch mode), BRGH = 0, and BRG16 = 0. The
config bits are set to HSPLL (so the CPU's running at 48 MHz on a 20
MHz clock (PLL divisor is 5 obviously, and CPU divisor is 2). If I
work backwards and try to calculation Fosc from the SPBRG values of
0x4A-0x51, I get between 46-48MHz -- Fosc cannot be that, right?

What am I missing??

--S

--- In p...@yahoogroups.com, "Dennis Clark" wrote:
>
> --- In p...@yahoogroups.com, Eirik Karlsen wrote:
> >
> > You ARE aware that if you get above +/-5% error there is a very
> > high risk of getting bit error, which is most likely to happend at the
> > last bit...?
> > Please read all of the posts in this thread.
>
> You will note that I have been using the highest precision
> configuration that the PIC has on this device and it was not working.
> I have moved to lower resolution, slightly higher clock error and now
> the USART receive _IS_ working. So, no your assertion does not
> qualify in this problem report.
>
> My assertion, based on three days of head banging an optimally
> provided suggestion from a fellow worker solved the issue, is thus:
>
> ****
> Do NOT use the BRGH=1 and BRG16=1 combination on the PIC18F6680. The
> receive data is not reliable at anything but 15200 bps (and perhaps
> higher). At lower clock rates the read data is unreliable when
> streaming bits back-to-back. It works fine if you have either 2 stop
> bits or long delays between characters.
> ****
>
> This information may be of value to others working with similar 18F
parts.
>
> FYI,
> DLC
>
> > Dennis Clark wrote:
> >
> > > I got it to work folks, however...
> > >
> > > I've found that the USART mode that uses the 16 bit divisor does not
> > > work well for lower baud rates. How low? I don't know, I've got to
> > > quantify it.
> > >
> > > If I use either of these two configurations:
> > > BRG16=0, BRGH=0, SPBRG=64 (error = 0.16%)
> > > BRG16=0, BRGH=1, SPBRG=255 (error = 1.73%)
> > > Everything at 9600 bps works fine. Where is the breakover point? Now
> > > my code isn't so clean because I've got to decide how to set the
bits
> > > and divide the values depending upon the rate instead of using the
> > > ever-so-nice 16 bit divisor method which covered all my bases. This
> > > wouldn't be so bad but I have about 16 bytes of FLASH left to do
this
> > > fix with.
> > >
> > > I think this pretty clearly points to
>
> a hardware problem in the PIC
> > > USART.
> > >
> > > have fun all,
> > > DLC
> > >
> > --
> > *******************************************
> > VISIT MY HOME PAGE:
> >
> > LAST UPDATED: 23/08/2003
> > *******************************************
> > Regards
> > Eirik Karlsen
>
------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )