Post by thread:[PIC]: Framing Error

It's very frustrating, I'm working on this the last 4 days straight, no solution so far. I'm going to quickly tell you my problem, and tell you what I've done to try solving it. Problem: Very simple: I have a device that sends data through USART at 38400baud (I've also tested 19200). I need to receive those bytes and do something with them. Right now my problem is even simpler, I just want to receive them without errors. I've done this with my PIC16F877A (hw USART) and with my PIC18F242 and both of them present the same problem, they receive bytes, but more than 80% of them are in FERR condition. What I've tried: - Different baud speeds (38400, 19200) - Different microcontrollers (16f877A, 18f242) - Pooling the serial port - Using interrupts (that's what I'm using now) - I thought the problem could be in the connections with my device, then I've done a program on the PC to send exactly the same bytes, at the same speed, at the same baud rate through serial port, same thing. I'm using a development board, so in the main loop of the program I'm displaying the contents of RCSTA on PORTD (PORTA on 18f242), and I see bit 2 (FERR) blinking like crazy. I know that I'm having FEER on 80% of the bytes because I'm incrementing a counter everytime the FERR flag goes up on the interrupt, and I know how many bytes I send per second... I'm using mikropascal, here's the code (it's short, I promise) I'd appreciate your help very much, thanks! Padu ///////////////////////////////////////////////////////////////////// program GPSCountMessages; var i: integer; s: string[17]; rx,x: byte; procedure interrupt; begin //taking care of overflow if TestBit(RCSTA,OERR)=1 then begin ClearBit(RCSTA,CREN); SetBit(RCSTA,CREN); exit; end; if TestBit(RCSTA,FERR)=1 then begin x := RCREG; inc(i); end else begin //right now I'm not doing anything with that, I just want to get my bytes clean rx := RCREG; end; end; procedure Setup; begin Usart_init(38400); USART_Read; INTCON := 0; // all interrupt bits off PIR1 := 0; // .. PIE1 := 0; // disable all ext. interrupts SetBit(PIE1,RCIE); SetBit(INTCON,GIE); SetBit(INTCON,PEIE); end; {main procedure} begin TRISA := 0; PORTA := $FF; Lcd_Init(PORTB); Lcd_Cmd(LCD_CLEAR); LCD_Cmd(LCD_CURSOR_OFF); LCD_Out(1,1,'FERR msg count'); Delay_ms(500); LCD_Out(2,1,' '); PORTA := 0; rx := 0; i := 0; found := false; Setup; while true do begin PORTA := RCSTA; inttostr(i,s); LCD_Out(2,1,s); end; end. ___________________________________________

Hi Padu, My question to you is: What is the frequency Kenneth? :) Seriously, you left out one important detail in your message -- the Fosc you are supplying to the PIC: 1) What is your clock source for the PIC, and what is the frequency of it? 2) Is it a clock oscillator, quartz crystal, or ceramic resonator? Please tell us the frequency that is stamped on the part. It could very well be that your percentage errors are great enough (between the frequency deviance of your Fosc clock source and your PC's tolerance) to cause your framing errors. Best regards, Ken Pergola ____________________________________________

On Nov 2, 2004, at 10:49 PM, Padu wrote: > > Problem: Very simple: I have a device that sends data through USART at > 38400baud (I've also tested 19200). I need to receive those bytes and > do something with them. Right now my problem is even simpler, I just > want to receive them without errors. I've done this with my PIC16F877A > (hw USART) and with my PIC18F242 and both of them present the same > problem, they receive bytes, but more than 80% of them are in FERR > condition. > Framing errors are usually speed mismatches. Are you sure that mikropascal's idea of what your clockrate is matches the actual hardware? Can you check the generated code to make sure it's coming up with a reasonable number? BillW ____________________________________________

Hi Padu, Also, what I was trying to get at with my previous post is this: What is your calculated baud rate error (given Fosc and your desired baud rate)? For *all practical purposes*, is the calculated value 0%, or pretty close to it by a few percentage points, +/-? If it isn't, a general rule of thumb is that ceramic resonators will generally introduce a greater frequency tolerance than that of a quartz crystal in your baud rate. Best regards, Ken Pergola ____________________________________________

Do you have a MAX232 or equivalent or other inverting circuit? Bob Ammerman RAm Systems ----- Original Message ----- From: "Ken Pergola" <spam_OUTno_spamTakeThisOuTlocalnet.com> To: "Microcontroller discussion list - Public." <.....piclistKILLspam@spam@mit.edu> Sent: Wednesday, November 03, 2004 2:22 AM Subject: RE: [PIC]: Framing Error {Quote hidden}> > Hi Padu, > > My question to you is: > > What is the frequency Kenneth? :) > > Seriously, you left out one important detail in your message -- the Fosc > you > are supplying to the PIC: > > 1) What is your clock source for the PIC, and what is the frequency of it? > > 2) Is it a clock oscillator, quartz crystal, or ceramic resonator? > > Please tell us the frequency that is stamped on the part. It could very > well > be that your percentage errors are great enough (between the frequency > deviance of your Fosc clock source and your PC's tolerance) to cause your > framing errors. > > Best regards, > > Ken Pergola > > > ______________________________________________

> What is the frequency Kenneth? :) > > Seriously, you left out one important detail in your message -- the Fosc you > are supplying to the PIC: Afte a few more tests, I have a little bit more information. I was using the HS osc. 4MHz. With the 16f877a, I wasn't successfull at al. With the 18f242, same thing, 80% of bytes in framing error. Then I tried using the HSPLL osc and changed the frequency to 16MHz. The framing errors dropped considerable to around 20% of bytes with error, but still, I want no byte in error. Finally, I tried the basics, changed frequency back to 4Mhz and the XT osc. and tried communicating at 2400, GOT IT! Then I started climbing the baud rate, 4800, 9600 and 19200. 38400 and bang! Framing error again. Do you think it possible to achieve baud rates higher than 38400 with a 4MHz crystal? My crystal board has this 4MHz crystal and it doesn't look like it's something easy to replace, but I don't care because I'm starting to build the first prototype, and then my concern is what crystal to get in order to achieve baud rates of 57600 and even higher? ____________________________________________

