Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Anyone Using CCS C Compiler for pics?

Status
Not open for further replies.

large_ghostman

Well-Known Member
Most Helpful Member
As the title says, does anyone here use it? Whats your opinion on it? Do pickits work ok on it and ICD3's? Any problems etc etc etc. I am looking at getting back into pics, but things have changed. Dosnt look like free compilers are worth using with pics, but I am not going to sell off stuff just to buy a compiler I am not happy with!! I would go Mikro C, but I dont want to buy a different debug tool as I have a ICD3 and pikit3.

All of the compilers seem alot of money, having used ARM mostly for the last year or so, I got spoiled by decent tools at a reasonable cost. Mostly the free ones were just code size limited.
 
Is there a free version?

If there is, then maybe I will give it a try....

.... and let you know how I get on.

I sense that it is not a popular choice.

Finally got the hang of MPLABX and XC compilers, but still struggle to see what it gives me over MikroE toolchain (other than that it is free)
 
The best free compiler is still XC8 ~ XC32 The XC32++ is totally free... Even with the bloating you can still get quite good function from them... I have tried sourceboost C, CCS, MikroC... FED C ( That only costs £65 ) I have still ended up forking out for the XC8 compiler!!!
 
The best free compiler is still XC8 ~ XC32 The XC32++ is totally free... Even with the bloating you can still get quite good function from them... I have tried sourceboost C, CCS, MikroC... FED C ( That only costs £65 ) I have still ended up forking out for the XC8 compiler!!!
Your on the other end of the spectrum though. Its hard to justify £700 for a hobby but if you squint a bit then £300 isnt as hard to justify. Ok if you squint alot
 
This really doesn't look that bad
Part Number: SW006021-SUB - MPLAB XC8 PRO Compiler Subscription License

The MPLAB® XC8 PRO Compiler (Subscription License) enables PRO-level features and optimizations on a Monthly basis for the MPLAB XC8 Compiler. These features and optimizations include highly-optimized ANSI C for all of Microchip’s 8-bit microcontroller families. This license also allows unlimited compiler updates without the need for HPA (High Priority Access).
The compiler itself integrates into MPLAB X IDE, Microchip’s feature-rich integrated development environment, and is compatible with all Microchip debuggers, programmers and emulators. As with all of Microchip’s design tools, the MPLAB XC8 Compiler works with Windows, Linux and Mac operating systems.
 
Is there a free version?

If there is, then maybe I will give it a try....

.... and let you know how I get on.

I sense that it is not a popular choice.

Finally got the hang of MPLABX and XC compilers, but still struggle to see what it gives me over MikroE toolchain (other than that it is free)
Well I will have a go and see if I can debug with MikroE under mplab. Although I do like the MikroE IDE.

One question I cant work out, on some the chips you get different coloured padlocks on the chip diagram, in MPLABX what do they mean? I couldnt find the info in the badly organised docs :D.
 
You can mix and match mikroE and MPLABX tool chains, but the experience is not as pleasant as sticking to entirely one or the other.

For instance, you can compile with ME then use MPLAB and PICkit3 to debug, but that means switching between IDEs and I suspect (not sure) that less information is available this way.

Debugging ME with the ME programmer is a much more pleasant experience. Debugging on easyPIC board is really nice, since everything is self contained (built-in programmer) and the board is large, making connection easy.

Trouble is the bill for ME ends up huge, because the more you get, the more you want. I have spent many thousands of £

Starter system might be something like:
PIC Compiler - £300
Programmer - £100
EasyPIC7 - £150 (cheaper if bought as a kit with compiler, LCD, GLCD)
a couple of click boards (not vital, just for fun) £60

.... so somewhere around £600 to start off (all prices approximate and from failing memory)

Then you may want:
PIC24 Compiler £300
PIC32 Compiler £300

Then you might be tempted to get more Development boards and more click boards - ends up a lot of money (but IMHO worth every penny)

MCHP toolchain is a lot cheaper if you can live with free versions. Remember XC8 only does 8 bit PIC, so there are two more compilers to buy at £700 a time if you want 16 and 32 bit PICs should code size and speed turn out to be important.

Tried CCS copiler 45 day trial - seems OK, but I can't find a way to use PIC register names in a straight forward way. Guess I am old and set in my ways, but I much prefer a nice standard statement like " LATB = 0x55;" to: the CCS way of "output_b(0x55);". Even if it turns out that there is a way to use real SFR names as in the datasheets, the programs I have seen do it the CCS specific way. Not found any other obvious reason to dislike CCS, but that one issue may be enough for me to not want to explore further.

