Microchip XC compilers survey

[boz]

Just noticed Microchip have an anonymous survey on the pricing of their XC pro compilers (the un-crippled ones!)

I'm not holding out much hope but if they are willing to listen to why they are shooting themselves in the foot with a crippled toolset heres your chance to have your say (If the link dont work it is also on the microchip compiler web page)

https://www.surveymonkey.com/r/MPLABXCCompilers

My (humble) opinion is that the XC compilers should be totally unrestricted, but at minimum they should make it unrestricted for non-commercial or open source projects.

[mikeselectricstuff]

I think the biggest foot-shoot is that someone evaluating PICs against the competition may come away with the impression that they have poorer speed & code efficiency purely because of the compiler.

The 16 & 32 bit free ones are a lot less bad than 8 bit.

I hear that they've recently changed the  protection mechanism which was so trivial that they clearly weren't too concerned about lost sales.

BTW They are giving a 15% discount code at microchipdirect .com for completing the survey

[Howardlong]

Just filled it out and received a 15% discount on microchip direct on my next purchase not valid until October, not sure what restriction(s) if any there are on it.

For me both the entry costs and the ongoing maintenance is excessive compared to other vendors.

I use all three pro compilers, and it's $600 pa for maintenance that they sneaked in last year. I used to have the old full C18, C30 and C32 compilers and was grandfathered into XC, but didn't realise that they were going to hit me with an ongoing maintenance fee later on. My Microchip silicon spend is about $10,000pa.

To keep competitive, they need to be aware that they are about six times more expensive than the likes of NXP and TI just for buy in, but even then the crippling of the Microchip compilers is far more intrusive than that of TI and NXP for the free versions.

I've been doing PICs for over a couple of decades, but over the past year or so I've been moving over to TI and NXP ARM for my higher end stuff, although it has to be said this is down to the crap silicon from Microchip recently at their top end rather than the compilers. Add into the mix the compiler pricing, the god awful Harmony framework, two or three years of bug ridden and slow MBLAB X IDE, a forum upgrade that barely worked for six months and it's not hard to see why developers and designers are jumping ship. I do still do plenty on the lower end devices, but I still use the old MPLAB 8 IDE if I can get away with it.

[mikeselectricstuff]

I've not even looked at MPLABX - fortunately 8.x supports the devices I currently use, the only exception being the recent memory-upgraded 32MX170, but a few quick hacks to some config & linker files fixed that!

[Howardlong]

I've not even looked at MPLABX - fortunately 8.x supports the devices I currently use, the only exception being the recent memory-upgraded 32MX170, but a few quick hacks to some config & linker files fixed that!

Indeed, same part, and for the USB MX270 I did pretty the same thing, for the same part, although the simulator crashes, not that I use the simulator, for anything more than the most trivial of scenarios and perhaps for honing your own hand coded optimisation, the simulator has almost no use for me. I hacked the MX150F128C VTLA part that I never intend to use from the 150F128B part and added the extra flash, RAM and a few config bits for the additional code protection coverage.

Do you know if you can add your own part number rather than me having to remember that the MX150F128C is in fact an MX170F256B?

You're not in bad company, a buddy of mine who works for MCHP out of Phoenix as a consultant on big projects for customers confided that he never uses MPLAB X either. I would say MPLAB X is reasonably stable now, and has been for nearly a year, but it took them about three years. The edit-compile-program-debug step it still a bottleneck though. This seems to be common among Java based cross platform dev environments, the same applies in LPCXpresso too and to a lesser extent Code Composer Studio, both Eclipse based rather than Netbeans. I assume that it's Java JNI fighting its way through to the debugger on the USB port, or shelling out to some loosely coupled executable somewhere. Isn't Java meant to be as fast if not faster than native code? **cough**

[mikeselectricstuff]

I've not even looked at MPLABX - fortunately 8.x supports the devices I currently use, the only exception being the recent memory-upgraded 32MX170, but a few quick hacks to some config & linker files fixed that!

Indeed, same part, and for the USB MX270 I did pretty the same thing, for the same part, although the simulator crashes, not that I use the simulator, for anything more than the most trivial of scenarios and perhaps for honing your own hand coded optimisation, the simulator has almost no use for me. I hacked the MX150F128C VTLA part that I never intend to use from the 150F128B part and added the extra flash, RAM and a few config bits for the additional code protection coverage.

That's exactly what I did - with that same part!

Do you know if you can add your own part number rather than me having to remember that the MX150F128C is in fact an MX170F256B?

It was a while ago - I think I did tinker around a bit to try this but couldn't figure out where MPLAB gets its device list.

You're not in bad company, a buddy of mine who works for MCHP out of Phoenix as a consultant on big projects for customers confided that he never uses MPLAB X either. I would say MPLAB X is reasonably stable now, and has been for nearly a year, but it took them about three years. The edit-compile-program-debug step it still a bottleneck though.

I just take the "aint broke - don't fix" approach - I've been using MPLAB 8.x for years & it does the job so why change. I almost always use a compile->program cycle, and only use the debugger when really  necessary to find a particular issue.
Speed of the  change/compile/program/run cycle is totally crucial for me - anything more than a few seconds gets really annoying. 
 

