Post by thread:[PIC]: 16f628A with INTOSC adequate for 9600 seria

Eric Bohlman wrote: > In members' experience, can the 16f628A (which claims to have a precision > internal oscillator) adequately handle 9600bps reception when using the > 4MHZ internal oscillator? I have a design where freeing up two pins > would > be extremely helpful, so would like to avoid a crystal or resonator. The baud rate matters none - just the accuracy. I've used the 12C series with the internal R/C for comms and it worked just fine for me. Part of it depends on the temperature stability of the circuit and the other end. David... -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

pic microcontroller discussion list <> wrote: > In members' experience, can the 16f628A (which claims to have > a precision > internal oscillator) adequately handle 9600bps reception when > using the > 4MHZ internal oscillator? I have a design where freeing up > two pins would > be extremely helpful, so would like to avoid a crystal or resonator. The official answer should probably be a FAQ (starting with "No"). The real life answer is: IME, it usually works, but I wouldn't use it for volume production or anything critical. A serial byte is about 10 bits long (including start bits etc), and is usually sampled at the receiving end in the middle of each bit. Therefore, if the timing slips by more than 1/2 bit width during 10 bits, there will be errors. That's an error of 0.5/10 or 5%. If you assume that is shared across both transmitter and receiver, they are allowed 2.5% each, but it would be better to keep it under 1%. The 628A internal clock (IIRC) is about 3-4% The real life answer comes about because: 1) when I have used them for this purpose, I haven't needed them to be functional over a wide temperature or supply voltage range, 2) the typical accuracy is better than the worst case quoted in the datasheet 3) I don't usually have a PIC at each end, the PC end is probably a crystal, with accuracy better than 0.1% so the PIC can get away with a larger clock error If you can test each part across the full expected range, and afford to throw away some PICs, it might be worth a risk for a small controlled production run, but that's what you have to figure out- I wouldn't try it personally! As someone else has mentioned, the baud rate is irrelevant, the above problem is just as bad at 300 baud and 19200 baud Nigel -- This e-mail and any files transmitted with it ("E-mail") is intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the addressee(s), any disclosure, reproduction, copying, distribution or other use of the E-mail is prohibited. If you have received this E-mail in error, please delete it and notify the sender immediately via our switchboard or return e-mail. Neither the company nor any individual sending this E-mail accepts any liability in respect of the content (including errors and omissions) and timeliness of the E-mail which arise as a result of transmission. If verification is required, please request a hard copy version -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