>Finally, I tried the basics, changed frequency back to 4Mhz >and the XT osc. and tried communicating at 2400, GOT IT! OK that is fine >Then I started climbing the baud rate, 4800, 9600 and 19200. >38400 and bang! Framing error again. OK, what devisor are you using for 38.4k, and what is the error figure when you use the formula given in the data sheet? At 4MHz for Fosc, according to the formula in the data sheet, for 38400 baud you need a divisor of 0.627 for BRGH= 0, and 5.5104 for BRGH=1. Now at BRGH=1, using 5 as the divisor (it can only be an integer) you end up with an actual baud rate of 41666.6, which is an error of 8.5%. Using 6 as a divisor (again nearest integer the other side) gives a baud rate of 35714.2, which is an error of -6.99%. Now anything over about 4% is likely to introduce errors(allowing for small errors at the other end), so these equate to what you see. ____________________________________________

{Quote hidden}>-----Original Message----- >From: piclist-bouncesKILLspammit.edu [.....piclist-bouncesKILLspam.....mit.edu] >On Behalf Of Alan B. Pearce >Sent: 04 November 2004 15:53 >To: Microcontroller discussion list - Public. >Subject: Re: [PIC]: Framing Error > > >>Finally, I tried the basics, changed frequency back to 4Mhz >and the XT >>osc. and tried communicating at 2400, GOT IT! > >OK that is fine > >>Then I started climbing the baud rate, 4800, 9600 and 19200. >38400 and >>bang! Framing error again. > >OK, what devisor are you using for 38.4k, and what is the >error figure when you use the formula given in the data sheet? > >At 4MHz for Fosc, according to the formula in the data sheet, >for 38400 baud you need a divisor of 0.627 for BRGH= 0, and >5.5104 for BRGH=1. Now at BRGH=1, using 5 as the divisor (it >can only be an integer) you end up with an actual baud rate of >41666.6, which is an error of 8.5%. Using 6 as a divisor >(again nearest integer the other side) gives a baud rate of >35714.2, which is an error of -6.99%. Now anything over about >4% is likely to introduce errors(allowing for small errors at >the other end), so these equate to what you see. Padu, In order to get a zero (or at least very low) error, you need to choose a crystal frequency that is an integer multiple of your baud rate. A commonly available crystal is 11.0592MHz. This will allow you to support 38.4k and higher. Note also, another limiting factor is the time between incomming bytes. The PIC takes a number of cycles to enter the interrupt and process the incomming data. At 38400 you have 260 microseconds, at 115200, you have only 86 microseconds. The Regards Mike ======================================================================= This e-mail is intended for the person it is addressed to only. The information contained in it may be confidential and/or protected by law. If you are not the intended recipient of this message, you must not make any use of this information, or copy or show it to any person. Please contact us immediately to tell us that you have received this e-mail, and return the original to us. Any use, forwarding, printing or copying of this message is strictly prohibited. No part of this message can be considered a request for goods or services. ======================================================================= ____________________________________________

> >OK, what devisor are you using for 38.4k, and what is the error figure when >you use the formula given in the data sheet? > >At 4MHz for Fosc, according to the formula in the data sheet, for 38400 baud >you need a divisor of 0.627 for BRGH= 0, and 5.5104 for BRGH=1. Now at >BRGH=1, using 5 as the divisor (it can only be an integer) you end up with >an actual baud rate of 41666.6, which is an error of 8.5%. The only way to get accurate baud over a wide range, is to use baud-multiple crystals. Otherwise, you push the error too far. In practice, you can allow the other guy half the error budget, but in design, I prefer to allow me as little as possible, since you never know what you'll be connecting to. ____________________________________________

