Microchip XC compilers survey - Page 1
Forum section: electronics / general

author: boz
author_rank: Regular Contributor
timestamp: May 26, 2015, 10:35:21 pm
content: 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/MPLABXCCompilersMy (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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: May 26, 2015, 11:13:19 pm
content: 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

author: Howardlong
author_rank: Super Contributor
timestamp: May 26, 2015, 11:19:32 pm
content: Just filled it out and received a 15% discount on microchip direct on my next purchasenotvalid 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: May 26, 2015, 11:53:13 pm
content: 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!

author: Howardlong
author_rank: Super Contributor
timestamp: May 27, 2015, 12:31:38 am
content: Quote from: mikeselectricstuff on May 26, 2015, 11:53:13 pmIndeed, 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**

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: May 27, 2015, 08:53:45 am
content: Quote from: Howardlong on May 27, 2015, 12:31:38 amThat's exactly what I did - with that same part!QuoteIt 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.QuoteI 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.

author: jnz
author_rank: Frequent Contributor
timestamp: May 27, 2015, 04:30:16 pm
content: 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.

author: RogerRowland
author_rank: Regular Contributor
timestamp: May 27, 2015, 05:58:18 pm
content: Quote from: Howardlong on May 26, 2015, 11:19:32 pm"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"

author: Howardlong
author_rank: Super Contributor
timestamp: May 27, 2015, 06:38:49 pm
content: Quote from: RogerRowland on May 27, 2015, 05:58:18 pmTypo on my part.

author: matkar
author_rank: Regular Contributor
timestamp: May 28, 2015, 10:32:09 pm
content: 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.

author: spudboy488
author_rank: Regular Contributor
timestamp: May 29, 2015, 11:34:16 am
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 29, 2015, 03:54:05 pm
content: 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.

author: Throy
author_rank: Regular Contributor
timestamp: May 29, 2015, 04:06:09 pm
content: 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.

author: Howardlong
author_rank: Super Contributor
timestamp: May 29, 2015, 06:39:17 pm
content: 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.

author: ale500
author_rank: Frequent Contributor
timestamp: May 30, 2015, 05:05:52 am
content: 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...

author: poorchava
author_rank: Super Contributor
timestamp: May 30, 2015, 10:49:11 am
content: 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).

author: c4757p
author_rank: Super Contributor
timestamp: May 30, 2015, 10:57:15 am
content: 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 tobuy 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.

author: AndyC_772
author_rank: Super Contributor
timestamp: May 30, 2015, 11:55:09 am
content: 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.

author: c4757p
author_rank: Super Contributor
timestamp: May 30, 2015, 12:17:14 pm
content: 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.

author: aon
author_rank: Contributor
timestamp: May 30, 2015, 12:40:05 pm
content: Quote from: Howardlong on May 27, 2015, 06:38:49 pmFWIW, 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...

author: Howardlong
author_rank: Super Contributor
timestamp: May 31, 2015, 11:20:15 pm
content: Quote from: ale500 on May 30, 2015, 05:05:52 am.... and the target-specific issues are usually most of them unless all you're doing is flashing an LED :-(

author: westfw
author_rank: Super Contributor
timestamp: June 01, 2015, 03:26:48 am
content: The survey doesn't look like it is asking the right questions :-(

author: ale500
author_rank: Frequent Contributor
timestamp: June 01, 2015, 04:31:18 am
content: 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...

author: westfw
author_rank: Super Contributor
timestamp: June 01, 2015, 10:55:24 pm
content: 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...)

author: depot
author_rank: Contributor
timestamp: June 06, 2015, 01:20:47 am
content: Quote from: Throy on May 29, 2015, 04:06:09 pmI 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.

author: Tomorokoshi
author_rank: Super Contributor
timestamp: June 06, 2015, 02:02:09 am
content: I have the same question for them that I had for Freescale:"Are you in the processor business or the compiler business?"They're trying to get revenue both ways. There is no use whatsoever for a PIC compiler for anything except a PIC - they get a PIC sale if the compiler is used. Same for CodeWarrior on Freescale.Nothing shuts down an evaluation faster than having to deal with a purchase order. I'm simply not going to waste my time on it, as the "free" versions won't produce code worthy of being shipped in a product.At least Microchip isn't so insane that they are using network licenses for them.

