embeddedgurus.com: "An open letter to the developers of the MPLAB IDE"

[jerry507]

That's a very strange graphic. I have no idea why you'd include smartcards, touch screen controllers and other asics in microcontroller revenue.

My impression for several years has been that Atmels actual microcontroller business isn't particularly healthy and Microchip has been doing better.

I dislike Atmels products because they seem more expensive than comparable PIC devices with little to show for it. That said, the toolchain can be better and Microchips XC8 compiler is in a sad state. It's gotten better but has remained significantly worse than the C18 compiler it replaced and much worse than the XC16 or XC32 compilers at the higher end. The 16 bit products from Microchip are quite compelling because of good cost and good peripheral support. While the 32 bit products are nice, why wouldn't I use an arm at that point?

Professionally, ARM cores have replaced everything. Why not when I can buy a M0 for less than a buck @1k?

[true]

go to hack-a-day, then.  what percent of pic projects do you see vs arduino?

hackaday has a total hard-on for arduino / attiny85 (even when used completely inappropriately), 3D printers, and quad/hexrotors aka "drones" - anything in the world involving one will probably end up there even if it isn't deserving of a second pair of eyes ever looking at it.

That said, my PIC32 project made it there a few months back. (The writeup was wrong on all the details though, about the project and about the PIC, as is normal for anything hackaday not involving an arduino)

[mikeselectricstuff]

I can buy preprogrammed chips from MicrochipDirect for a few pennies more. AFAIK no other MCU manufacturer does this, at least for small (<1000) qtys, or as easily. Even if all that gets preprogrammed is a bootloader, this can save a lot of time and hassle in production. 