At 11:43 AM 11/4/2004, William "Chops" Westfield wrote: >On Nov 4, 2004, at 6:51 AM, Padu wrote: > >>Do you think it possible to achieve baud rates higher than 38400 >>with a 4MHz crystal? > >Looking at table 10-3 and 10-4 in the 87x manual (Baud rates for asynch >mode), it doesn't look like the BRG will do higher than 19200 at >acceptable accuracy, with a 4MHz crystal... > >You could do better bit-banging, if you have the extra cycles... OTOH, some devices use even MHz xtals to get odd bauds. MIDI is one of them. ____________________________________________

Padu wrote: > Problem: Very simple: I have a device that sends data through USART at > 38400baud (I've also tested 19200). I need to receive those bytes and > do something with them. Right now my problem is even simpler, I just > want to receive them without errors. I've done this with my PIC16F877A > (hw USART) and with my PIC18F242 and both of them present the same > problem, they receive bytes, but more than 80% of them are in FERR > condition. This is exactly the symptom you would get if the baud are right on the edge of being close enough. This can be easily verified by watching on a scope the same byte being transmitted by each UART. See my UART_BAUD and UART_SETUP macros in STD.INS.ASPIC at http://www.embedinc.com/pic. You tell them the oscillator frequency and the desired baud rate, and they take care of the UART setup details. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

> At 4MHz for Fosc, according to the formula in the data sheet, for 38400 > baud > you need a divisor of 0.627 for BRGH= 0, and 5.5104 for BRGH=1. Now at > BRGH=1, using 5 as the divisor (it can only be an integer) you end up with > an actual baud rate of 41666.6, which is an error of 8.5%. Using 6 as a > divisor (again nearest integer the other side) gives a baud rate of > 35714.2, > which is an error of -6.99%. Now anything over about 4% is likely to > introduce errors(allowing for small errors at the other end), so these > equate to what you see. You can get zero baud rate error by choosing a crystal whose frequency is an exact multiple of 64 * Bit rate There are many standard crystals that meet this criteria. For example, at 115,200 bits per second, you could use a 7.3728 MHz crystal. To stay under 4MHz, you could use 57,600 bits per second and use a 3.68640 MHz crystal. The highest crystal frequency you can use under 20MHz for 115,200 bits per second is 18.432 MHz. Bob Ammerman RAm Systems ____________________________________________

Padu wrote: > Do you think it possible to achieve baud rates higher than 38400 with a > 4MHz crystal? You can answer this easily yourself. The 16x baud clock is created by dividing the oscillator frequency by an integer. The baud rate resolution is therefore very poor for low oscillator frequencies and high baud rates. For example, with 4MHz oscillator here are the fastest few baud rates: OSC | Div | Baud -------------------- 4MHz 1 250K 4MHz 2 125K 4MHz 3 83.3K 4MHz 4 62.5K 4MHz 5 50.0K 4MHz 6 41.7K 4MHz 7 35.7K 4MHz 8 31.3K 4MHz 9 27.8K 4MHz 10 25.0K To get 38400 baud, you have a choice of 41.7Kbaud (8.6% too high), or 35.7Kbaud (7.0% too low). Both those errors are too high. You therefore can't do proper 38400 baud with a 4MHz oscillator. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

olin_piclist@embedinc.com (Olin Lathrop) > Padu wrote: > > Do you think it possible to achieve baud rates higher than 38400 with a > > 4MHz crystal? > > You can answer this easily yourself. The 16x baud clock is created by > dividing the oscillator frequency by an integer. > > To get 38400 baud, you have a choice of 41.7Kbaud (8.6% too high), or > 35.7Kbaud (7.0% too low). Both those errors are too high. You therefore > can't do proper 38400 baud with a 4MHz oscillator. You can do interesting things with non-integer dividers, however. It isn't difficult to set up a 4-bit counter so that it produces 6 output pulses for every 13 input pulses. With a 4-MHz input clock, it produces a slightly jittery output clock of 1.846154 MHz, which is only 0.16% high relative to a "standard" 1.8432 MHz baud rate generator crystal. If you then divide this by 3, you have your 16x clock for 38400 baud. You can also do 57600 and 115200 with the same accuracy. Obviously, this requires logic external to the PIC. It's too bad, that with all those PICs that have on-chip 4 MHz oscillators, that Microchip doesn't include this tiny bit of additional logic to generate standard baud rates. -- Dave Tweed ____________________________________________

{Quote hidden}> Olin Lathrop wrote: > You can answer this easily yourself. The 16x baud clock is created by > dividing the oscillator frequency by an integer. The baud rate resolution > is therefore very poor for low oscillator frequencies and high baud rates. > > For example, with 4MHz oscillator here are the fastest few baud rates: > > OSC | Div | Baud > -------------------- > 4MHz 1 250K > 4MHz 2 125K > 4MHz 3 83.3K > 4MHz 4 62.5K > 4MHz 5 50.0K > 4MHz 6 41.7K > 4MHz 7 35.7K > 4MHz 8 31.3K > 4MHz 9 27.8K > 4MHz 10 25.0K > > To get 38400 baud, you have a choice of 41.7Kbaud (8.6% too high), or > 35.7Kbaud (7.0% too low). Both those errors are too high. You therefore > can't do proper 38400 baud with a 4MHz oscillator. Let me see if I got this right, if I want to be able to communicate at 38400/57600, then I'd have to find one crystal that would minimize rounding innacuracies. Having in mind that I'll set BRGH, then I came up with the following table: Desired Baud | SPBRG | Perfect Crystal 38400 7 4.9152 38400 8 5.5296 38400 9 6.1440 38400 10 6.7584 38400 12 7.9872 38400 14 9.2160 38400 16 10.4448 57600 5 5.5296 57600 6 6.4512 57600 7 7.3728 57600 8 8.2944 57600 10 10.1376 57600 12 11.9808 If my calculations were right, then a 5.5296MHz crystal would be perfect for both 38.4K and 57.6K baud rates, am I correct? I went to digikey and amazingly enough, there is a crystal at exactly this frequency (CSA309-5.5296MABJ). Should I order it? Which one is better, cylinder or smd? Just go digikey's main page and type in "5.5296" on the search edit box. ____________________________________________

Padu wrote: {Quote hidden}>>Olin Lathrop wrote: >>You can answer this easily yourself. The 16x baud clock is created by >>dividing the oscillator frequency by an integer. The baud rate resolution >>is therefore very poor for low oscillator frequencies and high baud rates. >> >>For example, with 4MHz oscillator here are the fastest few baud rates: >> >> OSC | Div | Baud >> -------------------- >> 4MHz 1 250K >> 4MHz 2 125K >> 4MHz 3 83.3K >> 4MHz 4 62.5K >> 4MHz 5 50.0K >> 4MHz 6 41.7K >> 4MHz 7 35.7K >> 4MHz 8 31.3K >> 4MHz 9 27.8K >> 4MHz 10 25.0K >> >>To get 38400 baud, you have a choice of 41.7Kbaud (8.6% too high), or >>35.7Kbaud (7.0% too low). Both those errors are too high. You therefore >>can't do proper 38400 baud with a 4MHz oscillator. >> >> > > >Let me see if I got this right, if I want to be able to communicate at >38400/57600, then I'd have to find one crystal that would minimize rounding >innacuracies. Having in mind that I'll set BRGH, then I came up with the >following table: > >Desired Baud | SPBRG | Perfect Crystal > 38400 7 4.9152 > 38400 8 5.5296 > 38400 9 6.1440 > 38400 10 6.7584 > 38400 12 7.9872 > 38400 14 9.2160 > 38400 16 10.4448 > 57600 5 5.5296 > 57600 6 6.4512 > 57600 7 7.3728 > 57600 8 8.2944 > 57600 10 10.1376 > 57600 12 11.9808 > > >If my calculations were right, then a 5.5296MHz crystal would be perfect for >both 38.4K and 57.6K baud rates, am I correct? > >I went to digikey and amazingly enough, there is a crystal at exactly this >frequency (CSA309-5.5296MABJ). Should I order it? >Which one is better, cylinder or smd? Just go digikey's main page and type >in "5.5296" on the search edit box. > > I personally don't like crystals at all, but if you have to get them, the cylindrical one, mounted with a small loop on the wires and the body encased in silicone bathtub caulk, will probably last forever. SMD crystals are easily damaged by vibration and shock, don't go that way. --Bob -- Note: Attachments must be sent to EraseMEattachspam_OUTTakeThisOuTengineer.cotse.net, and MAY delay replies to this message. 520-219-2363 ____________________________________________

Padu wrote: > Desired Baud | SPBRG | Perfect Crystal > 38400 7 4.9152 > 38400 8 5.5296 > 38400 9 6.1440 > 38400 10 6.7584 > 38400 12 7.9872 > 38400 14 9.2160 > 38400 16 10.4448 > 57600 5 5.5296 > 57600 6 6.4512 > 57600 7 7.3728 > 57600 8 8.2944 > 57600 10 10.1376 > 57600 12 11.9808 I spot checked a few values, and they were right. > If my calculations were right, then a 5.5296MHz crystal would be > perfect for both 38.4K and 57.6K baud rates, am I correct? Yes. Another way to do this is to use as fast an oscillator frequency as possible. With 20MHz oscillator you don't hit each baud rate exactly, but the integer divider number is high enough so that you have better resolution and the nearest choice is close enough. The drawback of this technique is that it takes more power. If power isn't an issue, then I usually want to max out the oscillator frequency anyway. > I went to digikey and amazingly enough, there is a crystal at exactly > this frequency (CSA309-5.5296MABJ). There is nothing amazing about this. That frequency is there for exactly the reason you went looking for it. There are a whole series of "baud rate" frequency crystals. > Should I order it? How should I possibly make that value judgement for you? I hope you're not going to ask me what you should have for dinner and when to go to the bathroom too. > Which one is better, cylinder or smd? Again, I can't answer for your application. Some variant of HC-49 is probably easiest for a hobbyist. For volume production, surface mount is best. Make sure that whatever crystal you get is specified for parallel resonant operation as required by all PICs. This means it will be rated for use with a parallel capacitance, usually in the 15-25pF range for this frequency. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

Shawn Yates wrote: > That raises a question I have had. What % error is acceptable to most > devices (In particular computers)? I like to keep the total mismatch between transmitter and receiver to less than 1/4 bit in the middle of the last data bit. That comes out to 2.9%. 5.9% is the guaranteed bad data threshold, and framing errors will start at 5.3%. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

Shawn Yates <piclistspam_OUTmit.edu> wrote: > That raises a question I have had. What % error is acceptable to > most devices (In particular computers)? +/- 5% or so, over the entire transmit/receive system, is the maximum. Ideally, you'll have less (+/- 2% is almost always acceptable). Although it's possible to build systems that can tolerate more error, you can't count on having one of those. A minimal receiver will decode serial data by sampling in what it thinks is the center of each bit, so you can tolerate a maximum of 50% error in the position of any bit. You can only depend on the transmitter and receiver being synchronized at the leading edge of the start bit, and there are 10 bits sent after that edge (start bit, 8 data bits, stop bit). To keep the final bit's timing error under 50%, therefore, the timing error over the entire ten bits has to be less than 5%. -Andy === Andrew Warren -- @spam@aiwKILLspamcypress.com === Principal Design Engineer === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation ____________________________________________

part 1 1400 bytes content-type:text/plain; (decoded 7bit) > Bob Ammerman wrote: >> You can get zero baud rate error by choosing a crystal whose frequency >> is an exact multiple of >> >> 64 * Bit rate > > True, but it only NEEDS to be a multiple of 16, at least on PICs that have > the "high speed" baud rate generator option. > Awk.... my bad. Which invalidates most of the content of my last post on this matter. To make it clear what Olin is talking about, on many newer PICs (nearly all the current ones?) there are two choices for baud rate calculation: with the BRGH bit set, the baud rate is Fosc/(16*(BRG+1)) with the BRGH bit clear, the baud rate is Fosc/(64*(BRG+1)) This implies several things. 1) To get relatively low baud rates when you have a fast clock you have to use the formula where BRGH is clear. 2) To get high baud rates setting BRGH lets you get better resolution. Attached is a PDF with a table showing the maximum crystal frequencies (below 4Mhz and 20MHz) that will provide a perfect frequency for various popular baud rates. It takes into account the BRGH bit. Some of the entries are 0 indicating that there is no possible crystal to do the job. This is either because: 1) the baud rate is too low and the divisor register would have to be set to a value > 255, or 2) the baud rate is too high Bob Ammerman RAm Systems part 2 3021 bytes content-type:application/pdf; (decode) part 3 79 bytes content-type:text/plain; charset="us-ascii" (decoded 7bit) ____________________________________________