author: JTR
author_rank: Regular Contributor
timestamp: June 06, 2015, 04:12:14 am
content: Quote from: westfw on June 01, 2015, 03:26:48 amHave to agree with this. Did the survey anyway. I mean 15% off is 15% off even for an assy coder like me.

author: Tomorokoshi
author_rank: Super Contributor
timestamp: June 06, 2015, 04:50:03 am
content: Kind of a bogus survey. Looks like an amateur attempt at collecting "positive reinforcement" marketing data for a Power Point.

author: Ian.M
author_rank: Super Contributor
timestamp: June 06, 2015, 09:30:10 am
content: Quote from: Tomorokoshi on June 06, 2015, 02:02:09 amDon't be so sure about that!The XC compiler licence manager uses network or local licences. Unfortunately some versions have had the network given priority with the result that compilation can hang for about 30 seconds on every build while it is looking for the nonexistant LAN licence server. The current versions are OK, but I wouldn't be surprised to see that bug again in a future version.It also 'phones home' for initial activation, which while understandable, is going to be a right P.I.T.A if you need to reinstall the toolchain to support a legacy product ten years down the line.

author: Howardlong
author_rank: Super Contributor
timestamp: June 06, 2015, 09:56:55 am
content: Quote from: Ian.M on June 06, 2015, 09:30:10 amI fell foul of the unexplained compiler hanging a year or so ago, of course Microchip employees couldn't reproduce it because they're on network licenses, not Workstation node locked ones, so it took a non-Microchip person to realise that copying the license manager from an earlier version fixed the problem.I've had more than my fair share of grief with Microchip compilers and licensing. I have all three of them. I lose about a day of productivity every year trying to fix licensing problems with my Workstation node locked versions because the licensing manager breaks. This can be for a number of reasons, but key to this is that on node locked licensing the installer picks the MAC address of a random NIC on your machine and phones home with that information. The hostname is also sent with the information but other than metadata I don't know if it's used in the licensing enforcement algorithm.Each node locked license has three lives, and Microchip allow a single user to use the license on three different machines. Generous enough, I have it on my main desktop machine and a field laptop. However, if, during installation or upgrade, a different MAC address is chosen by the installer to the last time for whatever reason, it chews up another one of those lives.So the moral of he story is to keep a record of the MAC address you compiler(s) are tied to and make sure during installation you use that one rather than let the installer pick one or you'll lose one of your lives.There is also no way to revoke your old unused licenses yourself online, say if you move to a new machine with different MAC addresses, you must email Microchip and wait for a response back. A simple web page with your licensing details would be all that is needed, you pretty much have to register anyway as far as I can see.One further point is to take care if you use their compilers in VMs, as these have their own way of managing MAC addresses.The impact that broken licensing has for bone fide users is really not acceptable, when you can't rely on your toolchain to work due to a flakey and arbitrary licensing scheme bolted on top of it it really disenfranchises you. It's hardly surprising that there has been so much effort spent circumventing it as a result!

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: June 06, 2015, 10:19:52 am
content: Quote from: Howardlong on June 06, 2015, 09:56:55 amI have licenses for all 3 but use the hacked versions as it's just plain quicker.Apparently later versions use a less trivial protection system, but haven't had the need to upgrade to these.

author: Howardlong
author_rank: Super Contributor
timestamp: June 22, 2015, 01:41:04 pm
content: Has anyone had any luck applying the discount code from this? I just placed a production order but it didn't do anything to the invoiced amount. I took a picture of the web page with the discount code having completed the survey. I've tried keying it in twice now, so I am pretty sure I have the code that was offered. There didn't appear to be any restrictions on its use other than it's single use and to use it before October 31 2015. Bearing in mind it's a production order, 15% would be quite a healthy discount!