CCS & MikroC Compiler Comparison

[carlao]

I'm starting in C language to PIC (during 5 years I had used PICBASIC...). For a while, I'm testing MikroC, as it is easier to start.
In few days I hope have some impressions of that.

[M.yasser]

Hi,
Two points are important to be considered; one is code optimization for speed and code optimization for size.
I haven’t tried MikroC yet. If we could code a program and test it with both compilers focusing on speed and size; we may make a good conclusion.
I have ccs v4.120, if someone is interested.
Regards.

[mrpicing]

M.Yasser is write. Code and speed are most important factors of compilers.
I used CCS and i like it due to its baked libs. I also tried many other compilers.

My friend found a fatal mistake in MikroC LCD Libs and after efforts of many day he gave up and switched to CCS.

For biggeners its doesnt matter how much code size and how slow is the speed. but after some time when you dive in the field, then you need to consider these matters.

[glenjoy]

mikroC coff file does not work with proteus.

[LithiumOverdosE]

It is rather the other way around. Proteus doesn't work with some compilers COFF files. I know that users of some other compilers are also complaining of incompatibilities with Proteus.

[alichan]

Hi,
Two points are important to be considered; one is code optimization for speed and code optimization for size.
I haven’t tried MikroC yet. If we could code a program and test it with both compilers focusing on speed and size; we may make a good conclusion.
I have ccs v4.120, if someone is interested.
Regards.

If you have it, upload and share with all the people

[odsk]

My small comparison of both compilers:

I- Mikroc has a big issue when it comes to PIC16 ram, it does not use all of it or you have to manipulate IRP bits on your own. That is a big disadvantage for me,
II- The code is bulkier.

III- CCS I don't have experience with it, but I wanted to write some code with it and I had to define the bits , registers example T0IE or flag is not defined!!!!!!!!!!! even though the processor header file is included in the project.
IV- But it does use maximum RAM.

This is my experience with both compilers anyway.
Regards,
ODSK

[gan_canny]

CCS does most of the work for you. You don't have to get very PIC specific since the header for the specific chip and a CCS compiler dat file do almost all of it for you. CCS has the SPI I2C and RS232 interfaces wrapped in CCS functions plus the interrupts are wrapped as well. It produces very tight code and has compiler instructions to map the code space to make writing bootloaders much easier. It has standard printf with streams and print to a string but you can also printf to a user defined function... the function is called once for every char the printf creates. CCS does rapid versioning the plus is you can get a quick bug fix the downside it is not exhaustively tested. Many like this style and keep an earlier more trusted version as well. It beats waiting several months for a new release. Several CCS compiler versions can be kept on a PC. The CCS debugger is excellent and the CCS programmer/debugger  is more convenient to use than the Microchip ICD versions.

[Magnox]

I tend to agree with gan_canny. I've used CCS for a good few years and bought the ICD-U40 programmer/debugger as soon as it was released.

That was a mistake as they subsequently brought out a revised hardware version of the U40 that mine could not take the firmware for, so I lost support for many of the later PIC's. I've just solved that though by modifying the board in mine to the later version thanks to finding the circuit diagram for it.

I find it more convenient to use CCS and their ICD-U40 for programming and debugging than the PICKit 3, which I only bought because the U40 doesn't support the latest devices any more. The PICKit annoys me with the firmware loading every time I change PIC's.

The bug issue is a big one with CCS due to the seeming lack of testing. I've been hit a few times after upgrading but, as gan_canny said, older versions can be kept. That's good practice with any software anyway.

There are some issues with the project wizard, where it doesn't create the correct entries for the options selected. For instance, it gets the serial port settings wrong in some cases, sets the defines for the delay functions wrong if using the PLL on the 18F4550, and generates the wrong defined pin names for the LCD option so that it does not work until you find out what the LCD.C code really expects.

Despite all that, I still use it out of choice if the PIC I'm using is supported (and most of the ones I use are).

[vantusaonho]

I vote for MikroC. Easy to use, there are many libraries. You also program with register easily

[lguancho]

I have been using CCS C compiler for some years.  Very short learning curve  for a RF designer.  I use it to control complex IC such as DDS and PLL.  The built-in functions such as software SPI is flexible and can basically configure and GPIO ports as the SPI channel.

The CCS C forum is another great place to connect with the other experienced programmer.  Give it a try!!

 

[zab]