> > Another way to do this is to use as fast an oscillator frequency as > possible. With 20MHz oscillator you don't hit each baud rate exactly, but > the integer divider number is high enough so that you have better resolution > and the nearest choice is close enough. The drawback of this technique is > that it takes more power. If power isn't an issue, then I usually want to > max out the oscillator frequency anyway. That's what I'm thinking... this is going to draw power from a 9v battery, so power consumption is an issue. When the application approaches its final design stages, we'll choose only one baud rate, so if there aren't any other disadvantages on using a slower clock (5.something), then I believe I should go for that. > > Should I order it? > > How should I possibly make that value judgement for you? I hope you're not > going to ask me what you should have for dinner and when to go to the > bathroom too. Possibly yes =D > > Which one is better, cylinder or smd? > > Again, I can't answer for your application. Some variant of HC-49 is > probably easiest for a hobbyist. For volume production, surface mount is > best. Someone else indicated that moments ago in another post that cylindrical is more resistant to vibrations. This device will be inside a racebike or a racecar, then I guess cylindrical would be better. > Make sure that whatever crystal you get is specified for parallel resonant > operation as required by all PICs. This means it will be rated for use with > a parallel capacitance, usually in the 15-25pF range for this frequency. Humnn, I don't know what you are talking about but I'll make my homework and check that. Thanks a lot... ____________________________________________

