问题
We are starting a new project based a microchip PIC18F252. What is the best 'c' compiler to use?
回答1:
tech PICC has always been reliable for me and it has had many years of development.
回答2:
- Microchip C18 compiler: really the best and easiest to use. Perfect for professional use.
- HI-TECH: Used when Microchip does not work (it was for a PIC16).
- CCS
- SourceBoost
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.
回答3:
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.
- You have to specify which ram bank to allocate variables to.
- In order to have const string be allocated to Program space (instead of ram) you have to use the rom keyword.
- You cannot allocate variables which are larger then 256 bytes without editing a linker script.
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.
回答4:
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?
回答5:
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.
回答6:
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.
回答7:
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.
回答8:
IAR System has a PIC18 compiler/IDE: IAR Embedded Workbench for PIC18.
回答9:
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
回答10:
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
回答11:
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.
回答12:
MPLAB C18 - Student
回答13:
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:
- limited in-line assembler
- slow to compile & link
- The IDE is only slightly better than MPLAB.
The things that I like about it are:
- Well, the code size sure seems smaller than the competition.
- A few extensions to the language (e.g. references). Kills portability, though.
- The price.
- Support via the forums is actually pretty good. The authors often post.
- Automatic elimination of unused code (I think this feature slows down the compile and link)
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.
回答14:
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.
回答15:
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.
来源：https://stackoverflow.com/questions/93356/what-is-the-best-c-compiler-for-the-pic18-micro