Wouter van Ooijen wrote:
>> I have used C18 and I agree with the quality of code it produces.
>
> C18 is IMHO one of the worst C implementations I have ever seen in
> terms of code density and quality of the PIC libraries provided with
> it.

You're right, I should have qualified that more.  What I meant by "quality"
was that the code seems to work.  In other words, the machine code does wha=
t
the high level source code defines.  However, I did not mean to say the cod=
e
is well optimized or particularly clever.

As for quality of the libraries, I wouldn't know since I have never
deliberately used any library routines.  Peripheral use is different enough
from one project to another that no reasonable runtime configuration can
exist.  Providing them is only a illusion for the incompetent, not of any
real use in real projects.

The UART is one exception to this.  It is possible to have largely canned
UART handling code that can be used accross projects with little
modification.  However, even with this you rarely need runtime setup
choices.  For example, the baud rate for most projects is fixed as defined
in the protocol spec.  Passing it as a runtime parameter is silly, since th=
e
machine then has to do a bunch of calculations, and drag in the associated
math routines, to determine the baud rate setup.  This is best done at buil=
d
time on the host, with the baud rate setup being constants at run time.

My UART_BAUD macro, for example, does this computation at build time given
the desired baud rate and the instruction clock frequency.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
--=20
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.