Padu <KILLspampiclistKILLspammit.edu> wrote: > Someone else indicated that moments ago in another post that > cylindrical is more resistant to vibrations. This device will be > inside a racebike or a racecar, then I guess cylindrical would be > better. Higher-frequency crystals, because they're physically smaller, are often more shock- and vibration-resistant than low-frequency crystals. It's probably not an issue in this case, since the frequencies you're choosing from aren't THAT far apart, but maybe something to keep in mind for other crystals you might need in your high-vibration application. -Andy === Andrew Warren -- RemoveMEaiwTakeThisOuTcypress.com === Principal Design Engineer === Cypress Semiconductor Corporation === === Opinions expressed above do not === necessarily represent those of === Cypress Semiconductor Corporation ____________________________________________

> That raises a question I have had. What % error is acceptable to most > devices (In particular computers)? A little math can show you that for typical 8-bit communications you have a maximum error budget of about 6%. This includes any clock errors on both ends of the link, as well as any issues causes 'phase shifting' of the signal (like unequal rise and fall times in the driver chip). A PC typically has a very accurate clock, leavinig you with a maximum budget of maybe 5%. I'd certainly try to stay below 2-3%, even if I knew the other side was a PC. A side story: I had to develop a device that could transmit an async word with 1 start bit, 240 (yes thats right!) data bits, and 1 stop bit. This obviously requires a much more accurate clock. Since the PC UART had no chance of receiving such a weird format (could you imaging a 240 bit wide receiver data register) I had to get creative. What I did was to bit-bang the output onto the DTR line of the serial port, which was then cross-wired via an adapter to the TX pin. To get the baud rate right, I just transmitted dummy data bytes out the TX pin (which fell into the bit bucket). By transmitting these bytes at 9600 baud (which is 8 times my desired bit rate of 1200 baud) and setting the UART to 6 bits per char, I was able to generate an interrupt exactly at my bit rate (because the UART needed 8 bit times to send each character). Sounds like it should work beautifully, doesn't it? Wrong! It turns out that the baud rate clocks on various PC motherboards are derived from various sources. Any frequency that is around that can be divided down to approximately the right value (+/- 0.5 % or so) seems to be used to avoid adding another crystal to drive the UART. In some cases ceramic resonators are used instead of crystals. To get around this problem I had to complete rewrite my code to use the system timer, which counts up to 65535 at the famous 18.2 ticks per second rate to control my timing. What an aggravation. BTW: I'd love to get my hands on the nitwit that designed the 240 bit protocol to begin with. Bob Ammerman RAm Systems ____________________________________________

