What is the best c complier for the Pic18 micro

Question

We are starting a new project based a microchip PIC18F252. What is the best 'c' compiler to use?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

1. Microchip C18 compiler: really the best and easiest to use. Perfect for professional use.
2. HI-TECH: Used when Microchip does not work (it was for a PIC16).
3. CCS
4. 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.

Answer 5

Does anyone have any experience with latest version of the HI-TECH PICC-18 PRO v9.61 compiler?

Answer 6

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.

Answer 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.

Answer 8

use sdcc:

http://sdcc.sourceforge.net/

HTH

Answer 9

Hi-tech PICC has always been reliable for me and it has had many years of development.

Answer 10

IAR System has a PIC18 compiler/IDE: IAR Embedded Workbench for PIC18.

Answer 11

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.

1. You have to specify which ram bank to allocate variables to.
2. In order to have const string be allocated to Program space (instead of ram) you have to use the rom keyword.
3. 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.

Answer 12

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

Answer 13

MPLAB C18 - Student

Answer 14

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?