PIC Compiler Recommendation - Page 1
Forum section: electronics / general

author: 7
author_rank: Newbie
timestamp: May 02, 2016, 05:18:38 pm
content: I've been programming 8-bit PICs using MELabs PICBASIC Pro for what feels like an awfully long time. I still have the original 3.5" floppy...I want to start working with 16-bit PICs, which MELabs will not be supporting for some time, if ever. (For 8-bit PICs, PBP has been absolutely brilliant and I have no complaints about it whatsoever.)I also figure I should make the leap and to a C-based compiler, and am asking that the knowledgeable folks here make recommendations for which one to select.FWIW I am moderately competent in a number of languages, including C and C++, and have programmed the MSP430 in some depth a few years back.I am leaning towards the MikroC for dsPIC, as it appears relatively economical in the long term and covers pretty much all of the 16-bit PICs. Are there others I should be looking at instead?Thanks,Paul

author: dannyf
author_rank: Super Contributor
timestamp: May 02, 2016, 05:34:09 pm
content: I have been a big fan of c30/xc16. Even the free version is good enough for me.

author: ez24
author_rank: Super Contributor
timestamp: May 02, 2016, 06:55:46 pm
content: My guess others will want to know what platform ie Windows, Linux, or MAC ?Trivia question - How many C compilers for PIC are there?

author: JPortici
author_rank: Super Contributor
timestamp: May 02, 2016, 07:17:27 pm
content: MPLABX + XC8/16/32. When you need optimization there is always assemblystick to the officially supported tools. still the best IMOI've never used Mikroe for anything other than 8bit pics, i remember them being really good in terms of optimizations.. all the builtin functions are good to get started and to test hardware, peripherals... nice support... but they're windows only, less "ansi" than microchip's compilers and they are limited in size for the free version.

author: Wilksey
author_rank: Super Contributor
timestamp: May 02, 2016, 07:57:06 pm
content: I've mainly used the microchip compilers / hitech c compilers, i've used CCS C and MikroE compilers, both serve their purpose. For the most part the Microchip offering will do what you need.Note. The MLA seems to have omitted most of the ethernet stuff, so I downloaded a 2013 archive (from the Microchip website) which still works fine, not sure what Microchip are playing at removing it from their latest offering.

author: 7
author_rank: Newbie
timestamp: May 02, 2016, 08:58:23 pm
content: Thanks everybody. I guess there are considerably fewer options than I thought. I appreciate the suggestions and am downloading the Microchip stuff.I will be programming in the Windows environment for the time being.I'll give it a whirl and see how it goes...Best,Paul

author: jnz
author_rank: Frequent Contributor
timestamp: May 02, 2016, 09:05:24 pm
content: I used CCS, then MLAB and MPLABX with the newer XC compilers... Go official.Fwiw... I can't imagine going from 8bit PIC to 16bit PIC when 32bit ARM is cheaper and FAR more supported, with legit companies making legit peripherals. There is just literally no reason to stop at 16bit, and MCHP's 32bit is trash IMO....Mac has an amazingly wide selection of chips, but outside of 8bit there are just so many better options, just my opinion but I'd recommend a course correction while you can.

author: JPortici
author_rank: Super Contributor
timestamp: May 02, 2016, 09:31:46 pm
content: i can't imagine doing with arm what i can do with dspics and their peripheralswhich is why we still haven't found a reason to switch to 32 bitters at work

author: Delta
author_rank: Super Contributor
timestamp: May 02, 2016, 10:06:40 pm
content: XC16

author: TheDirty
author_rank: Frequent Contributor
timestamp: May 02, 2016, 11:32:18 pm
content: You could always give the MPLAB-X Express a try.https://www.microchip.com/mplab/mplab-xpresshttps://mplabxpress.microchip.com/mplabcloud/ide

