A rant about tools

Longtime reader and correspondent Michael Covington sent me a missive about his trials using tools from Microchip. His comments are perceptive and I’ll quote them here:

”Why do microprocessor toolmakers seem to feel, as a point of pride, that they must show us they don't know how to program a PC?

”Microchip's MPLAB is an impressive product, once you get it running… BUT it shoots itself in the foot with a lot of basic blunders reflecting ignorance of the Windows environment. Here's what I've had to fight with today:

”(1) I had to go in and give ordinary users permission to write in C:Program FilesMicrochip, or else they get an “Access Denied” message. (Windows provides directories for storing temporary and per-user data. Writing in the Program Files directory at runtime is a no-no, and is forbidden to ordinary mortals.)

”(2) The assembler won't assemble a file whose path is more than 62 characters long. This means a project cannot reside in a normal user's “My Documents” directory, nor on his desktop.

”(3) For some reason MPLAB wakes up not knowing where the MPASM tool suite is located. That puzzles me, because they were installed together.

”(4) Microchip's documentation admits that the error message “Configuration Memory has not been updated” is misleading and requires no action from the user. Then why display it?

”(5) You can't open a project (.mcp file) by double-clicking on it; you have to start MPLAB and then open the project from within it. (Just an obvious opportunity not taken.)

”I suppose Real Men Always Log On As Administrator. And use FAT32 file system. And store their files in C: or D:. But Windows is a multi-user operating system with file permissions and security measures. Microchip should not require us to skip basic security precautions in order to use their product!

”This is the latest version of MPLAB (7.22, downloaded today). The relevant features of Windows are five to ten years old.”

I’m totally with Michael on this, having fought the same battle with too many other products. Don’t get me wrong; I’m quite the fan of their processors. Though some of the PICs are utterly brain-dead, they’re perfect for a huge range of small embedded systems. The 6 pin variants, so small anyone with bifocals can’t see them, are especially cool for minimal applications.

Back in the olden days of Windows 3.1 programs were installed in any old directory under c:. But that was long ago; as I recall it was waaaay back in 1998 that c:Program Files became the default place to install applications.

Yet just last month I loaded some educational software that very-annoyingly installed itself as a directory under C:. My main PC has nearly a half million files on the C: drive so I’m very protective of the directory structure. A zillion directories branching off the root would swamp File Manager and slow me down. Only disciplined use of directory structures tame our saturated hard drives. Unless, of course, a vendor makes up their own rules and salts applications in non-standard locations.

Then there’s the applications that don’t come with an uninstall. Come on, vendors – what makes you think I want to run your product forever? Why would you litter my drive and registry with the remnants of a program that ticked me off in the first place?

Take IAR’s “launcher” for their embedded workbench. Version 2.31C, purchased just a year or two ago, installs an icon in the system tray, a convenient way to quickly get into the application. But unlike every other icon in that tray (except the Norton products that get worse every year) right-clicking on it doesn’t pop up a menu that lets one remove the icon.

Tools are supposed to make our lives easier. If they don’t conform to platform-specific rules the poor user has to struggle that much harder to get the benefits promised by the vendor.

What do you think? What tool annoys you most?

Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. Contact him at . His website is .


The reason for the cryptic toolchain issue are as follows:

1. Current interfaces are now designed 'top-down' by managers that have not done any embedded development for at least 4-6 years.

2. The implementation of the interfaces for said tools are mostly out-sourced now, with very little accountability for closing the loop. It just has to 'work'

It is curious that the core stuff, (compiler, assembler, linker/locator), is pretty much NOT out-sourced. I guess this has to do with the perception of the value vs risk factor.

– Ken Wada

The first offender (by number of programs sold and any other metric) to these basic Windows rules is Microsoft itself…

And I do not think that they outsource alot.

– Jean-Christophe MATHAE

I've used MPLab quite a bit over the past few years and have noticed some of the glitches quoted in the article. I've run across another recently that's even more irritating. The checksum value for a given piece of code mysteriously changes from one version of MPLab to another. This has also happened when using two Microchip PM3 programmers with different firmware versions. This causes all sorts of problems when the production department sees a different checksum on their programmer than what is specified in the production documentation.

– Colin vanLeeuwen

That statement is only partially true. It is only true when writing absolute code using MPASM. The easy way to circumvent this limitation is to use Microchip's linker 'MPLINK' and suppress the generation of the 'COD' file.

If you are not currently writing relocatable object code using MPASM and MPLINK, then it would be a good New Year's resolution to switch from writing absolute to relocatable code. Besides allowing you to eliminate this 62 character path limitation, using MPLINK offers a lot of advantages over writing absolute code.

Please note that I'm not singling out anyone who has responded, but as a general statement, I think the best thing to do is to always contact the tool vendors with issue reports and feature requests. I see many people rant and rave about problems, but it seems many people (not all) never talk to the right people (the vendor) that can actually rectify the problem(s). You have to give the tool vendors feedback and give them a chance to fix problems otherwise you really can't complain. If they ignore your bug reports, well, that's a completely different problem.

Even though MPLAB IDE is free, it has been my experience that Microchip has been very responsive to customer requests and bug/issue reports.

P.S. It is my understanding that this 62 character path limit is not a limitation of the Microchip tool chain, but rather due to the COD file format which Microchip cannot change (nor do I think it has any jurisdiction over).

– Ken Pergola

Why are the toolmakers so confident that the stuff they do not know how to make is mandatory to the users.

As an example: Keil makes probably the best compiler for the ’51 but to use the IDE you have to accept their miserable editor.