I'll make one more post on this issue. You will notice that most of the popular bit-per-second rates are 2400*2^N, where N ranges from 0 (2400 bits per second) to 4 (38,400) bits per second. However 57,600 and 115,200 multiply in a factor of 3 (ie: 57,600 = 19,200 * 3, and 115,200 = 38,400 * 3). So, a good crystal that would work with zero error for all these rates would be any multiple of: 16 * 2400 * 2^4 * 3 or: 1,843,200 Hz The largest such value < 4MHz is 3,686,400 Hz The largest such value < 20MHz is 18,432,000 Hz You will find crystals in both of these frequencies readily available. Bob Ammerman RAm Systems ____________________________________________

> That raises a question I have had. What % error is acceptable to most > devices (In particular computers)? Thats a very frequent FAQ. You can do the calculation yourself, assuming your cable and other electronics do not add any delays or skews. I say: any product with an error above 1% should not leave my desktop. Wouter van Ooijen -- ------------------------------------------- Van Ooijen Technische Informatica: http://www.voti.nl consultancy, development, PICmicro products docent Hogeschool van Utrecht: http://www.voti.nl/hvu ____________________________________________

Just a few notes... Most of this error rate calculations becomes more or less an non-issue if using any of the newer PICs with the EUSART. They have a 16 bit baudrate register that gives you much better control over the baudrate generator. Check the tables with error rates using BRGH=1 and BRG16=1. Low error rates even at Fosc 8Mhz (= INTOSC) up to 115 Kbaud. +0.79% @ 57.6 Kbaud and -2.12% @115.2 Kbaud. 19.2 Kbaud and lower are all below 0.2%. No real need anymore for "odd" speed xtals. They also have an "auto baud rate detect" feature, that automaticly sets (trims) the baudrate register after detecting an special character sent to the PIC (h'55'). That would make the unit self-trimming if the PICs osc isn't running exactly at the expected speed (such as when running unsing the internal OSC). If the PIC and the "host" detects framing errors or other problems, the link could be put back to "auto baud rate detection" mode to re-calibrate itself. Yes, of course the freq "error" of the INTOSC has to be taken into account, but the auto baud rate detect would (partly) take care of that. These newer PICs are also "nanoWatt" devices that might have some added benefits since the original poster was talking about battery power and that the power consumption was an issue. Finaly, the INTOSC might give a better shock and vibration resistant solution then when using external xtals or cer-res (and two additional I/O pins :-) ). Jan-Erik. ____________________________________________

