Olin Lathrop wrote:

> Because then you still just end up with hard coded constants in your code,
> even if they are more likely to be right.

Hi Olin,

No problem here, I totally agree with you and others regarding the point of
having the assembler or the C compiler generate the value for SPBRG. It's
definitely a method of "working smarter" vs "working harder".

I remember seeing some posts indicating there were errors in the data
sheets, and references to "use the formula" etc. I was envisioning people
getting out their calculators and manually going through iterations of SPBRG
calculations.
Why? Because I used to do that of course! :)

Even though I'm guilty of it myself, I wasn't advocating using hard-coded
SPBRG constants in the source code, but rather I was advocating using the
spreadsheet as a tool for what it does best -- quick, *multiple*
calculations, and "what if I change Fosc" scenarios.

A lot of times I have a pool of crystals to choose from and I want to
quickly see if they produce standard 0% error baud rates or not. Or when
dealing with the MSSP, I want to see what I2C clock frequencies are
available to me with a certain crystal frequency. These are prime examples
where having a spreadsheet puts all the info in front of your face quickly
and greatly aids in design decisions.

Best regards,

Ken Pergola

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads