CCS & MikroC Compiler Comparison

[max]

Following are the test results of a common C source
file using 16F870.

CCS C     1053 words, 51% flash

MikroC    1556 words, 76% flash

This shows that the MikroC consume 25% more flash then
the ccs c for the same source file.
See the attached source files, the source files can
also be used as a template for these compilers.

p.s. the same source file with code vision avr C, using
     the MEGA48 will consume 1329 words, 65% flash.

[vsmvdd]

its all down to the finaly assembly  using mplab  to do it
 
both  software  use it  both have there own versions  
 
perhaps the differance is  purly  an inline problem  with some  compilers
 
and also  ccs i found  isnt  as reliable under  tests  for endurance  of code
when the hardware is run
ccs  crashes more often  personaly i like free   free means  no money or hastle
 
try your tests  using sdcc  and  lets see if
1} its more robust
2} the word count and  flash count is less or more than  ccs and microc
 
 
i bet a free 0  that sdcc  works far better

[mick]

Cute

Can you run same tests for
IAR
Keil
 
                       Thanks

[arvind]

maybe...for pros these come into picture..but for beginners ...mikroc suits best..

[valefrancy]

the miKroC for pic family 16 Use the first two benches ram the other 2 are not managing

[vovchik02]

MicroC don't integrated with Proteus & MPlab.
CCS more compatibility with this deduger.

[mc993]

And now, is CCS is more stable in the last version (4.0.65) ?

[makall]

What's the code was used to test? If you share the code, we can test in others compilers and post the results!

[leandrohuff]

A good test is compare CC5X by http://www.bknd.com with another compiler.

Posted on: January 07, 2008, 09:20:07 21:20 - Automerged
share you code to compare the results.

[valefrancy]

MicroC provides several tools and interfaces priced quite see easypic5 just come out with integrated touch screen controller

http://www.mikroe.com/en/tools/easypic5/

[respected]

as for me ccs compiler very good

[vsmGuy]

CCS is a great compiler and come with great support too. Forums both paid and free!

[Davidvn]

MikroC is easier for beginners !

[free]

MikroC has great libraries.
Actually the compiler will be work on you to help your job is the point.

[magnum]

If you use MCU has small ram don't use MikroC

[joshua1]

CCS is a great compiler, MikroC is easier for beginners.
 
 

[ata_tr]

I think CCS is also easy for novices, experienced users should try HITECH C and Microchip C18.

[wATAw]

I don´t know how is MikroC but i have seen very interesting libraries for it. I use ccs because i think that is easy, but i know C18 and other microchip compilers are better...I will try with C18 someday....

[shaban]

I have ordered EasyPIC5 and I will try it with mikroC. I think it is great for beginers and offers great possibilities for experimenting.

[billy77]

MikroC is complicated for many applications.

[gasper]

I use generally ccs, but I believe that mikroC has good tools that ccs not, As the different terminals of communications for exaple.

[ambo]

Well for beginers like me, I find that mikroC has a lot more built-in routines compared to ccs c.  More easier on beginers like me.

[ninjammx]

Mikro C is more built in lib. and easy to use too. It come with all in one package.
CCS is flexible and expandable.

Mikro C is suitable for beginer and upper.
CCS is suitable for middle and higher level.

[TigerX]

I have tested both compiler with a smallest program. Test result is:

MicroC:
Used ROM : 36
Used RAM : 18


CCS C:
Used ROM : 69
Used RAM : 9

CCS C --> more ROM, smaller RAM
MicroC --> smaller ROM, more RAM

And also have a great difference:

-CCS doesn't show the asm code of whole program. It cuts the some important intgrated operation like multiplication:

The program and the ASM outputs of both ones are:

Micro C:

char a,b;

void main()
{
    //a = 3;
    //b = 5;
    PORTB = a*b;
}

Micro C - ASM Output:

;  ASM code generated by mikroVirtualMachine for PIC - V. 8.1.0.0
;  Date/Time: 04/03/2008 15:37:48
;  Info: http://www.mikroe.com