author: asgard20032
author_rank: Regular Contributor
timestamp: May 02, 2016, 11:40:22 pm
content: I am still surprised by the large PIC fan-base, and the fact that xc16 and xc32 are based on gcc that there are no community repository with a pre-compiled gcc without restriction and with proprietary part removed (even if it include some optimization layer. GCC already has more than ok level of optimization for pic32 if its not crippled AKA allow optimization).By the way, nowadays, if you want to start out pic16 bit, you could also jump straight to 32 bit. PIC24/dsPIC are complex enough at peripheral level that it is not harder than going pic32 or some entry level/easy to use arm like the entry level lpc from NXP. It is more a matter of taste from now on, and a balance between feature, speed, predictability (interrupt latency, branch, pipeline...), and stability/maturity.If we compare PIC24/dsPIC to PIC32 (since you know better microchip product):PIC24 is better for hard real time, since it has a less complex pipeline, more predictable (every if statement will always take the same number of cycle, on pic32, because of branche optimization, wait-state, and other such optimization mechanism, it may be sometime faster, sometime slower). PIC24/dsPIC is a more mature product, less bug than PIC32. PIC24/dsPIC has better math performance in tight loop (for doing FFT, and other dsp related work). On the long run, PIC32 has better performance in big loop/multimedia (because of all its peripheral for multimedia, like lcd controller, 32 bit math for doing audio decoding). PIC24/dsPIC has faster GPIO, more peripheral related to motor control, reading encoder... PIC32 has more memory. But in the end, they both have the same complexity. ARM is like 10-25% harder compared that (as long as you don't take stm32f4/f7 or other big number crushing arm with advanced peripheral).Oh and another factor important : your style of literature. A factor that few people take into account but can make a huge difference. Some people understand some author better. For example, I can't understand many datasheet from microchip (how the data is formatted, explained, fragmented between multiple document, from my opinion, data in the wrong place). But I can understand datasheet from texas instrument (msp430) and atmel(AVR & sam) without problem. I know many other people that just can't stand atmel datasheet and feel right at home with microchip datasheet. But it also depend on who written the datasheet. Sometime, the same author written the datasheet, 20 application note, and 2 user guide, and many peripheral manual, except the one peripheral you need, that was written by someone else who you have difficult understanding what he say. Before choosing your target for your next few month of playing, explore different micro-controller, datasheet, and try to find your sweat spot of understanding in those datasheet.Oh and by the way, in no way I say you SHOULD go 32 bit, I just say it is an option you could consider. Unlike many other people, I don't say that 32 bit is the solution to everything, I see its advantage and disadvantage. But I agree 8 bit is really outdated and people should stop using it, except if they got an overstock of some part. Especially the 18 bit pic family. Nowadays, 16 bit are so much more better, cheaper, more featured, more efficient (less wasted power). Except from utterly simple task like electric toothbrush, where a 4 bit could suffice, people should move on. 16 bit is not dead, and are more than enough for any task, including quadcopter.

author: 7
author_rank: Newbie
timestamp: May 03, 2016, 03:26:57 am
content: Thanks again for even more advice and comments. I left the Microchip IDE download going and I'll try it in the morning. I appreciate that there is a free version that is only moderately crippled, which I hadn't realized...I'm not convinced that a 32-bit micro controller is automatically a better replacement for an 8-bit. For example I don't see any listed with only eight pins, so size consideration alone might eliminate them. I'm intrigued by the idea that if you're gonna go 16 bit then ya might as well go 32. However, low power is often a key concern as I rarely have a power budget that exceeds 1 or 2 mA, although the µC is usually just a small percentage of this. I haven't looked deeply into this yet, and not at all for the 32-bit.As far as remaining with PICs is concerned, a significant part is familiarity with the family. At this point I get how their datasheets are arranged and know how to fine what I need, and I am presuming that will follow into 16 and/or 32 bits. The MSP430 data book(s) drove me batty. It is possible that I'm just old and set in my ways...8v)Again, you all have made some excellent points and I appreciate you sharing them. I will have to take a look at options outside of Microchip (such as NXP) as the next project solidifies.Best,Paul

author: hans
author_rank: Super Contributor
timestamp: May 03, 2016, 10:27:19 am
content: I haven't looked very in depth at the power efficiency of PIC32 yet. But in the datasheet of the PIC32MX250 it says about 2mA at 4MHz, and 20mA at 40MHz (500uA/MHz). The PIC32MZ don't show much improvement either. Moreover their datasheets share scarce breakdown details of peripherals, voltage/temperature sweeps, etc., so I think it's quite clear those PIC32 parts are not optimized for low power unfortunately.Then a PIC24 is a better choice, as it will consumes slightly less power. A modern PIC24 part (like PIC24FJ128GA202) consumes 5.7mA @ 16MIPS (356uA/'MHz'), and ~1.5mA at 4MIPS (older released chips more though). Note that oscillator modules have relatively high operating currents independent of frequency, thus effectively increasing uA/MHz figures at lower speeds.Unfortunately PIC24 operating current figures aren't super special either, as many new Cortex m0+ or m3 chips run 100-200uA/MHz. With a budget of 2mA you could find a MCU that runs 8-12MHz easily.The free XC16 compiler is satisfactory. It is built on GCC, has C99 and so it's very easy to write sharable code between AVR, ARM and MSP430 GCC variant of compiler. Unfortunately no C++ support in XC16.Out of the non-free optimizations the one you will likely miss is -Os, however if you are designing for low-power you wouldn't want to use that anyway. In my energy consumption testing using an AES128 algorithm, I found that -O3 shows very mild to no improvement at all compared to -O1. Maybe this changes if they work on compiler optimizations in the future.. I am not sure. On MSP430 I did saw a ~15% energy consumption improvement between -O1 and -O3 (while using the exact same test code & 'benchmark' - which in no way is very representative).All in all, if you want to stay with Microchip I can understand the choice of PIC24.

author: dannyf
author_rank: Super Contributor
timestamp: May 03, 2016, 12:04:14 pm
content: QuoteThe basic structure of the datahsheet is roughly comparable. The actual details of the peripherals are vastly different.If it is that important to you, take a look at pic24 datasheet and see if you are comfortable with it before migrating.

