On Tue, 2007-10-16 at 08:09 -0500, fred jones wrote: > > On 10/16/07, Vitaliy wrote:> So I'm wondering if people can share their experiences using third party> compilers for the PIC18: SDCC, CCS, HI-TECH, CC8E, BoostC, mikroC,> IAR (any others I've missed?) > > I would imagine what is important to you would be a deciding factor in choosing a compiler. I liked the large library of routines that MikroC offers (as well as their other compilers) as well as the hardware development tools they have available. All the hardware products have routines available for them as well. Since I don't make my living with PICs, I couldn't justify a large price tag. Since I bought some development boards, the compiler with no limitations, was only $149. They have a forum with wonderful support. As for memory, it is probably not the most efficient but cost and huge library were more important for me. > Good luck Hehe, it's funny how different opinions can be! Personally, libraries (beyond the basic standard stuff, i.e. strcat) mean almost nothing to me, especially peripheral libraries. There's always something I find out not liking about built in libraries. Peripheral libraries always do things in ways I don't like, they either get too complicated to use (i.e. requiring weird structures to init them) or they don't give enough info in what exactly they are doing (i.e. the definitions of clock polarity and edge for SPI control differs depending on who wrote the library). I've often spent more time trying to figure out how to properly configure and use a peripheral library then it would have taken for me to read the datasheet and write my own routines. Even worse is some of the errors/bugs I've encountered in peripheral libraries. As a result, I don't even bother with built in peripheral libraries anymore. As for "standard libraries", beyond the simplest members, I use them as rarely as possible. The biggest issues here are bloat. One call to say printf results in HUGE amount of code space being added, because printf supports SO many different ways of doing things. Sometimes I can afford the bloat, oftentimes I can't. As a result I just write my own simpler routines that mimic the simpler functions of printf (i.e. "prints" which just prints a string, no formatting, "printhex" which prints a number in hex, etc.). Portability is always maintained for my "standard library" substitutions since I always wrap things in a way that I just change one minor function to accommodate a different platform. For example, all my "print" functions use putchar to do the actual output. putchar just calls the appropriate peripheral function, so if I want to change serial ports (or change to outputting to an LCD), I just change the call in putchar and all my print functions remains the same. Perhaps the current crop of compilers have cleaned up all the issues that annoyed me in the past, making what I do now pointless, but so be it! :) TTYL -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist