Which PIC compiler to choose?

Thread Starter

rougie

Joined Dec 11, 2006
410
Hello,

I have been programming Microchip mcu's for 4 years, namely the PIC18F4685and I have been using PCWH compiler from CCS. I recently maxed out the on board rom/ram memory for this part. My program is approximately 26K lines. I think the PIC18F4685 contains the largest amount of rom/ram for the PIC18's familly. And therefore if I want to continue my project I need a bigger mcu... perhaps the PIC24's familly with the PCWHD compiler from CCS.

Has anyone here experienced or used extensively the PCWH compiler. I was wondering, is the PCWHD compiler is the same as the PCWHD.

I was also looking for a PIC compiler for the MC PIC24's familly for C++. I have heard that IAR makes one and I also was told from IAR themselves that the compiler is approximately 4K$. Does anyone here know of any other C++ PIC compilers which are less costly?

I also had my eye on the Mikroc compiler, it seems to have some nice libraries while maintaining a good ANSI C compliance.

I am not crazy about MPLAB or Hightech, since there is not much pre-done libraries as in CCS and MikroC.

Anyone with feedback on this, please do get back!

Best regards
 
Last edited:

rjenkins

Joined Nov 6, 2005
1,013
I've been using the CCS compilers for many years, including PCWHD for the last 18 months or so.

From within MPLab, you don't really see any great differences between the versions, you just use the correct includes for the CPU and carry on as normal.

It still uses the same generic CCS toolsuite selection, everything to do with the specific CCS chip compiler version selection is is done transparently.
 

Tahmid

Joined Jul 2, 2008
343
Hi,
I use pic24 but I program in basic namely mikroBasic for PIC24/dsPIC. For c, you can use mikroC for PIC24/dsPIC.
 
Personally I do use the compiler from Microchip.

I feel good with that. I have not yet encountered any library limitation you are talking about.

Furthermore having an integrated IDE and hardware platform is quite convenient.

Last but not least, you will always have the support for all the PIC that get released. This is not in general true with other compilers or programmer.


Ciao,

Mauro
 

THE_RB

Joined Feb 11, 2008
5,438
I like the MikroC compiler. It's simple, the simulator is extremely easy to use and it handles bits quite well, which is a weakness with some other compilers.

They also have a lot of library functions for popular external devices.
 

S_lannan

Joined Jun 20, 2007
246
I use mikroC too. Plenty of examples and in built libraries eg. lcd, onewire, soft i2c, hardware i2c. I find it extremely easy to use.
full version costs $249 us dollars.

And i agree with what the_rb says too about handling bits. If you need to take one bit from any variables you just say Variable.F3 to get bit 3 from Variable for example. This is a lot easier than doing it with HitechC.
 

mik3

Joined Feb 4, 2008
4,843
You can move to AVRs, which I think have lager programming memory, and you can find the C compiler (AVRStudio 4 and WinAVR) for free.
 

hgmjr

Joined Jan 28, 2005
9,027
You can move to AVRs, which I think have lager programming memory, and you can find the C compiler (AVRStudio 4 and WinAVR) for free.
I second mik3's suggestion. The only cost you will incur by checking into AVR aside from the cost of the component itself is the cost of a programming unit. These programmers can be had for less that $50.

If you download AVRSTUDIO4 (for FREE) and fire it up you will be impressed with its power and ease of use. If you decide to program in C you can get WINAVR (for FREE). Again, you will be impressed. It works in conjunction with AVRSTUDIO4. It will cost you nothing to download the software and take a look at it. If you don't like the program you can always remove it from your PC.

hgmjr
 

nanovate

Joined May 7, 2007
666
Rich (BB code):
PIC18F4685 contains the largest amount of rom/ram for the PIC18's familly
The PIC18F6722 is larger.

Rich (BB code):
My program is approximately 26K lines
Is this lines of 'C'? How large of a device are you looking for?

Probably will not reap much advantage using c++ on 8/16 bit devices. The "embedded c++" is really targeted for 32-bit devices.

Going to a PIC24 means you will lose eeprom for larger devices but they do have twice the program memory as the largest PIC18.
 

rjenkins

Joined Nov 6, 2005
1,013
Don't forget the DSPIC range, eg. the DSPIC4011 has 48K Bytes flash and runs up to 120MHz clock, in a 40 Pin DIP package.

If you need still more, the DSPIC33FJ64GP202 has 64K Flash & 8K Ram in a 28 pin package for around $5.

There are waay bigger ones if you don't mind surface mount packages.
 

Thread Starter

rougie

Joined Dec 11, 2006
410
hello nanovate,

"The PIC18F6722 is larger."

Yes but its 64 TQFP package, which for now I am using 40 Pin dip in my target board. So this would mean that I would have to build a 64 TQFP to 64 pin dip convertor to accomodate my current target board's circuitry. Humm especially that after all that I am still at 10 MIPS, I really would prefer going straight for a faster MCU with larger memory.

"Probably will not reap much advantage using c++ on 8/16 bit devices. The "embedded c++" is really targeted for 32-bit devices."

Well, thats exactly what I don't understand, and therefore, where's the 32 bit device for Sourceboost: see here:

http://www.sourceboost.com/Products/BoostCpp/SupportedDevices.html

They only support PIC16/18... no Pic24's.