>Why would that be? Aren't serial bitwidths wider at lower speeds? Yep but you measure those long bit width delays using the cpu clock so any error there will multiply up as you go round your timing loop lots of times. Cheers, Robin. This email originates from AXA Sun Life Services Plc (reg. no. 3424940) which is a service company for the following companies within the AXA UK plc Group: AXA Sun Life Plc (reg. no. 3291349) Sun Life Assurance Society Plc (reg. no. 776273) Sun Life Unit Assurance Limited (reg. no. 975601) Sun Life Pensions Management Limited (reg. no. 1105141) AXA Equity & Law Life Assurance Society Plc (reg. no. 575435) All of the above mentioned companies are registered in England and have their registered office at 107 Cheapside, London EC2V 6DU, England. This message and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. If you have received this in error, you should not disseminate or copy this email. Please notify the sender immediately and delete this email from your system. Please also note that any opinions presented in this email are solely those of the author and do not necessarily represent those of The AXA UK Plc Group. Email transmission cannot be guaranteed to be secure, or error free as information could be intercepted, corrupted, lost, destroyed, late in arriving or incomplete as a result of the transmission process. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of email transmission. Finally, the recipient should check this email and any attachments for viruses. The AXA UK Plc Group accept no liability for any damage caused by any virus transmitted by this email. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Matt Redmond wrote : > >> As someone else has mentioned, the baud rate is > >> irrelevant, the above problem is just as bad at 300 > >> baud and 19200 baud > > Why would that be? Aren't serial bitwidths wider at lower > speeds? Just curious - trying to get an educashun. Yes they are, but the rellative error (in %) is just the same. (bit width vs. bit/baud clock error) Think about it, if you have a 1 meter measuring-tape with an (known) error of 5% (so it's actualy 1.05 meters long), you will still get an error of 5% even when measuring 10, 100 or 1000 meters. In the same way, the *absolute* error in the baudrate clock will add up and give the same *rellative* error at all baud rates. It's a whole other thing if you have "jitter" in the baud rate clock. Jitter tend to even out over time, so in that case lower baud rates might be "better" then higher. But here we are talking about a fixed, stable error in the buad rate clock. Jan-Erik. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

> >> As someone else has mentioned, the baud rate is irrelevant, the above > problem is just as bad at 300 baud and 19200 baud<< > > Why would that be? Aren't serial bitwidths wider at lower speeds? Just > curious - trying to get an educashun. Each bit is a certain percentage of the total frame period. The timing is synchronised by the start of the start bit and then must stay in sync for one data word. At any data rate, if you move more than a certain percentage of word length from the centre of a bit then you cross a bit edge. In one direction you sample the bit before the one you ought and in the other direction you sample the bit after the one you ought. In either case the error is ABOUT 5%. This applies at whatever speed you are working. eg with an N81 data signal there is 1 start bit, 8 data bits and 1 stop bit. Assume the transmitter is perfect and the receiver clock is fast. The receiver will sample each bit progressively earlier. The timing starts at the start of the start bit (say that 10 times rapidly) and ends when the stop bit is sampled. This period OUGHT to be 1 + 8 + 1/2 = 9.5 bits from the start of start to the middle of stop. The fastest sampling allowed is if the stop sample JUST is inside the stop bit rather than inside the preceding data bit. This is 9 bit times from the start of start. The clock would be running 9.5/9 = 1.0555r or 5.56% fast for this to happen, regardless of baud rate. If you ASSUME the stop bit is correct and only worry about sampling the data bits then you can be 8.5/8 = 6.25% fast. Student is left to work out how slow you can be. Note that this 5 % or 6 % error can be spread between transmit and receive. IF they both drift the same way with eg temperature the result MAY be better than if one end is crystal controlled. This depends on drift matching and on similar temperature environments at each end. As a general rule, if one end is crystal controlled then you can allow about 5%clock error at the other end before bit errors occur. YMMV. RM -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

Thanks Robin & Jan-Erik, that clears it up. I guess I was thinking about "jitter". I can see how a fixed error might work for a very short time, then the data gets so shifted in time that it's unreadable. Makes sense. Thanks again, -matt Matt Redmond wrote : > >> As someone else has mentioned, the baud rate is > >> irrelevant, the above problem is just as bad at 300 > >> baud and 19200 baud > > Why would that be? Aren't serial bitwidths wider at lower > speeds? Just curious - trying to get an educashun. Yes they are, but the rellative error (in %) is just the same. (bit width vs. bit/baud clock error) Think about it, if you have a 1 meter measuring-tape with an (known) error of 5% (so it's actualy 1.05 meters long), you will still get an error of 5% even when measuring 10, 100 or 1000 meters. In the same way, the *absolute* error in the baudrate clock will add up and give the same *rellative* error at all baud rates. It's a whole other thing if you have "jitter" in the baud rate clock. Jitter tend to even out over time, so in that case lower baud rates might be "better" then higher. But here we are talking about a fixed, stable error in the buad rate clock. Jan-Erik. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

On Tue, 24 Aug 2004 14:20:19 +0100, Nigel Orr <spam_OUTnigelTakeThisOuTAXONINSTRUMENTS.CO.UK> wrote: > A serial byte is about 10 bits long (including start bits etc), and is > usually sampled at the receiving end in the middle of each bit. > Therefore, > if the timing slips by more than 1/2 bit width during 10 bits, there will > be errors. That's an error of 0.5/10 or 5%. If you assume that is > shared > across both transmitter and receiver, they are allowed 2.5% each, but it > would be better to keep it under 1%. The 628A internal clock (IIRC) is > about 3-4% Over 0-85 degrees, the max jitter is 2%. {Quote hidden}> > The real life answer comes about because: > 1) when I have used them for this purpose, I haven't needed them to be > functional over a wide temperature or supply voltage range, > 2) the typical accuracy is better than the worst case quoted in the > datasheet > 3) I don't usually have a PIC at each end, the PC end is probably a > crystal, with accuracy better than 0.1% so the PIC can get away with a > larger clock error > > If you can test each part across the full expected range, and afford to > throw away some PICs, it might be worth a risk for a small controlled > production run, but that's what you have to figure out- I wouldn't try it > personally! We're talking about at most 10 units, which will all be used at standard office temperatures. The data source is an inclinometer, whose circuit details I'm not privy to. The actual unit generates one of 16 contact closures based on the radius and angle of the tilt sensor. It's a redesign of a bunch (too many) of one-offs I did with a Basic Stamp II (it's essentially a joystick controlled by an individual balancing on a board). The inclinometer generates a continuous data stream, which is read when convenient; occasional misreadings won't cause critical problems. > As someone else has mentioned, the baud rate is irrelevant, the above > problem is just as bad at 300 baud and 19200 baud Well, there's also the relationship of the clock to the divisor to take into account; at the nominal clock (4MHZ) truncating the divisor to an integer introduces only a 0.16% error at 9600, but at other rates it could be more. It looks like if I go with the internal oscillator, the rate will range from 9423 (-1.8%) to 9808 (+2.2%) with a nominal of 9615 (+0.16%). The CPU will be a socketed DIP, so I can swap parts if necessary. -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

On Tue, Aug 24, 2004 at 12:58:18AM -0500, Eric Bohlman wrote: > In members' experience, can the 16f628A (which claims to have a precision > internal oscillator) adequately handle 9600bps reception when using the > 4MHZ internal oscillator? I have a design where freeing up two pins would > be extremely helpful, so would like to avoid a crystal or resonator. I saw the rest of the discussion, There is a critical piece of information missing: are you planning on using the hardware USART or bit banging the interface? It can be done if you bit bang the interface because you can actually track the drift by looking for the edges of the cells as they are transmitted to you. So you can adjust your delays dynamically while the application runs. Now of course if you use the hardware USART, then the bit rate generator is tied directly to the oscillator. If there was some way to detect the drift you could nudge the divider for the BRG up or down a bit. It would be even better if you could build a protocol around the concept. Caller ID uses the concept by sending a string of U's as a header for the CID packet. U's ASCII code is 55 hex which means the bit pattern on the line including the start and stop bits is 0101010101 which is easy to pick out the width of a bit cell. So if I had control over the protocol this is what I'd do: 1) Have the host controller send U's as a resync packet. This will give the 628 a chance to get it's clock right. These can be bit banged received and then the BRG adjusted to match the incoming clock to the current oscillator. 2) Then fire up the hardware USART and start communicating, keeping track of both the frame error and packet checksums. As long as no errors occur, keep ACKing incoming packets. 3) When a error occurs, then NAK the packet, which forces the sending of a resync packet, going back to step 1. This could track drift in some pretty poor conditions I think. BAJ -- http://www.piclist.com hint: PICList Posts must start with ONE topic: [PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