----- Original Message ----- From: "Jan-Erik Soderholm" <spamBeGonejan-erik.soderholmspamBeGonetelia.com> To: <TakeThisOuTpiclistEraseMEspam_OUTmit.edu> Sent: Friday, November 05, 2004 3:10 AM Subject: RE: [PIC]: Framing Error {Quote hidden}> Just a few notes... > > Most of this error rate calculations becomes more or less > an non-issue if using any of the newer PICs with the EUSART. > They have a 16 bit baudrate register that gives you much > better control over the baudrate generator. Check the tables > with error rates using BRGH=1 and BRG16=1. Low error rates > even at Fosc 8Mhz (= INTOSC) up to 115 Kbaud. +0.79% > @ 57.6 Kbaud and -2.12% @115.2 Kbaud. 19.2 Kbaud and lower > are all below 0.2%. No real need anymore for "odd" speed > xtals. Huh? Having a 16-bit baud rate divisor doesn't give you any better resolution at high bit-per-second rates. It does let you get to lower rates for a given clock frequency however. It seems like the world has standardized on a "16 * the bit-rate" clock for UARTs. This is a bit silly since many software (bit-banged) UARTs work fine at sampling frequencies as low as 3 x the bit rate (including several I have written). The high sampling rates do allow for a more accurate determination of the leading edge of the start bit, and sampling close to the center of the data bits. Some UARTs even perform multiple samples (say at 7/16, 8/16 and 9/16 into the bit time) and return the majority value. I would expect that a UART using an "8 * the bit-rate" clock would work very well and would allow for more resolution at high rates, and higher maximum rates. I have a software UART I wrote that uses a "6 * the bit-rate" clock and is very robust. It even does the majority vote thing on three samples per bit time. Alternatively, I can set a flag in the code so that any data bits where all three samples are not equal are considered an error condition. This is great for detecting marginal communications conditions. Bob Ammerman RAm Systems ____________________________________________

Shawn Yates wrote: > That raises a question I have had. What % error is acceptable to most > devices (In particular computers)? Hi Shawn, Attached you will find a technical document describing this. The entire document is very good, but to focus on your question, please see: ============================================= Section -- 9. - Required Clock Accuracy ============================================= Best regards, Ken Pergola PICList Administrators: ----------------------- P.S. I realize that this file is just a tad over the PICList file limit. I did my best to compress the PDF file but there is nothing else I can do to compress it any further (that I know of). Please forgive me if anyone gets mad -- I'm just trying to help the poster -- this question comes up from time to time and this document contains a very good technical description. Thank you so much. ____________________________________________

> Bob Ammerman wrote : > >> Huh? Having a 16-bit baud rate divisor doesn't give you any better >> resolution at high bit-per-second rates. It does let you get >> to lower rates for a given clock frequency however. > > Well, given that you use "Fosc/4" instead of "Fosc/16", it does, > doesn't it ? So at a specific buadrate, you have a four time as large > divisor and better (4 times also ?) resolution. > > Am I missing something ? > > Jan-Erik. If BRGH = 1 mode on the older UARTs the divisor formula is: Fosc / (16*(BRG+1)) In the UARTs with the 16-bit divisors the formula is: Fosc / (16*(BRG+1)) :-) Actually, the chance from Fosc/4 to Fosc was implemented when they came out with the BRGH=1 mode. Bob Ammerman RAm Systems ____________________________________________

Looks like from my end that my original message explaining my uploaded attachment did not come through the PICList. Anyway, a few posts back I uploaded a file (thank you for letting it through PICList administrators) that has some very good infomation related to this thread and not directly related to this thread -- please check out the PDF file contained in ZIP file I uploaded a few messages back... My original post: Shawn Yates wrote: > That raises a question I have had. What % error is acceptable to most > devices (In particular computers)? Hi Shawn, Attached you will find a technical document describing this. The entire document is very good, but to focus on your question, please see: ============================================= Section -- 9. - Required Clock Accuracy ============================================= Best regards, Ken Pergola ____________________________________________