; ADDRESS   OPCODE   ASM
; ----------------------------------------------
$0000   $281D         GOTO   _main
$0004   $   _Mul_8x8_U:
$0004   $1303         BCF   STATUS, RP1
$0005   $1283         BCF   STATUS, RP0
$0006   $0870         MOVF   STACK_0, W
$0007   $00F1         MOVWF   STACK_1
$0008   $01F0         CLRF   STACK_0
$0009   $3008         MOVLW   8
$000A   $00FC         MOVWF   STACK_12
$000B   $0871         MOVF   STACK_1, W
$000C   $0CF4         RRF   STACK_4, F
$000D   $1803         BTFSC   STATUS, C
$000E   $2813         GOTO   $+5
$000F   $0BFC         DECFSZ   STACK_12, F
$0010   $280C         GOTO   $-4
$0011   $01F1         CLRF   STACK_1, F
$0012   $3400         RETLW   0
$0013   $1003         BCF   STATUS, C
$0014   $2818         GOTO   $+4
$0015   $0CF4         RRF   STACK_4, F
$0016   $1803         BTFSC   STATUS, C
$0017   $07F1         ADDWF   STACK_1, F
$0018   $0CF1         RRF   STACK_1, F
$0019   $0CF0         RRF   STACK_0, F
$001A   $0BFC         DECFSZ   STACK_12, F
$001B   $2815         GOTO   $-6
$001C   $0008         RETURN
$001D   $   _main:
;Muitiplication.c,3 ::       void main()
;Muitiplication.c,7 ::       PORTB = a*b;
$001D   $1303         BCF   STATUS, RP1
$001E   $1283         BCF   STATUS, RP0
$001F   $0820         MOVF   _a, 0
$0020   $00F0         MOVWF   STACK_0
$0021   $0821         MOVF   _b, 0
$0022   $00F4         MOVWF   STACK_4
$0023   $2004         CALL   _mul_8x8_u
$0024   $0870         MOVF   STACK_0, 0
$0025   $0086         MOVWF   PORTB
;Muitiplication.c,8 ::       }
$0026   $2826         GOTO   $


CCS C:

#include <16F88.h>

#FUSES NOWDT                    //No Watch Dog Timer
#FUSES INTRC_IO                 //Internal RC Osc, no CLKOUT
#FUSES NOLVP                      //Low Voltage Programming on B3(PIC16) or B5(PIC18)

#use delay(clock=8000000)

char a,b;

Void main()
{
   Output_B(a * b);
}


CCS C - ASM Output:

CCS PCM C Compiler, Version 4.068, 34857               03-Apr-08 15:38

               Filename: I:\PIC-Elektronik\PIC\Prog_Source Codes\ccs_c PCW\PIC16F88 Projeleri\PIC16F88 Binary Mult.lst

               ROM used: 69 words (2%)
                         Largest free fragment is 2048
               RAM used: 9 (2%) at main() level
                         10 (3%) worst case
               Stack:    1 locations

*
0000:  MOVLW  00
0001:  MOVWF  0A
0002:  GOTO   02A
0003:  NOP
.................... #include <16F88.h>
.................... //////// Standard Header file for the PIC16F88 device ////////////////
.................... #device PIC16F88
.................... #list
.................... 
.................... 
.................... #FUSES NOWDT                    //No Watch Dog Timer
.................... #FUSES INTRC_IO                 //Internal RC Osc, no CLKOUT
.................... #FUSES NOLVP                      //Low Voltage Programming on B3(PIC16) or B5(PIC18)
.................... 
.................... #use delay(clock=8000000)
.................... 
.................... char a,b;
.................... 
.................... Void main()
.................... {
002A:  CLRF   04
002B:  BCF    03.7
002C:  MOVLW  1F
002D:  ANDWF  03,F
002E:  MOVLW  72
002F:  BSF    03.5
0030:  MOVWF  0F
0031:  MOVF   0F,W
0032:  BCF    1F.4
0033:  BCF    1F.5
0034:  MOVF   1B,W
0035:  ANDLW  80
0036:  MOVWF  1B
0037:  MOVLW  07
0038:  MOVWF  1C
....................    Output_B(a * b);
0039:  BCF    03.5
003A:  MOVF   20,W
003B:  MOVWF  22
003C:  MOVF   21,W
003D:  MOVWF  23
003E:  GOTO   004
003F:  BSF    03.5
0040:  CLRF   06
0041:  BCF    03.5
0042:  MOVF   78,W
0043:  MOVWF  06
.................... }
0044:  SLEEP