But anyhow, if there would be a C++ compiler for 32 bit which costs approximately 500$ I would go for it... ! But Iar is 4K$... and I don't see any others! If you know of one, please let me know.

On another subject, I have many functions that carry out the same logic, but using different structure types as their parameters. I would really need to use templates. Does anyone know of a good tutorial link on how to simulate templates in C?

"Going to a PIC24 means you will lose eeprom for larger devices but they do have twice the program memory as the largest PIC18."

PIC24HJ256GP210 has 2.5 times the PIC18F4685 of program memory, so I will use some of that as eeprom flash to store some of the informations I was storing in eeprom in the PIC18F4685 !

I looked over mikroc's website, and its true they do have lots of samples and it looks pretty interesting.

Regards
Ross
 

Thread Starter

rougie

Joined Dec 11, 2006
410
Hello Robert,

Right now, if I am to carry out any type of tests with my target board, I need minimum 100K of flash(program memory) *and* must be 40 pin dip.

I am pretty dead set on going for the PIC24's and port my code to it. At the same time I will build the TQFP to dip convertor and take advantage of the extra memory/speed. And apparently, pic 24's are comming out with 60 MIPS soon. So I would be set. Its just if one day I want to start chainging my structures to classes and use C++.... then what?

regards
ross
__________________
Robert Jenkins.
 

Thread Starter

rougie

Joined Dec 11, 2006
410
Hello rjenkins,

"From within MPLab, you don't really see any great differences between the versions, you just use the correct includes for the CPU and carry on as normal."

I hear alot of people doing this.... What do you do to use CCS within MPLAB? Do you open CCS and then click on MPLAB and start coding using the MPLAB interface?

And what about when you want to debug, do you use MPLAB or do you have to go back to CCS... confused!!!

Please get back
Reagards ross
 

rjenkins

Joined Nov 6, 2005
1,013
Hello rjenkins,

"From within MPLab, you don't really see any great differences between the versions, you just use the correct includes for the CPU and carry on as normal."

I hear alot of people doing this.... What do you do to use CCS within MPLAB? Do you open CCS and then click on MPLAB and start coding using the MPLAB interface?

And what about when you want to debug, do you use MPLAB or do you have to go back to CCS... confused!!!

Please get back
Reagards ross
Once you have installed the CCS Compiler (plus it's little MPLab interface program), you work purely within MPLab.

You have to tell it what 'toolset' you are using within the project setup (eg. CCS C compiler), but from then on you only use the facilities within MPLab - Build, Debug, Program, Trace / single step - all with the Microchip debug tools (ICD, PicKit etc) or just any supported generic programmer.

Basically once you have configured MPLab so it can find a working compiler for whatever chip you are using, it makes no difference to MPLab operation if it's Microchip's own compiler or one from another company.
 

THE_RB

Joined Feb 11, 2008
5,438
...

Right now, if I am to carry out any type of tests with my target board, I need minimum 100K of flash(program memory) *and* must be 40 pin dip.
...
I don't want to sound mean, but maybe you need to re-think your code writing techniques. Working with microcontrollers you have to change some of the ways you do things.

I've had C projects for PICs written in "C style" code that I was able to just re-write the C code a bit more like the techniques used in assembler, and had the same project shrink down to a fraction of its original size.

Just when you started talking "structures and classes" it reminded me of C code i've seen written by people who have never worked with limited size microcontrollers... :)

May I ask just what is the application that you believe requires 100k code size??? :eek:
 

nanovate

Joined May 7, 2007
666
Just when you started talking "structures and classes" it reminded me of C code i've seen written by people who have never worked with limited size microcontrollers...
It is amazing the bugs that come out of overflowing the avail resources on a micro. One time I "inherited" a design that was having intermittent problems in the field. It would stop responding every once in awhile or miss a message. It was suspected that it was a hardware issue -- esd or glitch since it passed all the bench tests which only exercised it one function at a time. I looked at the code and saw these huge two dimensional arrays declared as globals! Fixed that (total re-write) and there hasn't been a problem since.

Often breaking the project up into multiple micros is cheaper and better than trying to have one MEGA micro do everything. Code is developed faster and with fewer bugs and easier to debug-- more than makes up for the add'l dollar for an extra small micro or two
 

rjenkins

Joined Nov 6, 2005
1,013
I agree, if you tell us a bit more about your project we may be able to assist with possible options; eg. requiring pins for a keypad or LEDs does not mean they have to be on the PIC.

Another thing, as the_rb mentions, is fundamental coding style.
Make sure you are using the smallest variable sizes and simplest data types; eg. writing everything with long ints (or smaller) rather than floats will drastically reduce the code size, using char/byte for loop counters if you don't need to go beyond 255 will reduce it a bit more and so on.

Many compilers will code simple integer maths inline, but once you get to floating point and especially trig & log functions, one use of a particular operation will cause the compiler to add a library routine to handle the operation.

Avoid using the same expression repeatedly, calculate it once and re-use the result.
Use shifts instead of x2, x4 etc.
Be wary of arrays and pointers - using array[index] creates masses of code at each instance.
If you are going to be doing lots of ops on the same indexed value or structure, copy it to simple variables first then back when you are done with it.

Many compilers have the option to create an assembly-language listing of the program between the compile and assemble stages, it can be very enlightening to browse this and compare the C source lines (usually included as comments) to the produced assembly code. Often you can see simple changes that have drastic effects.
 
Top