author: Karel
author_rank: Super Contributor
timestamp: May 03, 2016, 12:16:03 pm
content: Quote from: asgard20032 on May 02, 2016, 11:40:22 pmThe only thing I can think of, is that the free versions are satisfactory for most applications and/or that there's not much gain to get with higher optimization settings.So, probably it's not worth the effort.

author: Sbampato12
author_rank: Regular Contributor
timestamp: May 03, 2016, 01:12:37 pm
content: I've been workin with MikroPascal PRO. I've bought it some years ago. No regrets.If it is the best option? For me was. Was the cheaper solution to go 'legal', a really good support from mikroe, nice interface and worked without bugs (for me at least).Recently I bought the MikroPascal 32, but I'm without time to test it. I've not got the job that needed pic32, and not used it yet.

author: igendel
author_rank: Frequent Contributor
timestamp: May 03, 2016, 03:10:29 pm
content: Quote from: Sbampato12 on May 03, 2016, 01:12:37 pmWow, I'd love to program MCUs in Pascal, but clients tend to frown on such non-mainstream tools. Of course they'll never actually touch the code themselves, but still...

author: @rt
author_rank: Super Contributor
timestamp: May 03, 2016, 03:52:06 pm
content: HiIf you’re writing for dsPic, C-30 is good.It’s simple to replace all logic and math stuff with C syntax. DT’s elapsed timer is now a Microchip sample interrupt routine.LCDOUT is available for free from a lot of sources, and I’ve posted one here you could just ignore the fancy stuff.LOOKUP and LOOKUP2 can be done with a C arrays, and for LOOKUP with constant data, can be declared:Code:int value;int index;int lookup = {0,1,2,3,4,5,6,7,8,9};main (){index = 5;value = lookup;// value now equals 5}The hardware serial ports are easier to use, and have a few bytes buffer.What else.. it will probably pay to look into retargetable pins, and the port latch registers.They are both good things but will be annoying if not read about

author: eeadata
author_rank: Contributor
timestamp: May 03, 2016, 04:27:49 pm
content: Quote from: asgard20032 on May 02, 2016, 11:40:22 pmif i can solve my problem with a 8 bit MCU why to bother 16-18-24-32 bits

author: asgard20032
author_rank: Regular Contributor
timestamp: May 03, 2016, 04:45:26 pm
content: Because 16/32 bit can be cheaper and use less power. 8 bit is only good for the most trivial task or very low pin count matter. And it wouldn't surprise me that with a lower demand for 8 bits, they simply start creating 16/32 bits mcu with low pin count to replace them. In fact, the 16/32/bits already use a smaller die. Smaller die = they can create more of the same device on the same wafer, thus better for the manufacturer. Changing the 8 bits to use a smaller die would mean lot of engineering to be sure all the electrical spec are the same.

author: JPortici
author_rank: Super Contributor
timestamp: May 03, 2016, 05:03:34 pm
content: 32bit usually don't come in less than 48 pins (though there are arm and pic32 even in dip package)pic32 still have embarassing errata.. for one the MZ can't be clocked reliably from a crystaland many peripherals are basically useless when put under minimal stress... i still wouldn't use a MZ if not as an external fpu for a system built around another mcu but even in that case..New dspics have issues too, but you can still work with them and every bug i found out and reported in all the new parts i'm using have a workaround.

author: Sbampato12
author_rank: Regular Contributor
timestamp: May 03, 2016, 06:11:59 pm
content: Quote from: igendel on May 03, 2016, 03:10:29 pmBy now none asked specific compiler language, but I deal with small clients, that aren't engineer. They only ask me a working piece of equipment, they usually doesn't make choice of uC, language... Maybe I'm a little lucky.

author: Howardlong
author_rank: Super Contributor
timestamp: May 03, 2016, 07:27:12 pm
content: Quote from: TheDirty on May 02, 2016, 11:32:18 pmPretty sure MPLAB Xpress only supports 8 bit chips.

author: Howardlong
author_rank: Super Contributor
timestamp: May 03, 2016, 07:44:16 pm
content: Quote from: JPortici on May 03, 2016, 05:03:34 pmFWIW there's an 8 pin NXP Cortex M0 available in DIP, LPC810. I use the 28 pin PIC32s extensively.The MZ EC really was a clusterfandango silicon-wise. The EF is significantly better, but as you say they still couldn't fix the crystal oscillator and the I2C peripheral has significant limitations. Add to that the Harmony nonsense and it's not great. I am confident enough on the MZ EF now to use it in a production device.I still love the whole range. Those predicting the death of 8 bit have been proved wrong again and again over the years. The peripherals, and low power modes, are what keeps them and the 16 bitters alive.For the OP, I recommend XC16. Being dependent on third party compilers has its own complications, and to be fair the compiler quality, particularly nowadays, is excellent. I've used BK Knudsen and CCS over the years but now only use the xc8/16/32 compilers after using C18/C30/C32 before that.

author: Karel
author_rank: Super Contributor
timestamp: May 04, 2016, 06:39:54 am
content: Quote from: Howardlong on May 03, 2016, 07:44:16 pmI agree. Use the XC8/16/32 compilers and set optimization to 1. Avoid the harmony framework.