(Not directly related to the F628A, but anyway...) What Byron describes below, is more or less what's built in in those PIC with the "Enhanced USART". Those have something called "ABD" or "Auto Baud Rate Detect". The "other side" must send a "U" (h'55') which is used to calculate the correct value for the BRG register. Another nice feature of these PICs are that the Baud Rate Register is 16 bits (instead of 8 bits), so you can get very low baud rate errors at a wide range of combinations of Fosc and baud rate. Regards, Jan-Erik. Byron A Jeff wrote : {Quote hidden}> It would be even better if you could build a protocol around > the concept. > Caller ID uses the concept by sending a string of U's as a > header for the CID packet. U's ASCII code is 55 hex which > means the bit pattern on the line including the start and stop > bits is 0101010101 which is easy to pick out the width of a > bit cell. So if I had control over the protocol this is what I'd > do: > > 1) Have the host controller send U's as a resync packet. This > will give the > 628 a chance to get it's clock right. These can be bit banged > received and > then the BRG adjusted to match the incoming clock to the > current oscillator. > > 2) Then fire up the hardware USART and start communicating, > keeping track of > both the frame error and packet checksums. As long as no > errors occur, keep > ACKing incoming packets. > > 3) When a error occurs, then NAK the packet, which forces the > sending of a > resync packet, going back to step 1. > > This could track drift in some pretty poor conditions I think. > > BAJ -- http://www.piclist.com hint: The list server can filter out subtopics (like ads or off topics) for you. See http://www.piclist.com/#topics