Has some one tried to compare CCS and MicroC with microchip new XC compilers? If yes what the results were.

[gan_canny]

Over the last 15 years the CCS forum has been an excellent source of information. Since Proteus added CCS support it has degraded the CCS forum. Proteus allows some to just throw code at the wall to see if it will stick. It maybe many don't even own a real PIC chip.  Often times with Proteus code does stick except it produces unexpected results. This drives those who are adverse to reading microchip data sheets or even learning a small amount of C syntax to the CCS forum with questions. Like why does "if (x=1) x=2;" not work. Or why can't I use . period instead of ; to end lines of C code. These kindergarten questions about microchip and C are driving engineers away from the CCS forum board. Recently the CCS forum no longer accepts Proteus questions. Further Google creates for a few an expectation of a no effort on your part answer...a bit like asking the teacher to do your homework. It is causing some assistance boards to control membership to invitation only in order to avoid the dilution of expertise by in-expertise.
A C compiler is a C compiler..in that way they all will convert C code to machine code. The choice is then efficiency and functionality. CCS is efficient and it has a great many built in functions tailored to the PIC hardware and Interrupt vectors. CCS has a very extensive library of coded examples.

[LithiumOverdosE]

Has some one tried to compare CCS and MicroC with microchip new XC compilers? If yes what the results were.

First of all CCS is not ANSI C compiler and it really cannot be directly compared to MikroC or XC8.


I use both XC8 and MikroC and my conclusions are as following (just a few thoughts not ordered in any logical manner):

1. MikroC has many ready to use libraries which you would otherwise have to adapt yourself in case of XC8 (USB, TCP/IP, FAT16, FAT32) first comes to mind.
2. Microchip libs very often require modifications since they were mostly written for C18 and not XC8 (which is based on HiTech PICC). It is the state of the affairs at the moment.
3. Most time with both compilers I had to write my own libs in order to support and tweak advanced features. However, XC8 provide you with the libs source files which makes things much easier if you just want to modify existing library.
4. Both languages are ANSI C compliant although at certain times it seems MikroC is closer to the standard.
5. In many cases XC8 produces smaller and faster code (with optimisations turned on in Pro mode). I haven't really checked generated assembly code because I simply don't have time to play with low level programming but my guess is that XC8 simply have better optimisations implemented.
6. Contrary to many users I really like MPLAB X IDE and haven't had any real problems with it.
7. MikroC IDE doesn't normally support PicKit2/3 which is a big disadvantage in my case.
8. Although XC8 produce smaller and more optimised code I just recently found a bug with basic arithmetic operations. I never had any such problems with MikroC. Perhaps it's just my misfortune but it's very annoying when something like that happens. Especially when you're half way through with a bigger project. Damn. But in all honesty I just recently found a bug in the simples for loop in MikroC so it seems it's not immune to basic problems as well.
9. MikroC has a comprehensive help file with context support. With XC8 I was few times forced to look for clarifications on Microchip forums regarding hardware libs and had to dig through the source code to better understand of how they work.
10. XC8 still has limited educational internet resources available while for the MikroC there is a quite stable and forthcoming on-line community. That's a good thing especially for beginners.
11. MikroC has advantage that they have a single compiler to cover all PIC and AVR families with virtually same syntax and libraries. With Microchip compilers one has to switch between XC8, XC16 and XC32 and they have different syntax and libs. Crappy thing if you want to quickly port your code from one family of MCU to another.
12. If you want to use it for commercial projects XC8 is MUCH more expensive than MikroC and have time limited support.

All being said nowadays I use exclusively XC8 for any kind of serious work together with Proteus and PicKit 3 for debugging. However I do keep MikroC installed for reference and for simple quick projects in which I can use their ready hardware libraries. I suspect that over the time XC8 will become more stable (it's still a Frankenstein monster combination of PICC and partially C18). Also, I'm yet to see a complex, commercial project done in MikroC because most developers have problems with MikroC very slow support and release of fixes and of course their hardware libs are inaccessible so that represent a significant problem as well.

I did try CCS but it deviates so much from ANSI C that I simply didn't want to waste time getting used to it and in the end ending up with the not so easily portable C(?) code. Yes it has a selection of good libs and they provided source for them but as I've said I personally am annoyed with their deviation from standard. Also, their IDE sucks big time compared to MikroC IDE and MPLAB X.

At least that's my experience. ;-)
 

[LithiumOverdosE]

For some reason I read that comparison is between CCS, MikroC and XC8. I guess my mind is playing a trick with me. 

If one only compares CCS and MikroC then the answer is simple. MikroC is ANSI C compliant (standardised and rather portable code). CCS is not ANSI C compliant (proprietary and less portable code).

My vote goes for MikroC for the reasons I mentioned above + MC has better help + much better IDE.

[metal]

I find it really difficult to port codes written with CCS and even PICC to other compilers. They both don't follow bit manipulation in C.

You can't set GIE bit inside INTCON register like this:

Code:

INTCON |= (1<<GIE);

This is because of the GIE definition itself, which directly accesses the bit itself, rather than defining GIE as being a constant i.e. 7. As a result, I must use:

Code:

GIE = 1

which is also a stupid thing to do, header files in PICC and XC8 are more prone to errors now. I find it really silly this way. I have recently tried BoostC, and it really works fine and optimizes excellent, it is very close to PICC and XC8 code size. But BoostC defines register names in header files using lowercase which is also another stupid step! It sounds like every compiler is racing towards being more stupid in one aspect or another

CCS is another story, and I don't even see it as a C compiler, sometimes I feel it is perl with many libs installed! Why do I have to read the manual to understand these embedded silly functions!? I don't know why I have to see every strange thing only in PIC compilers!!?? Other compilers try to unify writing the codes, so I follow true C while working, except in PIC, which really slows the development process.

[mario2000]

From my experience using mikroC, I can say that is a good compiler so easy to use, but to try to do more complex code, starts to have problems, even when it has been used only 50% of the memory, for example, when increases code tends to run out of RAM, it also occurs when the code is fairly large stops working in the micro. Instead ccs is much better in those areas, but requires more learning time.

[metal]

you need more time on drivers ; )

[LithiumOverdosE]

@metal

Interestingly enough I haven't had any time porting any of my code between PICC, XC8 and MikroC.  IMO it's because I try to stick to standard C syntax as much as possible. I also very rarely use hardware libs in any compiler as I like to write my own customised ones. Although from time to time I did modify existing libs or turned to their source to get some clue as how to solve some of my own particular problems. Which is of course impossible in MikroC with their compiled libraries.

As for the BoostC I experienced tremendously long compilation times. Also their IDE sucks big time (like CCS). Sorry, but slow compilation time and comparatively small knowledge base is a big minus for me.

And of course with MC pushing XC8 as a standard compiler (they do plan to eventually discontinue C18) the bugs will gradually be fixed and knowledge base will expand. Also, there is much less chance of official MC compiler being discontinued which is not the case with any of the smaller software companies. MikroElektronika is exception because their main revenue comes mostly from selling hardware and they have quite large user base because their libs, IDE and documentation are very good starting point for beginners.

So I must reluctantly agree with the standard assessment - start with MikroC and then work your way to official MC compiler (or some other professional compiler). CCS is not even an option if one is to hold on to ANSI C and portability.


All being said I will stick with XC8 until I eventually cross over to 16bit MCUs and XC16.

[glenndr_15]

MikroC's target market is for Educational/Hobby while for CCS target market is for Commercial and Educational.

[LithiumOverdosE]

That's your supposition or their official politics? 

[metal]

MikroC's target market is for Educational/Hobby while for CCS target market is for Commercial and Educational.

You are wrong.. both will never be commercial compilers. I saw mikroC used for some commercial products, but this doesn't mean it is for the commercial sector. Only PICC from Hi-Tech is used for serious commercial products, and just you know, people who work for companies using PIC for commercial products, use a mix of ASM and C. Do you believe that a professional needs a bunch of assholes (mikroE or CCS) to write libraries and drivers for him?

[sarah90]

I have used ccs in the past because it provided the c language for pic16 devices, where the microchip tools only provided asm. The bad thing about ccs is that provide "easy" functions and you do not know exactly how they implemented it. So debugging was a real pain in the .. and I lost a lot of time with it. I have no experience with MikroC.

For pic18 and better, microchip offers c compilers that are bare bone, but you know exactly what will be compiled and what not. That is what I like and see no reason to use anything else.

 

[cengiz_ayten]

I think, this stiation is changable

[LithiumOverdosE]

microchip offers c compilers that are bare bone, but you know exactly what will be compiled and what not.

A bit optimistic statement.