Configuration Fuses:
   Word  1: 3F70   NOWDT PUT MCLR BROWNOUT NOLVP NOCPD NOWRT NODEBUG CCPB0 NOPROTECT INTRC_IO
   Word  2: 3FFF   FCMEN IESO


In MicroC Fuses and Clock are setted at sperately. Same fuses and clock rate has choosen. So, All everthing same. But the outputs are not same. As you can see, CCS C has not multiplication algorith but MicroC has.

This program is very very shot. Then, that is not a true comparion. But gives us some ideas.

I use CCS. But I have trying MicroC in a few days. MicroC has some internal utilities an statements. And also,

I din't run USART with CCS but MicroC I have run. Some code but CCS didn't give any output at USART PIN's. Because of the fact that, I tried MicroC. Now, I am testing both anywhere.

But I like CCS ...

[jabuka]

mikroE is good for beginners, but CCS C caters to beginners and professionals as well. Aside from the fact that mikroE's libraries are hidden, there is not much you can do to somehow flex your code. Here is a classic example: The flex lcd driver in the code section of this forum. You cannot write such a flexible lcd driver with mikroE without going thru the pain of coding the whole thing again. C18 is definitely not at par with CCS C because of its limited MCU support. I never tried Hi Tech. the SDCC v2.7 (gnu) is stable than the previous releases but you will have to write your own libraries - painfully. In my experience, CCS C is the best RAD for PIC MCUs. with regards to the crashing of your PC, If we are using exactly the same CCS C IDE version and mine is stable then the problem could be in your OS version or some libraries /behind the scene programs running in your PC.

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

[ikefu]

I think one thing to consider in comparing compilers is the speed at which the programmer can crank out a prototype program. MikroC has closed libraries which makes it less flexible, but it has so many built in libraries and I find myself coming back to it for all my prototyping needs. For instance, I can use the built in PWM library and just put in a frequency without having to do the calculations I would need without it. So I think you need to consider how you're going to be using it before you pick a compiler. For most school/hobby/prototyping projects the compiler you can program the quickest in is the best. If you go professional and are coding for a product that will be sold the world over and needs super fast optimized code then you'll probably want to look outside of MikroE or the other higher level compilers.

[Vineyards]

As a matter of fact, it is not right to consider MikroC a hobbyist only platform. We tend to overestimate commercial products. The golden  rule for today is that the eqipment doing the job in the most cost efficient and practical way sells the best. You are welcome to doing with any compiler. If you want to end up in Siemens or Sony they will tell you what platform to code in anyway. In a nutshell, learning  a compiler very well is a hundred times better than wasting your time comparing them. They are all good in different ways.

[mario2000]

Mikroc:

Code:

unsigned time;
void main() {
  delay_ms(time);
}

Error: void Delay_ms(const unsigned long time_in_ms);

CCS:

Code:

int8 time;
void main()
{
    delay_ms(time);
}

Copiling, complete no error.  

Note that this function in ccs can work with constants and variables, mikroC added new features to its latest version to support variables in this function.

New funtion's in mikroc:
void Vdelay_ms(unsigned time_in_ms);
Creates a software delay in duration of time_in_ms milliseconds (a variable). Generated delay is not as precise as the delay created by Delay_ms.
Note that Vdelay_ms is library function rather than a built-in routine; it is presented in this topic for the sake of convenience.


void VDelay_Advanced_ms(unsigned time_in_ms, unsigned Current_Fosc_kHz);
Creates a software delay in duration of time_in_ms milliseconds (a variable), for a given oscillator frequency. Generated delay is not as precise as the delay created by Delay_ms.
Note that Vdelay_ms is library function rather than a built-in routine; it is presented in this topic for the sake of convenience.