The above is an example, every toolset I have tried has the same limitations.

– Erik Malund

Speaking of programs that install themselves at the root, Altera Quartus is another one of those offenders.

– Bruce Casner

Yes, I have plenty of similar complaints about embedded tools.

Codewarrior which is $$$expensive has all kinds of Windows compatibilities and missing features.

I have always hated the IAR IDE and Debugger (archaic).

I have to say that Keil sells the best 8-bit tools I have ever used. Especially the new uVision3 is superb. Not sure why someone was complaining about the editor.

I attribute a lot of this to either laziness or an attitude of 'this feature makes no difference to my sales so why bother'.

Off-topic a little … but demonstrating the same attitude…all Nokia phones are a good example of an embedded product with a horrible user interface and no thought to simplifying basic operations. (why can I not type in any 3chars from someone's name to search for them in my phone book?) I could write a whole article on this.

– Daraius Hathiram

I get most annoyed with tools that are only available for a platform I no longer use to get my work done.

Tools that require me to move a mouse to do something as simple as compile or assemble a program, or reflash a controller's memory, rank a close second. GUIs unduly add size and complexity to programs that do what should be a very simple job. If I want to turn a screw, I reach for a screwdriver, not a multi-speed cordless Makita drill with a quick-release chuck and a regular-head screwdriver bit.

On top of that, GUIs make automation of those simple tasks cumbersome if not impossible. Try having your favorite version of make integrate with a tool that requires you to mouse-click “OK” in a dialog box to finish the job.

Wada's point 2 is well said. In that case, there can't be reasonable consideration for the end-user, especially when the person making the UI doesn't even have a good command of the user's native language. In other markets, this communication barrier would kill the product. Outsourcing gives companies whole lists of new reasons to not care.

– Daniel Daly


As always, you're on the money. One of the late & great Richard Feynman's mottos was, 'What I cannot create, I cannot understand.' So, you're in good company in having reinforced what my wife considers the worst in me: Do it yourself (except for uninteresting home repairs). Semi far-fetched connection: Did you catch Ivars Peterson's MAA-Website article regarding the error-rate of those tools known as spreadsheets? More ammo for (at least my) polemics.

– George Hacken

Is it more because, the people designing the embedded tools have not worked extensively in the embedded field. So they do not get the basic concepts of cross platform development?

– kalpak dabir

Some IDEs for microcontrollers I have encountered so far do not offer a very good editor environment. So, my option now is to use Eclipse as an editor, and use the vendor's IDE as a compiling, assembling, and linking tool.

Eclipse can do autocomplete, content-assist, tasks do do at certain source-code lines, CVS plugin & team-work, and many other useful plugins you can make use of.

– Bao Anh

The changing checksum problem experienced by Colin vanLeeuwen may be caused by the default fuse settings, of which one or two setting bits aren't even visible in the fuse tab of MPLAB. Wonder if I've just helped solve a problem??

– Matthew staben

I wish vendors support more platforms like Mac OS X. The problem of uninstall is solved by OS X.

– Tim Flynn

It isn't just the Microchip tool chain that has problems. It is coincidental that I recently downloaded one of their “Framework Software” packages (cdc_rs232_emulation.exe). It insists on installing to C:MCHPFUSB. Yes, hardcoded to the C: drive. Hardcoded to that path. Why they need that particular path I don't know, but it made it darn difficult to install on my machine, which has no C: drive. I ended up using a USB flash key. The reference design might be wonderful, but it gives me less confidence when I can't even install it.

– Shane Lardinois

Totally agree on this rant ! I had my share of battles with (expensive) tools as well.

I changed my dev platform to Unix (FreeBSD) and have been using the Gnu tools as much as I can for development on AVR and ARM. They are not very friendly to the uninitiated, but once you get to know them they are consistently very similar across the whole range of processors they support – no quirks anymore.

– Ewout

We suspect we bring a certain amount of this onto ourselves. We are after all engineers who find tinkering with software interesting. Heck I still use make files for some products just because I want to know exactly what is going into the code. The lack of visibility into what is going on “behind the scenes” in some IDEs makes me a bit leery to trust them.

I also think the potential market for most embedded tool chains is so small that it is hard to justify much development effort beyond the minimum needed to get it functional. I recall that the reason Motorola bought CodeWarrior was to make sure they stayed focused on their processors and to give them more resources so the tools would continue to improve.

Another thing that really bugs me about a lot of IDEs is that they pretty much force you to use their built-in text editor. I find being forced to use different editors for each processor family more than annoying, especially when a particular built in editor is lacking in some commonly used functionality. General purpose coding editors like CodeWrite (my favorite) can drive compilers, but integrating debuggers can be a bit of a pain. Unfortunately IDEs that hide details from you make porting to your favorite 3rd party editor more difficult. I often find myself taking the path of least resistance and have both CodeWrite and the IDE open at the same time and switch back and forth between them to go from text editing to compile/debug.

Hey at least it's not as bad as children's educational software. The guys that write those seem to be 10 to 15 years behind the times. Stupid stuff like having to set the display properties for 256 colors, give me a break!

– Phil Ouellette

A project's PATH was hard coded at least in MPLAB 5.0 and prior. This prevented one from easily archiving complete projects. Prevented one from cloning one project to create another similar project.

When the time came to select an MCU for another project Microchip lost to Atmel AVR. I made the decision but can't say how much the MPLAB tools contributed, and how much was price and availability as the AVR was cheaper and I liked avr-gcc better.

– David Kelly

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.