Jan-Erik made an excellent point regarding the Enhanced UARTs in the PICs that have them. The Enhanced UARTs can greatly help nailing those baud rates you want with less baud rate percentage errors in some (but not all circumstances) versus the Standard UART. That's what's so nice about the Enhanced UARTs and their 16-bit baud rate generator register: For Enhanced UARTs (16-bit Baud Rate Generator register): --------------------------------------------------------- When BRGH=0: Baud rate = FOSC / ( 16 * ( SPBRG + 1 ) ) When BRGH=1: Baud rate = FOSC / ( 4 * ( SPBRG + 1 ) ) For Standard UARTs (8-bit Baud Rate Generator register): --------------------------------------------------------- When BRGH=0: Baud rate = FOSC / ( 64 * ( SPBRG + 1 ) ) When BRGH=1: Baud rate = FOSC / ( 16 * ( SPBRG + 1 ) ) Best regards, Ken Pergola ____________________________________________

Ken Pergola wrote : > Jan-Erik made an excellent point regarding the Enhanced UARTs > in the PICs that have them. Thanks ! :-) > The Enhanced UARTs can greatly help nailing > those baud rates you want with less baud rate > percentage errors in some (but not all circumstances) > versus the Standard UART. That's what's so > nice about the Enhanced UARTs and their 16-bit baud > rate generator register: Well yes, but... It's not thanks to the 16-bit BRG register as such, but the fact that those PIC's also have a "Fosc(4*(BRG+1))" mode, instead of a "Fosc(16*(BRG+1))" mode. As Bob Ammerman correctly pointed out, in a way... :-) Jan-Erik. {Quote hidden}> > > For Enhanced UARTs (16-bit Baud Rate Generator register): > --------------------------------------------------------- > > When BRGH=0: Baud rate = FOSC / ( 16 * ( SPBRG + 1 ) ) > When BRGH=1: Baud rate = FOSC / ( 4 * ( SPBRG + 1 ) ) > > > > > For Standard UARTs (8-bit Baud Rate Generator register): > --------------------------------------------------------- > > When BRGH=0: Baud rate = FOSC / ( 64 * ( SPBRG + 1 ) ) > When BRGH=1: Baud rate = FOSC / ( 16 * ( SPBRG + 1 ) ) > > Best regards, > > Ken Pergola ____________________________________________

----- Original Message ----- From: "Jan-Erik Soderholm" <RemoveMEjan-erik.soderholmTakeThisOuTtelia.com> To: <piclistEraseME.....mit.edu> Sent: Saturday, November 06, 2004 10:22 AM Subject: RE: [PIC]: Framing Error {Quote hidden}> Bob Ammerman wrote : > >> In the UARTs with the 16-bit divisors the formula is: >> >> Fosc / (16*(BRG+1)) >> >> :-) > > On the PIC18F1220/1320 it's : > > Fosc/(4*(BRG+1)) > > But maybe you just made a typo... :-) > I got fooled by looking at the dsPIC30F6011 docs, expecting them to be the same as the other UARTs with 16 bit BRGs. That was pretty stupid of me. Bob Ammerman RAm Systems ____________________________________________

Bob Ammerman wrote: > I got fooled by looking at the dsPIC30F6011 docs, expecting them to > be the same as the other UARTs with 16 bit BRGs. That was pretty > stupid of me. What's really annoying about the dsPIC UART is that it doesn't have a high speed mode. You get better baud rate resolution with a 18F at 40MHz than with a 30F at 120MHz. ***************************************************************** Embed Inc, embedded system specialists in Littleton Massachusetts (978) 742-9014, http://www.embedinc.com ____________________________________________

Back in the old days wrote a program on Apple II to decode Morse code off the air. With it you could tell if the code was sent by hand key, bug, keyer or keyboard. The trick was to have the dot and dash timings constantly resync and hunt around for proper timings. With the normal data transition timing, resyncing is only done with every start bit and the base timing is never changed. So any bit timing error is going to multiply with each bit received until the next start bit. Bill {Original Message removed}

Hi, an xtal with freq=4.432M is also available, which would yield baud rate approx 39550 which has a 3% error. Imre {Quote hidden}> For example, with 4MHz oscillator here are the fastest few baud rates: > > OSC | Div | Baud > -------------------- > 4MHz 1 250K > 4MHz 2 125K > 4MHz 3 83.3K > 4MHz 4 62.5K > 4MHz 5 50.0K > 4MHz 6 41.7K > 4MHz 7 35.7K > 4MHz 8 31.3K > 4MHz 9 27.8K > 4MHz 10 25.0K > > To get 38400 baud, you have a choice of 41.7Kbaud (8.6% too high), or > 35.7Kbaud (7.0% too low). Both those errors are too high. You therefore > can't do proper 38400 baud with a 4MHz oscillator. > > > ***************************************************************** > Embed Inc, embedded system specialists in Littleton Massachusetts > (978) 742-9014, http://www.embedinc.com > ______________________________________________