[mclinic]

i preffer ccs , stable & less lines of code

[danifox]

I've worked with CCS compiler for 2 years without big issues, and when I started I had never programmed a PIC before. For that reason, I think CCS is also good for beginners. I haven't tried mikroE, but CCS is way easier than XC8.

[gan_canny]

CCS definitely has advantages. CCS unlike many doesn't wait months or years to fix bugs. There is is the option of compiling with several earlier versions so any issue with a rapid update is easily avoided. It is the best of both worlds and the built in functions make for a short learning curve.

[kaem1189]

I used CCS, mikroC, xc8 compilerss..

xc8
    *you only need one reference for programming which is the datasheet of the controller that you are using.
    *advisable for advanced user because of mplabx ide debugging capability(with the use of ICD3 or REALICE)
    *ANSI compliant coding
    *can control each and every part of the code which can be helpful for advanced users..
    *access to registers are easy
    *advanced libraries that has a LOT of settings that can be customized
    *always supports the latest controllers

ccs
    *smallest output hex file compared to the other compiler
    *simplified usage of codes eg. LATX.XY = output_high(PIN_XY) which is very helpful for beginners
    *setup of controller and accessing features are already optimized for the user and requires lesser lines of coding
    *some parts of the code like the interrupt routines automatically resets the flags
    *very understandable functions and routines. Refer to CCS manual
    *very easy to change controller using the same codes..
   
mikroC
   *ANSI compliant coding
   *similar to xc8 coding style
   *lots of libraries for different ICs
   *graphics support and a lot of handy plugins
   *very easy setup of controller


Hope these will help you in choosing your compiler

[Vineyards]

I used CCS, mikroC, xc8 compilerss..

xc8
    *you only need one reference for programming which is the datasheet of the controller that you are using.
    *advisable for advanced user because of mplabx ide debugging capability(with the use of ICD3 or REALICE)
    *ANSI compliant coding
    *can control each and every part of the code which can be helpful for advanced users..
    *access to registers are easy
    *advanced libraries that has a LOT of settings that can be customized
    *always supports the latest controllers

ccs

    *simplified usage of codes eg. LATX.XY = output_high(PIN_XY) which is very helpful for beginners

I generally agree with you however that item could actually be just one more addition to the code spagetty that boggles peoples minds while preventing them from learning the real thing.
I wouldn't want to be limited to one language variation that is meaningless elsewhere in the presence of all that needs to be learned and memorized.

[kaem1189]

I generally agree with you however that item could actually be just one more addition to the code spagetty that boggles peoples minds while preventing them from learning the real thing.
I wouldn't want to be limited to one language variation that is meaningless elsewhere in the presence of all that needs to be learned and memorized.

I totally agree with you.. I stopped using CCS very long time ago and used xc compilers now (xc8 and xc32) if you want to learn every part and all of the microcontroller. Go for XC compilers.. you can customize your code as if you control almost all of the microcontroller.

PS. if you adopted this coding style, its easy to migrate to other controllers eg. AVR freescale , their native IDE and compilers uses the same "register" based control of the chip

[picdev2]

I installed the new MPLABX with XC8 compiler, the peripheral libraries are not supported , the Code Configurator produce the library fuctions with no documentetion or examples!
For test I configure the i2c , I couldn't understand what the functions do. Why such a mess ?

[mars01]

If you look into the generated header files (.h files) by Code Configurator you will find documentation in the comments for each function, data structure. There are also some examples in those comments.

One example. Here is the comment for the I2C1_MasterRead function:

Code:

