9

As I mentioned, I have just beginned programming pic16f877a. I can now work with 7 segment displays. At present I am using ccs compiler. Nothing wrong with that. But i prefer to be a compiler independent programmer. So i simultaneously want to work in other compilers like IAR or Hitechc. I want to know whether the "program statement declaration in compilers" other than ccs will be different? Please guide me how to approach this thing. I would welcome all forms of suggestions. Thanks in advance.

tyblu
  • 8,167
  • 6
  • 40
  • 70
V V Rao
  • 1,136
  • 3
  • 19
  • 32

5 Answers5

9

That great that you want to be compiler independent! Unfortunately hitech and CCS compilers for the low end PICs use a lot of compiler specific preprocessor declarations, compiler specific pin access routines, and in the case of CCS compiler specific routines for access core functions such as SPI, I2C, ADC and so on.

It is not possible to write your code to be non-compiler specific without a lot of preprocessor #define, #ifdef, #ifndef and so on to get access to specific parts of what each compiler has on offer. This would make your code unreadable.

The best thing you could aim for is to be IDE independent and use something like eclipse, so at least you are using the same IDE. This will result in losing CCS wizards for setting up core functions, but will give you greater flexibility in using the same IDE.

Another thing to consider is that both hitech and CCS do not have (at least in the past) a true c compiler linker and required you to use "#include myfile.c" which I personally despise ... but that is another story.

I have not commented on the IAR compiler as I have only used CCS and hitech. Both worked ok, but I was never really happy with either after migrating across from the Motorola (now freescale) platform and using the metroworks compiler which was more advanced at the time. The IAR compiler looks good but I have never used it.

smashtastic
  • 3,336
  • 21
  • 31
  • If you can handle staying at or above pic18 then you should take a look at the c18 compiler. It has a large amount of support. IAR is dropping PIC support, they will no longer sell licenses with maintenance. – Kortuk Nov 01 '10 at 14:58
  • It's been my understanding that the PIC16/12/10 architecture does not map very well to the C language. Therefore, the C compilers have to have some unusual & non-standard structures to compensate for the PIC architecture. The end result is none of the compilers interoperate. – Connor Wolf Jul 04 '11 at 08:05
7

If you were using PIC18 parts I would recommend C18 compiler from Microchip. It conforms much more closely to ANSI C than the CCS compiler. I'm not sure about the Hi-Tech compiler since I have not used it. As was said earlier if you really need to make compiler independent code you will need to use lots of pre-compiler directives. I'd recommend taking a look at some of the Microchip example programs that support multiple compilers to get an idea of how it is done.

mjh2007
  • 3,899
  • 24
  • 49
  • c18 for pic18, c30 for pic24 and dspic, c32 for pic32! – Kortuk Nov 01 '10 at 14:58
  • CCS is nice in that certain things are simpler to do (interrupts and timers, for example - all the Microchip examples have you write ASM to get interrupts to work right in C18), but it is closer to ANSI C. – J. Polfer Nov 01 '10 at 15:49
  • You only need one assembly instruction and that is the GOTO that is used to setup the interrupt vector to point to the interrupt service routine. – mjh2007 Nov 01 '10 at 18:50
3

Unfortunately you will find it is very difficult to find a compiler independent program for a microcontroller. There are several problems, here are just two:

  1. Differences in peripherals, SFR naming, etc (especially over other processors, but even with compilers from the same family), and;

  2. Non-standard features on some compilers like setting bits individually or different structures for invoking assembly code.

The 16F series is very limited in terms of architecture and not really designed to support a C compiler. That is why there is no GCC for it.

Thomas O
  • 31,546
  • 57
  • 182
  • 320
3

Take a look at SDCC. It supports many of the PIC16 and PIC18 devices. GCC supports PIC24 and dsPIC.

Toby Jaffey
  • 28,796
  • 19
  • 96
  • 150
  • i asked about the differences in statements while using different compilers.. anyways i came to know about 1 more compiler 'sdcc'.. thanks a lot.. – V V Rao Oct 20 '10 at 04:07
2

The most likely aspects to be compiler-dependent are:

  • using single bits (especially in IO ports)
  • sizes of integers, and char being signed or unsigned
  • funny pointers: C18 differentiates rom and ram pointers :(
  • configuration fuses
  • busy waiting

My preferred way to handle this is to write macros for these aspects, and have the compiler select the correct macro based on compiler-specific predefined macros. I made an RFM70 library and example applications this way that run on PIC14 (HiTechC), PIC16 (C18) and ARM (GCC).

(update) My RFM70 library is now complete. It supports C on PIC 16F (Hitech compiler), C and C++ on LPC11114 (Cortex) and LPC2148 (ARM7TDMI) (GCC compiler) and Arduino (ATMega128, GCC compiler). This is generated (including doxygen documentation) from the same source by doing some preprocessing in a Python script. Jal support is under development, maybe ProtonBasic will follow. http://www.voti.nl/rfm70

Wouter van Ooijen
  • 48,407
  • 1
  • 63
  • 136