IIRC Digikey can do this for most of the atmels they have in stock, at no expense in basically any quantity (but I haven't tried it yet).

I'd be highly surprised if this was "at no extra expense", unless you're buying serious quantities or expensive parts.

[ecat]

go to hack-a-day, then.  what percent of pic projects do you see vs arduino?

hackaday has a total hard-on for arduino / attiny85 (even when used completely inappropriately), 3D printers, and quad/hexrotors aka "drones" - anything in the world involving one will probably end up there even if it isn't deserving of a second pair of eyes ever looking at it.

So, anything which ranks highly in search engine keyword lists. They lavish the same gushing praise on the trivial and downright dangerous as they do on genuinely novel and innovative projects. They certainly do publicise some good stuff but I find the signal to noise ratio so low I've given up visiting their site.

[hans]

Ha, yeah, Hackaday has turned to crap postings the last few years IMHO. Is there any other news/blog site noteworthy of checking out for cool designs?

This letter was written back in 2011!!! And it is about the old (outdated) MPLAB IDE. The main IDE now is MPLAB X and because it's based on Netbeans it is supported on Linux too. And it is MUCH better than the old MPLAB IMHO. Although there are still some folks out there who claim the IDE is awful, i have to say that my experience with it is VERY positive. Lately i'm doing some work with Keil, and it crashed on me twice, without any warning! One of the crashes corrupted my project file, so i had to start over by creating a new project! Never had that experience with the MPLAB X.

I think people can share similar experiences for all IDE's. I can say I've had to recreate a MPLAB X project because otherwise the debugger couldn't figure out what line C code complies to what assembler (PIC24 project).
I've ranted more about MPLAB X in the past, and it's getting better now, but the slowness of Netbeans still bothers me. I say this on a fast machine (SSD/16GB RAM/i5 3570K CPU), and any non-Java based IDE beats it in terms of speed any day of the week. To get rid of that, ideally an IDE needs to step up with QT.
(As a side note: i'm still eager to try out Qt developer environment for ARM, including debugging. I think it should be possible, given there is a GDB server for ARM + open ARM GCC tools).

Microchip offers FREE editions of their compilers for all their families, and XC8 has become better since version 1.21.

Yep, I still can't imagine people say Microchip is not free. They provide a reasonable set of compilers that work out of the box in MPLAB X.
PICKIT 2/3 is ~50 euro's for a standalone programmer + debugger, (PK2 can also be used as a AVR programmer using avr-dude). In Atmel world this buys you an AVR dragon, but they forgot to make an enclosure for that. I guess it's a close call.

And if you want you can still use the legacy HI-TECH C compiler for the 8 bits in MPLAB X in lite mode. And PIC18 + XC8 free or HI-TECH C lite will OUTPERFORM the Arduino anyday, so it is your loss for not using the PIC.

It will probably outperform programs written using the Arduino runtime. That's horribly slow, where I recall a simple digitalWrite action can take up to tens of microseconds.

As in the architecture of PIC16/18, it's actually completely terrible compared to anything else and modern. Only 1 accumulator register, banked memory, Fosc/4 clock speed, etc. But it works.
There is a reason it still uses HI-TECH compiler. Microchip failed themselves to make a decent one, and therefore bought out HI-TECH. They made attempts to port it to GCC or LLVM, but that failed too, as the architecture was so odd it couldn't made to fit with modern compilers.

Also the XC8 compiler has it's limitations, and all MCP compilers speak a very strict dialect of C to much annoyance. In addition, XC8 optimizations at the FREE level are to say the least "odd".

I think this is a well known story for those who have argued with an Atmel fanboy, as they will always bring this up. And I regard it as true, but then again I try to avoid using the PIC16 & 18s a bit.

Luckily though, their XC16 & XC32 compilers are GCC (with O1 optimize which does most good stuff).

Moreover it's not hard to figure out how to run all compilers in their most optimal setting. As XC16 and XC32 are based on GCC, their source code is found online, including the part that speaks to the license manager, which means it's actually incredibly easy to figure out a replacement manager to run it in original intentions 

As for the demise of the 8-bitters, it will happen, but only for more complicated projects. Currently i'm working on 2 projects that are so trivial, (simple user interfaces) even the PIC16 series is overkill. I think that the 8-bitters will continue to hold this (low end) market for the years to come.

I'm designing a digital power supply at the moment, and I'm likely to put a PIC24 or STM32 chip in it. Mostly for cost/performance (which I don't really need, though), but also so I have similar/identical code for most of my projects (saves time).
I would only use 8-bit chips if for package or power consumption.

[dannyf]

hackaday has a total hard-on for arduino...

It is sad that one would pick hackaday as a yardstick for how a mcu does; It is sadder that after it was pointed out repeated why that's wrong, it still failed to be comprehended, .

In Atmel world this buys you an AVR dragon

Or 10+ arvasp.

As in the architecture of PIC16/18, it's actually completely terrible compared to anything else and modern.

Agreed.

significantly worse than the C18 compiler

Microchip did itself a huge favor by killing C18 - that compiler is truly a total crap.

the XC16 or XC32 compilers

PIC24 + C30/XC16 is a nice combination. PIC32 seems to have a crippled peripheral set vs. PiC24.

[ecat]

PK2 can also be used as a AVR programmer using avr-dude

Risking a quick diversion off topic, do you have any links to the info on this? Last time I looked I came up with something in Russian with a very suspicious chain of half broken html links and some other method I didn't like the look of but cannot quite remember at the moment.

[fcb]

I've used PIC's solidly since 1991.  From time to time I've looked at other vendors, but keep returning to PIC.

More recently I've wanted more horsepower in a project, but couldn't stand the learning curve with ARM (I still code in assembler) - I got round the problem with a bit of neat design and XC9572 cpld - still cheaper solution.

Microchip and Atmel are both successful because they understand their customer base, much the same as the generic 8051 clones do. They must be doing something right?

I will stick with Microchip as I haven't been let down once by availability, and I know I can buy a 16C54 to drop into a 20+ year old design... Try and get a Z8, COP8, ST7 off-the-shelf at reasonable prices or qty.

MPLAB X - I haven't tried this for a few years - it sucked when I did and I haven't gone back since.

On another note, I found myself reviewing a 16F54 the other day for a project, I forgot how simple the instruction set was and how much fun it is to code for.

[dannyf]

do you have any links to the info on this?

It is truly experimental, and I think the efforts stop'd maybe 5 - 7 years ago.

[ecat]

do you have any links to the info on this?

It is truly experimental, and I think the efforts stop'd maybe 5 - 7 years ago.

So, what I found is all there is, thanks for the confirmation

[dannyf]

8bit mcus are pretty much at no growth but not loosing shares, 16 bits are declining and 32 bits are climbing (mobile stuff of course)

A lot of the "observations" will depend on how you define the market: for example, SIM/RFID typically contain a mcu. Think about how many ID cards are out there, or phone cards, :0.

I think most people would not include those figures + phones in their definition of "mcu market". Automotive is generally included in mcu market definitions.

It is generally accepted that 16-bit ship surpassed 8-bit a couple years ago. Both 16-bit and 8-bit are on a decline in terms of shares but increasing in terms of shipment. ASP on 8-bitters has been on a steady decline for more than a decade now.

I don't think 32-bit has surpassed 16-bit in terms of shipment but did so in terms of $$$.

I would say that biggies in this market are Renesas and Freescale - I would put their combined shares in the 50%+ territory. Infenion and NXP/ST are fairly large too. Fujisu/Spansion is large but only domestically.

TI was up there due to their OMAP which they exited recently.

After that, just some niche players like Silabs (mixed signal), Cypress (USB), Analog (analog/mixed signal).

[icon]

is it true that they do insert no-ops to cripple the free versions? 

Spurious 'goto's seem to be the order of the day. It's perhaps some artefact of the compilation process, but they're scattered everywhere, bulking out the code.

As Hans points out, it's no great effort to unlock the other versions.

Regards
John

[linux-works]

what I'd like to know (genuinely asking) is if MC creates the no-ops or bad code on purpose or accident.

again, my only source was from gerry's write-up on MC's compiler tools and his implication, as I read it, was that the free tools had the no-ops inserted on purpose, to 'motivate' you to buy the paid-for tools.

is this true or not?

I really hope its not actually true, as stated.  it seems quite hostile for a company to do this.

story: I worked at DEC many years ago and I did hear the story about how we made 2 VAX systems (I forget if it was the 750 or 780 series) and we would allow customers to upgrade from one to the other by paying the upgrade fee.  it turns out that there was no actual hardware change but we'd dispatch field service (we jokingly called them 'field circus') to swap out the color of the metal skins and do a microcode upgrade.  the microcode - you guessed it - had the no-ops removed and so the end effect was that the VAX ran almost twice as fast with that 'upgrade'.  the metal skin color change was just 'marketing' and to let the customer think something real had been changed.  this angered a lot of people and I've heard the story told by many old DEC guys, so I do believe it was true.  the MCP thing makes me think of this shenanigan; and it was unacceptable back then and still is, now.

so, is this on purpose or just sloppiness?

[ecat]

what I'd like to know (genuinely asking) is if MC creates the no-ops or bad code on purpose or accident.

again, my only source was from gerry's write-up on MC's compiler tools and his implication, as I read it, was that the free tools had the no-ops inserted on purpose, to 'motivate' you to buy the paid-for tools.

is this true or not?

I really hope its not actually true, as stated.  it seems quite hostile for a company to do this.

story: I worked at DEC many years ago and I did hear the story about how we made 2 VAX systems (I forget if it was the 750 or 780 series) and we would allow customers to upgrade from one to the other by paying the upgrade fee.  it turns out that there was no actual hardware change but we'd dispatch field service (we jokingly called them 'field circus') to swap out the color of the metal skins and do a microcode upgrade.  the microcode - you guessed it - had the no-ops removed and so the end effect was that the VAX ran almost twice as fast with that 'upgrade'.  the metal skin color change was just 'marketing' and to let the customer think something real had been changed.  this angered a lot of people and I've heard the story told by many old DEC guys, so I do believe it was true.  the MCP thing makes me think of this shenanigan; and it was unacceptable back then and still is, now.

so, is this on purpose or just sloppiness?

If the 1st stage of the compiler simply translates source into assembly code (or something similar) and does so by using simple, one size fits all occasions template code then it is quite possible that nops and gotos are inserted at this stage. All 'for' loops have the same, general, inefficient but flexible template, all if statements have their own general template etc.

Subsequent compiler stages perform various optimisations, one of those includes removal of superfluous template code.

So, yes, the superfluous code would be put there deliberately but not out of malice, rather as a way of simplifying the compiler and giving the optimisation passes something to work with.

[baljemmett]

what I'd like to know (genuinely asking) is if MC creates the no-ops or bad code on purpose or accident.

It's unlikely that anybody outside Microchip actually knows the answer to that for sure - we're unlikely to have seen any "hey, make this generate crap code so they cough up for the paid version" memos, after all!  However, from reading the output on some of my projects, it doesn't really seem to have anything 'maliciously' bad; it's mainly just unoptimised and/or naïvely-generated code.  Things like calculating a value, storing it in a temporary and then immediately loading it back, or a goto over some conditional code that lands right on another goto.  Even a simple optimiser would take care of fixing a lot of it up, so it wouldn't have been a problem to emit code like that until they started offering a free version without one.

[dannyf]

my only source was from gerry's write-up...

Simple common sense dictates that unless this "gerry" was intimately involved in the development / decision making of this compiler, what he said is inconclusive at best.

[retrolefty]

what I'd like to know (genuinely asking) is if MC creates the no-ops or bad code on purpose or accident.

again, my only source was from gerry's write-up on MC's compiler tools and his implication, as I read it, was that the free tools had the no-ops inserted on purpose, to 'motivate' you to buy the paid-for tools.

is this true or not?

I really hope its not actually true, as stated.  it seems quite hostile for a company to do this.

story: I worked at DEC many years ago and I did hear the story about how we made 2 VAX systems (I forget if it was the 750 or 780 series) and we would allow customers to upgrade from one to the other by paying the upgrade fee.  it turns out that there was no actual hardware change but we'd dispatch field service (we jokingly called them 'field circus') to swap out the color of the metal skins and do a microcode upgrade.  the microcode - you guessed it - had the no-ops removed and so the end effect was that the VAX ran almost twice as fast with that 'upgrade'.  the metal skin color change was just 'marketing' and to let the customer think something real had been changed.  this angered a lot of people and I've heard the story told by many old DEC guys, so I do believe it was true.  the MCP thing makes me think of this shenanigan; and it was unacceptable back then and still is, now.

so, is this on purpose or just sloppiness?

 I worked as a field service engineer for a different minicomputer firm from the mid 70s for around five years, Varian Data Machines. We 'targeted' the scientific application market (along with small businesses) so had quite a few high performance options available at extra costs.

 A few of these options (like high speed DMA memory access by peripheral controllers) only required jumper changes on some of the boards. Obviously this was implemented as a marketing policy, but I always felt a little guilty the few times I had to implement such upgrades. The majority of the time such options were factory set up when the customer's system was being configured.

 Buying our machines was not unlike buying a new car at the time, the delivered price with options might be double the price of the starting list price. Option list was huge.

 Probably the most profitable part of our business was the field support service, typically ran about $1,200 a month. Otherwise one paid by the hour plus parts, but had no guarantee on response time if not on the service contract.

 Still all in all the minicomputers at the time allowed businesses to utilize computers at very much lower cost relative to the mainframe computer companies at the time, IBM, Univac, etc.
 
 

[mikeselectricstuff]

But when 16 & 32 bit parts are cheaper, who cares?

8 bit still has some important advantages. Power consumption for many tasks is lower, performance for some tasks is better (especially low latency stuff, interrupt handling etc.)

I think this is as much about differences in specific architectures than 8 vs.16/32. Most applications will be dealing with at least 16 bit data, so 8 bit MCUs will be using more cycles. 16/32 bit tends to be on newer, smaller processes at lower voltages, which will save power in some circumstances.
Even quite low-end devices tend to  have smarter peripherals like FIFO'd UARTS and DMA, reducing any minor latency issues.

[neslekkim]

my only source was from gerry's write-up...

Simple common sense dictates that unless this "gerry" was intimately involved in the development / decision making of this compiler, what he said is inconclusive at best.

This "Gerry" is btw this blogpost: http://gerrysweeney.com/microchip-pic-chips-could-have-been-the-power-behind-arduino/
His opinions, and I guess others have similar after struggling with useless compilers.

is this true or not?

I really hope its not actually true, as stated.  it seems quite hostile for a company to do this.

I guess this is not the only post about this:
http://www.t4f.org/articles/optimization-of-microchip-pic-xc8-compiler-in-free-and-pro-mode/

But remember that this compiler is acquired from Hi-tech, a company that had good reasons to do this..  Just read the conclusion in that post.

[dannyf]

This "Gerry" is btw this blogpost: http://gerrysweeney.com/microchip-pic-chips-could-have-been-the-power-behind-arduino/

So?

That page is high on rants and low on facts. He didn't even attempt to provide any substantiation that Microchip deliberately inserted nops to lower the performance of the free mode, a contention of this discussion.

His opinions, and I guess others have similar after struggling with useless compilers.

I would imagine that billions of PICs coded with Microchip / Hi-Tech compilers would suggest that those compilers aren't "useless".

You certainly are on solid footing accusing them of being not free (for the non-free versions anyway), of having poor performance, of offering subpar user friendliness, etc.

You are without basis accusing them of being "useless".

Unless of course you define "useless" differently.

[neslekkim]

Useless in the way that an compiler fills the resulting code with instructions that does not belong there, just to fill up already tight memoryspace, if you pay $999 you get an option that does not add that code.
But as that last blogpost mentions, it seems like microchip is removing parts of this "extracode"/fillercode..

[dannyf]

Useless in the way that an compiler fills the resulting code with instructions that does not belong there, just to fill up already tight memoryspace, if you pay $999 you get an option that does not add that code.

So your BMW is useless because my Ferrari gets to the supermarket 0.2 second faster,

Being able to tell the difference between "less useful" and "useless" may be useful.

[dannyf]

it seems like microchip is removing parts if this "extracode"/fillercode..

Newer XC8 is actually quite respectable. I did a benchmark of dhrystone on pic18, among other mcus. The XC8 free is on par with PICC18 pro, and XC8 pro is about 20% faster than PICC18 pro. I don't recall exactly which version of XC8 I used (could be 1.21).

[gocemk]

And if you want you can still use the legacy HI-TECH C compiler for the 8 bits in MPLAB X in lite mode. And PIC18 + XC8 free or HI-TECH C lite will OUTPERFORM the Arduino anyday, so it is your loss for not using the PIC.

It will probably outperform programs written using the Arduino runtime. That's horribly slow, where I recall a simple digitalWrite action can take up to tens of microseconds.

Yes, that's exactly what i meant. I was not referring to a direct comparison between Microchip PIC vs. Atmel AVR, only vs. the Arduino runtime.

As in the architecture of PIC16/18, it's actually completely terrible compared to anything else and modern. Only 1 accumulator register, banked memory, Fosc/4 clock speed, etc. But it works.
There is a reason it still uses HI-TECH compiler. Microchip failed themselves to make a decent one, and therefore bought out HI-TECH. They made attempts to port it to GCC or LLVM, but that failed too, as the architecture was so odd it couldn't made to fit with modern compilers.

True, i know AVR's have a more modern architecture than the PIC's, although now Microchip offers 16MIPS PIC's (PIC18F K series). But we all know what that means (Meaningless Information for Processor Speed)

I'm designing a digital power supply at the moment, and I'm likely to put a PIC24 or STM32 chip in it. Mostly for cost/performance (which I don't really need, though), but also so I have similar/identical code for most of my projects (saves time).
I would only use 8-bit chips if for package or power consumption.

Like i said, i mostly work on small projects at the moment (easy money  ), so 8-bit PIC's are quite decent for the job. Also, where i live there is no Digikey/Mouser, only local electronics stores, and the offer for PIC's is quite bigger than that of the AVR. Another big advantage for me is the DIP packages, because often the customer wants a prototype of the board which i must build myself (toner transfer), so i am mostly working with trough hole stuff, and the 8 bitters are still vastly available in that packages.

[hans]

PK2 can also be used as a AVR programmer using avr-dude

Risking a quick diversion off topic, do you have any links to the info on this? Last time I looked I came up with something in Russian with a very suspicious chain of half broken html links and some other method I didn't like the look of but cannot quite remember at the moment.

My bad, I thought on the top off my head it was PK2, but apparently that doesn't work.

I'm not dreaming; I see no new projects that are pic based compared to the numerous ones that are arduino based.

I would not even consider using a pic in an opensource project simply due to the fact that the tools are not free and not nearly as functional as they could/should be.

the ones using pic are the ones told to use it at school or industry.  I know of no one that starts out picking the pic anymore.  its used by pros (who have the expensive tools) but rarely by new guys starting out.

if you have info to show otherwise, bring it.  else, it seems pretty obvious if you just take a look at a place like hack-a-day (etc) and see how many pic submissions are there vs atmel.  pic is rarely even mentioned anymore and that's a fact.

Sure, look at dangerousprototypes. It's the complete opposite of hackaday in that sense, as it features many PIC related projects. It's mainly the blog hosts there (Ian and other designers) use PICs , so likely a small community hangs around it.