/**
    @Summary
        Handles one i2c master read transaction with the
        supplied parameters.

    @Description
        This function prepares a TRB, then inserts it on the i2c queue.
        Finally, it waits for the transaction to complete and returns
        the result.

    @Preconditions
        None

    @Param
        address - The address of the i2c peripheral to be accessed
    
    @Param
        length - The length of the data block to be sent
    
    @Param
        *pdata - A pointer to the memory location where received data will
                 be stored

    @Param
        *pstatus - A pointer to the status variable that the i2c driver
            updates during the execution of the message.

    @Returns
        I2C1_MESSAGE_STATUS

    @Example
        <code>
 
            #define MCHP24AA512_RETRY_MAX  100  // define the retry count
            #define MCHP24AA512_ADDRESS    0x50 // slave device address

            uint8_t MCHP24AA512_Read(
                                            uint16_t address,
                                            uint8_t *pData,
                                            uint16_t nCount)
            {
                I2C1_MESSAGE_STATUS status;
                uint8_t     writeBuffer[3];
                uint16_t    timeOut;
                uint16_t    counter;
                uint8_t     *pD, ret;

                pD = pData;

                for (counter = 0; counter < nCount; counter++)
                {

                    // build the write buffer first
                    // starting address of the EEPROM memory
                    writeBuffer[0] = (address >> 8);                // high address
                    writeBuffer[1] = (uint8_t)(address);            // low low address

                    // Now it is possible that the slave device will be slow.
                    // As a work around on these slaves, the application can
                    // retry sending the transaction
                    timeOut = 0;
                    while(status != I2C1_MESSAGE_FAIL)
                    {
                        // write one byte to EEPROM (2 is the count of bytes to write)
                        I2C1_MasterWrite(   writeBuffer,
                                                2,
                                                MCHP24AA512_ADDRESS,
                                                &status);

                        // wait for the message to be sent or status has changed.
                        while(status == I2C1_MESSAGE_PENDING);

                        if (status == I2C1_MESSAGE_COMPLETE)
                            break;

                        // if status is  I2C1_MESSAGE_ADDRESS_NO_ACK,
                        //               or I2C1_DATA_NO_ACK,
                        // The device may be busy and needs more time for the last
                        // write so we can retry writing the data, this is why we
                        // use a while loop here

                        // check for max retry and skip this byte
                        if (timeOut == MCHP24AA512_RETRY_MAX)
                            break;
                        else
                            timeOut++;
                    }

                    if (status == I2C1_MESSAGE_COMPLETE)
                    {

                        // this portion will read the byte from the memory location.
                        timeOut = 0;
                        while(status != I2C1_MESSAGE_FAIL)
                        {
                            // write one byte to EEPROM (2 is the count of bytes to write)
                            I2C1_MasterRead(    pD,
                                                    1,
                                                    MCHP24AA512_ADDRESS,
                                                    &status);

                            // wait for the message to be sent or status has changed.
                            while(status == I2C1_MESSAGE_PENDING);

                            if (status == I2C1_MESSAGE_COMPLETE)
                                break;

                            // if status is  I2C1_MESSAGE_ADDRESS_NO_ACK,
                            //               or I2C1_DATA_NO_ACK,
                            // The device may be busy and needs more time for the last
                            // write so we can retry writing the data, this is why we
                            // use a while loop here

                            // check for max retry and skip this byte
                            if (timeOut == MCHP24AA512_RETRY_MAX)
                                break;
                            else
                                timeOut++;
                        }
                    }

                    // exit if the last transaction failed
                    if (status == I2C1_MESSAGE_FAIL)
                    {
                        ret = 0;
                        break;
                    }

                    pD++;
                    address++;

                }
                return (ret);

            }
        
      </code>
   
*/

void I2C1_MasterRead(
                                uint8_t *pdata,
                                uint8_t length,
                                uint16_t address,
                                I2C1_MESSAGE_STATUS *pstatus);

[picdev2]

I generate code for UART , this is not library, There isnt a fuction to change the baud rate , the baud rate is fixed.
The old Plibs was fine.

[mars01]

There are always some trade-offs. What's keeping you to make a function for this baudrate change? It's not that hard to add it.
The purpose of a compiler is to compile the code efficiently and correctly. The rest is just bonus.

If you need a compiler that give you a lot of libraries, use mikroC (or even CCS).

[hanle]

I used MikroC and MPLAB C18 to make a pure sinwave inverter, I had a big problem with MikroC about speeding calculator and interrupt services. However, when I used MPLAB C18 which quite good with the same algorithm.