[jnz]

So glad I'm in the process of dumping Microchip for ARM. They have done a LOT lately to shoot themselves in the foot.

Between the XC compilers, the MPLabX disaster, their 8bit parts have received zero development in years despite broken peripherals and their 32-bit stuff, their typical part cost is crazy high... Why would I even bother anymore!?

Best decision I've made recently was to run away from them. I filled out the survey tho.

[RogerRowland]

Just filled it out and received a 15% discount on microchip direct on my next purchase not valid until October, not sure what restriction(s) if any there are on it.

"Not valid until October"? I just took the survey and the 15% one-off discount said "This is a single-use code that expires October 31, 2015"

[Howardlong]

Just filled it out and received a 15% discount on microchip direct on my next purchase not valid until October, not sure what restriction(s) if any there are on it.

"Not valid until October"? I just took the survey and the 15% one-off discount said "This is a single-use code that expires October 31, 2015"

Typo on my part.

[matkar]

I never switched to MPLabX either and by reading the above I'm happy I didn't. I stick with MPLab 8.x and the old C compilers. If you know their quirks they do the job just fine.
Performance to price ratio is very poor in regard to some ARM chips. I tend to choose an ARM over a PIC to often these days.

[spudboy488]

I'm still using MPLAB-8 too. Along with the demo HiTech C compiler, it does what I need with the small number of parts I typically use (18F46K22, 16F887, and occasionally 16F689).

Probably a discussion for another thread but the issue I have with moving to ARM is the small number of 5V parts. I have a relatively large stock of 5V peripherals that would require extra interfacing if they were to be used in an ARM circuit.

[nctnico]

The majority (say 95%) of NXP's ARM controllers have 5V tolerant I/O. If your peripherals are TTL level compliant then you should have no problems interfacing them.

[Throy]

What don't you guys like about the MPLabX?  I first started using PICs about 3 years ago with MPLab8, due to a job change.  Before that I had only used Freescale and their Codewarrior IDE.  That was a huge change for me in IDEs, and I struggled at first with MPLab8 but eventually got use to it.  I then switched to the MPLabX about a year and a half ago.  At first I had a lot of problems with RealICE and losing it's connection to MPLabX, having to unplug and plug it back in about every 30 minutes.  I haven't had this problem for a while now, and I find it's more comfortable for me to develop in the MPLabX than in version 8. 

I do have to say though, I'm pretty disappointed in their compilers.  I've ran into a few bugs with them.  With Freescale I had problems once and while too but not as often as I do with Microchip's.

[Howardlong]

Primarily for me it's the compile-program-debug/run step as I mentioned earlier, it's soooo sloooow in comparison to the old school, but tightly coupled, MPLAB 8.

Secondly it was the sheer bugginess of it. I would forever be having problems with debuggers, but they seem to have cleared that up about a year ago. Not before time though.

MPLAB 8 has it's character building featured too of course, but productivity-wise, particularly having used it for many years, I prefer it, although slowly but surely it is being marginalised.

XC8 is buggy, but XC16 and XC32 are reasonably good. I can't say I've found a compiler bug in XC16 or XC33 in some time. The same is not true for XC8 where it's not uncommon for it to spit its dummy out. However, before XC8 I used the Knudsen Data CC5X and CC8E for PIC16/PIC18, and more recently C18 for PIC18. With the Knudsen Data compilers you have to do a lot of work yourself, including taking care where your data is stored in what RAM bank. They also couldn't deal with anything more than very simple arithmetic in single statements. C18 was better but only supports PIC18.

The whole physical debugger interface thing has long been a problem for many vendors, particularly when many were parallel port based, and the move to protected mode operating systems. With USB being so ubiquitous, and with it being so mature now, it seems crazy that there are still problems in this area, but regretfully there are. Lots of random plugging in and unplugging, fannying about with reinstalling drivers, rebooting the computer, you name it.

The RealICE, ICD 3 and PICkit 3 all need their various firmwares being updated when you switch cores or between MPLAB 8 and MPLAB X, and in the case of RealICE and ICD 3 you need to switch drivers too if you switch IDEs. Sometimes you even need to manually upload the firmware to make the debugger work. It's yet another time consuming and ultimately badly thought out design from the vendor.

But as I've said many times before, this all pales into insignificance compared to the PIC32MZ silicon releases and Harmony Framework, 18 months since release and still a year away from being useful in production, coincidentally much the same timeframe as MPLAB X.

Having said that, I do love some of the newer peripherals on even the PIC16s, but they can take some learning.

[ale500]

MPLABX could be faster... User input is slow and column-mark copy/paste doesn't work, it also doesn't work in Eclipse, but at least eclipse is faster .

I have a PICKit3 and debugging is really slow. But I develop in a pc and test/debug the code on the PC and then try it in the target and only debug target-specific issues...

[poorchava]

Have had to do with XC8 only, and I didn't like it. First of all there's the artificial code bloating thing in the free version so that they could brag how standard version reduces code size.

They could come clean about it and just write 'free version produces code with artificially lowered performance as a form of limitation' which would be dumb,  but at least honest.

