Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
We are starting a new project based a microchip PIC18F252. What is the best 'c' compiler to use?
tech PICC has always been reliable for me and it has had many years of development.
PS: I myself worked on the PIC18F25XX and PIC18F45xx family, so I know a tiny bit about this. ;)
PS2: In case of compiler bug (it happened to us), the Microchip team is quite reactive and new versions are released quite quickly. Try to find a local reseller who has contact with Microchip, then participate to a event with them and get direct contacts. Invaluable.
I did extensive research on the Hitech PICC18 compiler and the Microchip C18 compiler a few years ago.
I think most people that decide to go with Microchip C18 compiler only because they see it when they go to the microchip website and are already familiar with MpLab from doing assembly (which is a terrible IDE IMHO).
HiTech's solution is much closer to ANSI C (hence code is much more portable). With C18 you have add all kinds of compiler specific keywords and your forced to manage memory much more.
An excellent comparison which goes way more in depth can be found here: http://www.xargs.com/pic/picc18-vs-c18.html
Besides from the compiler you also need to take into consideration the IDE. I am an avid eclipse fan and so I really liked HiTech's HiTide for this reason. However, since Microchip has purchased HiTech... it seems that they are no longer supporting HiTide. I don't think this is official... but from my experience with HiTech support... they aren't fixing bugs anymore which is a real shame.
I've also tried their pro compilers. I really like the idea. But, my project exceeded the auto param block requirements and was unable to use it. It also seemed to take a verrrryyy long to compile but it could have been b/c of the program complexity.
I've not used the Microchip compiler, but have been using HiTech's products for years. I've generally liked their PIC16 compiler, but find their PIC18 compiler rather frustrating. While I appreciate not having to hand-place all variables into banks, the rules used by HiTech's compiler are annoying, bizarre, and goofy. Brief background: the chip has 16 256-byte banks of variables (*not all 256 bytes are available in all banks) and one bank pointer. Direct access to a variable requires that the proper bank be selected; changing banks takes one instruction.
Global and static ints and structs, and arrays thereof, whose size ranges from 2-255 bytes will each be allocated into psects on a per-module basis; each module's psect must fit in a 256-byte page. Arrays of bytes, as well as individual bytes, go in a "big" psect where every byte is assumed to possibly reside in a different page.
All automatic variables and parameters throughout the program must fit in a 256-byte page (they are allocated statically at link time). The linker does overlay variables which are never live simultaneously, but it assumes any call to a function pointer with a particular signature can call any function whose address is taken and which has that signature.
It is possible to declare up to 128 bytes' worth of global and static variables to be 'near'. These can be accessed without bank-switching. It is not possible to designate that automatic variables or parameters be placed 'near'.
The bank-switching rules used by HiTech mean that many functions, even if they never use any variables outside their own module, will be sprinkled with movlb (switch-bank) instructions.
I don't want "omniscient code generation". I want the ability to add a few hints to place things sensibly by defining keywords or macros for custom psects, allowing automatic and local variables to share psects with other variables (overlaying auto variables/parameters to the extent possible given the specified banking restrictions). If a compiler vendor really wants to be nice, allow pointers to accept bank qualifiers, so that a pointer which would only ever point to things in a certain psect could be stored in 8 bits. Likewise, allow bank qualifiers on functions and function pointers to specify that certain indirect calls can only work with certain functions. Rather than making function pointers 24 bits or having to work to ensure indirect-called functions end up in the first 64K, put an automatic GOTO in the first 64K so function pointers can be 16-bits. Or better yet, if a function 'class' has fewer than 64 different functions, use an 8-bit pointer.
Am I asking too much?
We use CCS and it's pretty good. Very slow, but it works well. Anyway, I don't have any comparison with other compilers, so there might be better choices.
I didn't like CCS, it was too quirky.
SourceBoost is not bad and pretty cheap, about £40.
The Microchip C18 compiler is the best IMO, but very expensive. There is a free demo / student edition, though.
I currently use CCS and hate it. It is so non-standard and so much of a subset of C, that it just sucks. I'm considering switching shortly. I'm going to try Microchip C18 compiler first and then I'll swallow hard and get HighTech which seems pretty solid from reviewing the trial version and samples.
IAR System has a PIC18 compiler/IDE: IAR Embedded Workbench for PIC18.
I have been using CCS for many years. I have found a few bugs but there support is great and I can develop quicker and easier with CCS than with C18 or HiTec
use sdcc:
http://sdcc.sourceforge.net/
and for non-free(but free!) PIC-compiler, mikroC is gr8!
http://www.mikroe.com/eng/products/view/7/mikroc-pro-for-pic/
HTH
I would insist that you use the C18 compiler. It is extremely robust and very easy to use. It's a must have for professional development. It really depends on the size of the project you are working on.
Start with the free/student edition and you'll get a good feel for using it. If your project is small, that may be all you need. I just finished a large-ish size dev project on a PIC 18F and I was extremely satisfied with the C18 compiler.
MPLAB C18 - Student
I have been using SourceBoost for a year or so, and I'm not totally thrilled, but it's been fine. However, I just completed a code-size test between SourceBoost 7, MCC18, and Hi-Tech C. The results were remarkable.
For a small sample program (that incuded structures, arrays, function pointers, structure pointers, chars and ints) the SB7 kit produced code that was about 2/3 the size of MCC18 and HTC. I wanted to detemine how much of that was startup and run-time overhead, so I added more random stuff to the sample program, and the size delta showed that SB was still 2/3 the size of the others. HTC was slightly smaller than MCC18, but not significantly. All optimizations are on in all environments.
The things that I don't like about SB are:
The things that I like about it are:
Since I don't like the SB IDE, I use Source Insight for an editor and it ROCKS! The SB "make" utility is hopeless as well, so I use GnuWin32 make, which is absolutely the real deal, and free.
So all in all I'm feeling quite a bit better about my choice of tools.
Anyway, hope this helps someone out there.
MPLAB C-18 is nice, and they have a student version that is free. It has a good user interface that is simple enough that it doesn't confuse users. It is what I use.
If you can get away with it (my preference would be to) use the PIC18 Assembler with MPLAB. It has the advantage of being free and relativly well documented alongside the fact that it has decent hardwars / debugger support. Its small instruction set and simplicity led itself to easy and quick coding.
If you're set on c though:
CCS is a good compiler to use, a bit buggy and quite expensive but also has good debugging capabilities.
Microsoft Embedded Studio (or something like that) is excellent if you're already used to the Visual Studio 6 methodology of writing c code. Again good hardware support and excellent debugger.
I believe that if youre looking for a free solution you can indeed get c compilers for MPLAB, although Ive personally never used any so I can't pass judgement.