The other down side of mikroE is that it is so easy and so nice to use that you may get lazy, and struggle to return to other tool chains.
Another issue with mikroE is that libraries are closed source, so if you want something other than the supplied library routines, you end up having to write them yourself.

Sorry for the wordy response, but choice of toolchain is not easy, and before you commit to investing big money, you should be aware of the limitations of each.

Hope this helps, rather than adds confusion ;)
 
Oh - and as for padlock colours - haven't found doc on it either, but just playing around tells me:

Blue - pin not allocated and is available
Green - pin in use
Orange - pin not available
Green chain - pin allocated twice (which presumably is to be avoided most of the time)

EDIT - found this: https://microchipdeveloper.com/mcc:overview
 
Last edited:
You can mix and match mikroE and MPLABX tool chains, but the experience is not as pleasant as sticking to entirely one or the other.

For instance, you can compile with ME then use MPLAB and PICkit3 to debug, but that means switching between IDEs and I suspect (not sure) that less information is available this way.

Debugging ME with the ME programmer is a much more pleasant experience. Debugging on easyPIC board is really nice, since everything is self contained (built-in programmer) and the board is large, making connection easy.

Trouble is the bill for ME ends up huge, because the more you get, the more you want. I have spent many thousands of £

Starter system might be something like:
PIC Compiler - £300
Programmer - £100
EasyPIC7 - £150 (cheaper if bought as a kit with compiler, LCD, GLCD)
a couple of click boards (not vital, just for fun) £60

.... so somewhere around £600 to start off (all prices approximate and from failing memory)

Then you may want:
PIC24 Compiler £300
PIC32 Compiler £300

Then you might be tempted to get more Development boards and more click boards - ends up a lot of money (but IMHO worth every penny)

MCHP toolchain is a lot cheaper if you can live with free versions. Remember XC8 only does 8 bit PIC, so there are two more compilers to buy at £700 a time if you want 16 and 32 bit PICs should code size and speed turn out to be important.

Tried CCS copiler 45 day trial - seems OK, but I can't find a way to use PIC register names in a straight forward way. Guess I am old and set in my ways, but I much prefer a nice standard statement like " LATB = 0x55;" to: the CCS way of "output_b(0x55);". Even if it turns out that there is a way to use real SFR names as in the datasheets, the programs I have seen do it the CCS specific way. Not found any other obvious reason to dislike CCS, but that one issue may be enough for me to not want to explore further.

The other down side of mikroE is that it is so easy and so nice to use that you may get lazy, and struggle to return to other tool chains.
Another issue with mikroE is that libraries are closed source, so if you want something other than the supplied library routines, you end up having to write them yourself.

Sorry for the wordy response, but choice of toolchain is not easy, and before you commit to investing big money, you should be aware of the limitations of each.

Hope this helps, rather than adds confusion ;)

All the info I found so far says only mplab and not MPLABX, works with MikroE C. The real gotcha though is apparently you have to use the COFF file to do this, there was also some issues with variable names. So If I go the MikroE way then I would get the MIKROE programmer.

CSS
I will download the trial and have a play, it also fits into MPLABX apparently, if there is no way to use register names then its a bust! Stuff like LAT or Port should be standard IMHO. So I will dig into this.

This is getting an expensive hobby, when I started the tools were free apart from the programmer and worked enough to use. To me MC make chips, the tools should be free. Like sil labs on the 8 bit side they pay for the Kiel compiler for you. On the 32 side you can use the IDE with GCC which is free, you also have a wide variety of IDE's that support GCC. Its one reason I really like ARM stuff, plus the dev kits from sil labs are some of the best value and quality I have ever seen. Take a look at the Gecko STK boards and see how stuff is crammed onto a $29 board! Which can also program ANY JTAG board or chip as it has a built in unlocked programmer!!
 
So If I go the MikroE way then I would get the MIKROE programmer.
Wise choice - IF you can afford it.

This is getting an expensive hobby
yes, there is cheap, or there is nice - pick one of those two

Good luck with whichever choices you make

EDIT: I bought EasyPIC7 board because it is the best board out there, planning to use it with MCHP tool-chain. It lead me to buy more and more ME compilers and hardware, without regret. But then again... I am lucky to be able to afford the luxury options.
 
Yeah its just annoying I was happy with C18 mplab and the ICD3!! XC8 I dont like and C18 dosnt support some of the chips I use, on the other hand MPLABX dosnt support some of the older chips I use!!! Thats my main niggle, take the 18f4685 40 pin dip. Its a fab chip, but XC8 dosnt have the Libs any more and the thing they use to set up the chips instead of libs, dosnt support that chip.