I also don't like how long it takes to compile even a simple program. I've read that it's because of how include files are constructed (basically all possible headers are included at all time through xc8.h and this takes serious time for the compiler to parse).

I as it stands now I would avoid using Microchip 8 bis parts (aside from the fact that they are lower performance and typically more buggy than Cortex-M0 solutions from other vendors).

[c4757p]

Yup, I gave up on 8-bit PICs a while ago because their compiler is such a piece of shit. Perhaps the commercial ones aren't, but no other microcontroller I've used requires me to buy a compiler. It's not the 1980s anymore...

Add to this that the architecture is just generally not conducive to compilers - why do you think GCC doesn't do PICs? - and you have a real turkey of a platform.

[AndyC_772]

I use 8 bit PICs a lot. Find me a better family that has an equivalent of the CTMU, and which can run directly from the 5V supply I need for external analogue circuits, and I'll consider switching.

I've filled in Microchip's survey anyway, because the whole idea of crippling a compiler and then charging for the un-crippled version is... well, we all know how sane it is in a world where gcc is free and Cortex-M0 exists.

[c4757p]

CTMU might be hard. Atmel has similar on the xmega series, but those don't do 5V. Likewise, the mega series does 5V but most don't have the comparator current source.

Thankfully, I rarely need either.

[aon]

Just filled it out and received a 15% discount on microchip direct on my next purchase not valid until October, not sure what restriction(s) if any there are on it.

"Not valid until October"? I just took the survey and the 15% one-off discount said "This is a single-use code that expires October 31, 2015"

Typo on my part.

FWIW, the discount code is combinable with others, which is nice considering the way things usually tend to be. 40% off an order if you happen to be eligible for their student discount, not bad at all...

[Howardlong]

MPLABX could be faster... User input is slow and column-mark copy/paste doesn't work, it also doesn't work in Eclipse, but at least eclipse is faster .

I have a PICKit3 and debugging is really slow. But I develop in a pc and test/debug the code on the PC and then try it in the target and only debug target-specific issues...

.... and the target-specific issues are usually most of them unless all you're doing is flashing an LED :-(

[westfw]

The survey doesn't look like it is asking the right questions :-(

[ale500]

No, is it not, because assumes that you accept their business model, which many of us don't. There is a comment area, I wrote there that the compiler should be free because it is based on GPL code . Their object code format is the same as mips elf. There may be a very high quality compiler for mips, but from what I read it is not gcc. Well, for the time being I am compiling outside of mplabx with optimizations and then linking the lib, not the best...

Did someone compare the execution time of mips16 code vs mips ? The code is smaller, but faster... I don't know...

[westfw]

Only the pic32 is MIPS.  MIPS gcc is supposedly pretty good (run all sorts of routers, for instance.) 
PIC24 (16bit) compiler is also gcc-based.
I don't know whether Microchip intentionally disables normal gcc optimizations, or whether they have additional proprietary optimizations that are unavailable in the free versions.  My impression was that they had an equivalent of -lto before gcc did.
Presumably for MIPS, you could grab an OTS MIPS gcc and add newlib nano/etc (I think that's essentially what the MPIDE folk did for their arduino-compatible thing.)

The 8-bit PIC compilers are fully proprietary (and the architectures are so far from gcc's model that there's no hope of a PIC8 gcc.)

As a potential customer, I'd much rather have the "evaluation" version of the commercial compiler have a limited code size, or be tied to eval boards, like ... almost every other vendor.   Compiler vendors should never admit that their compilers will generate code as bad as some of the PIC8 examples that were floating around (although I've heard that the latest "less optimized" code is a lot better than it used to be.)  This happens to be the same thing I want as a hobbyist...  (OTOH, some of the available libraries: tcp, usb, etc, can quickly blow past most otherwise-reasonable code size limits.  Though I've heard that they also quickly blow past chip-size limits without optimization, too...)

[depot]

What don't you guys like about the MPLabX?  I first started using PICs about 3 years ago with MPLab8, due to a job change.  Before that I had only used Freescale and their Codewarrior IDE.  That was a huge change for me in IDEs, and I struggled at first with MPLab8 but eventually got use to it.  I then switched to the MPLabX about a year and a half ago.  At first I had a lot of problems with RealICE and losing it's connection to MPLabX, having to unplug and plug it back in about every 30 minutes.  I haven't had this problem for a while now, and I find it's more comfortable for me to develop in the MPLabX than in version 8. 

I do have to say though, I'm pretty disappointed in their compilers.  I've ran into a few bugs with them.  With Freescale I had problems once and while too but not as often as I do with Microchip's.

I agree.  Their hardware is nice and fairly cheap, their software is mostly dumb (and I don't want to pay for it).

Actually they are doing neat things with new 8 bit pics adding a "Configurable Logic Cell" where you can put in a few gates and latches or flip flops.  Not more than a handful, but a neat thought.  I guess they'll put something similar on the 16 and 32 bit pics eventually.

Their code configurator thing might have some utility once they put it on their 32 bit pics.  It has a diagram for planning the use of pins and it helped me set up a first CLC project.