Or include a clock calibration routine to be run when you initially test the thing? RP Well, worst case I posted just now in another reply... But, I was thinking... If i leave a byte in the eeprom like a calibration-byte. Then Read this and have a little extra-loop in my main delay-routine that uses it, maby I can repair any cards that turn out to be sour ? Or. why not simply test chips before we let the boardhouse mount them ? Not too hard to kick in a config word and a loop on the first program-line of the chip? Then measure clkout... Besides... If half the cards turn out to be lemons, we are still OK financially! The cards are so cheap to produce, compared to the market-price of the product, that a doubling won't even be noticed! The problem is size and complexity. As long as I can maintain a certain enormous track-width and single-sided layout we get the cards produced for almost nothing. Kyrre ----- Original Message ----- From: "Sean Alcorn - PIC Stuff" To: Sent: Friday, November 08, 2002 2:57 AM Subject: Re: [PIC]: How is the stability of the 16F628's internaloscillator ? > Kyrre, > > > It's not as much cutting production cost, as it is board space / > > layout... > > Because of some restraints I can only use single sided... This is what > > makes the layout a challenge. > > What is the application? What will happen at the worst case ends of the > Microchip published clock accuracy? > > For some reason, I can not see the beginning of this thread. Sorry. :-( > > Regards, > > Sean > > -- > http://www.piclist.com hint: To leave the PICList > mailto:piclist-unsubscribe-request@mitvma.mit.edu > > > -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu -- http://www.piclist.com hint: To leave the PICList mailto:piclist-unsubscribe-request@mitvma.mit.edu