But I also use some K20 parts, so C18 and MPLAB dosnt support them but XC8 and MplabX does. So I am sort of stuck in the middle with 2 tool chains!! plonking money out for MIKROE programmer is going to hurt alot. I work part time when I can after school, but I dont earn much (around £20 a week this time of year). Most of that goes on essentials.

Looking at the CCS docs...... It does have some quirks!!! I am not sure if any of the register names are supported directly or not. So that might be a bust, I like to use some of them straight from the datasheet, I find it odd a compiler wouldnt support the manufactures register naming. Things Like OSCON should be supported IMHO.
 
take the 18f4685 40 pin dip. Its a fab chip, but XC8 dosnt have the Libs any more and the thing they use to set up the chips instead of libs, dosnt support that chip.
You can still download the peripheral libraries..
But I also use some K20 parts, so C18 and MPLAB dosnt support them but XC8 and MplabX does.
MPLAB IDE V8.xx does support that chip... I use the pic18f45k22 with C18 in the MPLAB IDE... I know the 45k20 was supported because I used that for a couple of weeks until I found out it was a 3v3 chip only..

I have said this before...I think that XC8 is a far better compiler than the old C18... Hitech where making compilers long before the C18 was thought of.... In fact C16/17 were abandoned some years back... C18 has always been messsy and buggy ... HTC was far superior then and still is... The only thing you have been used to is the pre-built libraries... On many occasion I had to modify these... USE_OR_MASK Bah humbug... never seemed to work then... Here is the link

https://www.microchip.com/mymicrochip/filehandler.aspx?ddocname=en574973

Windows peripheral libraries for the old C18...
 
Ian you keep confusing me!!!!

Right lets get this straight......


1) Can i use the C18 libs with XC8 compiler?
If I cant then downloading them is pointless unless I use C18, I will check which chips I have that C18 dosnt support.

XC8 is supposed to be Hitech C but I used hitech C and liked it alot, the IDE was also great (high Tide). XC8 seems a botch up of Hitech but I am no expert. Hitech also had alot of peripheral Libs in it, so if XC8 is hitech under a different name, why take the libs out? If I can use C18 libs with XC8 then fine, but reading the XC8 manual makes me think that wouldnt work.
 
1) Of course you can.... A library can be used for any compiler... Any compiler specifics have to be taken on board.

If you need to use LATABits.LATA4 for example just include the header.... XC8 headers are slightly different so some definitions aren't included... The library will start to cry "whah... where's the definiton. boo hoo" So you just need to include it..

When you try and compile the library, just take a note of the errors, then look at the include file and see which one you need to use..

If you give me an example of the library you want to use and I'll show you how to do it.. Remember though.. the libraries where rubbish... I mostly wrote my own anyway... Doing this gives you the power to use any compiler... I was trying to use the pre-built libraries in MikroC... There were many conflicting libraries.. ie.. the sound library wouldn't co-exsist with the mono graphic library... What I did was port my own.. done..
 
1) Of course you can.... A library can be used for any compiler... Any compiler specifics have to be taken on board.

If you need to use LATABits.LATA4 for example just include the header.... XC8 headers are slightly different so some definitions aren't included... The library will start to cry "whah... where's the definiton. boo hoo" So you just need to include it..

When you try and compile the library, just take a note of the errors, then look at the include file and see which one you need to use..

If you give me an example of the library you want to use and I'll show you how to do it.. Remember though.. the libraries where rubbish... I mostly wrote my own anyway... Doing this gives you the power to use any compiler... I was trying to use the pre-built libraries in MikroC... There were many conflicting libraries.. ie.. the sound library wouldn't co-exsist with the mono graphic library... What I did was port my own.. done..

Cheers Ian, that makes more sense. Explains alot why XC8 has the one header for most things....... So on the whole do you include the device header or just the XC include? Or both? That might be enough for me, with the device header I can always copy the bits of the libs I want. By that I mean I use them to open up and look for the registers and then use those. If that makes sense!
 
The easiest way is to copy the source code library to your project directory then copy all the relevant header details to a new header and just include that.

The one good thing about making the libraries your own is you can trim all the fat away... The bits you'll never need.
 
I need to try that later, I have read so much etc I have brain freeze at the moment :D. I have put the thing away for a bit lol. Before it took a trip at high speed towards the wall :D.

I can see why Arduino is doing so well. I always preferred pics, but lately I have to admit Arduino has the right idea IDE and compiler wise. Looking at CCS docs...No chance going that route.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top