IDE-Plus: Trends in embedded software tools By Chris Hills

Some time ago I did a series of annual articles on embedded compiler trends for MTE. Since then, things have moved on, but not entirely in the direction expected. While compilers are improving, with increased efficiency, MISRA checking etc, these changes are over shadowed by other developments.  

Now the trend I can see is the expansion of the IDE or Integrated Development Environment: Not in the IDE editor/project manager application itself so much as thecreation of an integrated environment.  Companies like IAR, Keil, Mentor, and Green Hills now supply alongside the compiler and the project IDE, development kits (with examples and BSP’s), RTOS, USB, TCP-IP stacks, file systems, CASE tools and debuggers: in fact everything you need bar a computer and a desk.

 

So, far from the days when one bought the compiler from one supplier and the editor elsewhere, the compiler companies are endeavouring to be a one-stop-shop from start to finish.  The question is, “Is this a good idea?”  The answer has to be “Yes” and “No.”

 

The up side is that, in theory, all-in-one will work out of the box with no integration or support problems: the supplied example projects will pull all these components together, in some cases all the way from the CASE tool to the debugger on the dev kit. So set up and configuration time is low and managers like fast start up for a project.

 

However the common thing about embedded systems is they are all different.  The down side of these packages is that one size does not fit all.

 

For example…. the RTOS.  Some companies have a simple RTOS developed in-house, others buy one in, in one case from a customer who had developed it for their own use. Some buy an RTOS company (usually with an old or ailing system) and others just re-badge and repackage an RTOS from a successful RTOS company. Very few, if any, actually develop a high end RTOS from scratch. The different approaches can determine how much work the compiler company puts into the RTOS and associated components, and how well customer support works.

 

Compiler companies with no history of developing an RTOS may not put much more effort into development or support for the system they have bought.  A re-badged system may have on going development and support, but usually though the compiler company back to the original RTOS company.

Levels of integration can vary. Some file, USB and TCP/IP systems are stand-alone, others require the support of a particular RTOS. For most RTOS “having a USB stack” means a USB device, not a USB Host Stack: Host stacks are few and far between.

 

Not all RTOS are the same. I was recently in a bidding process where there were a dozen different RTOS in the frame. There were major differences in their architecture, way of working and performance, not to mention the range of targets they supported.  Also, there were differences in the licensing model and the add-ons, such as file systems, TCP/IP, USB etc, to be supplied.

 

Some RTOS can be used in critical systems and have the back-up for this. Others will be far more difficult, and even more expensive, to certify to any standard.  So the list price of “the RTOS” is not a real guide to the cost for the project.  

 

The compiler companies are now providing their own debuggers. (Note “debuggers” NOT emulators.) They have, over the years, provided simulators (the software MCU emulators) that have increasing sophistication and ease of use. Building a simple hardware JTAG or BDM is not particularly difficult.  However, be under no illusion that these bundled debuggers are anything more than simple debuggers. They are not the same as In-Circuit-Emulators, they will be intrusive and they will be lacking in features: that is why they are inexpensive. 

 

The debuggers from the high-end emulator companies are designed as part of an expandable system. They will probably have modules for trace and logic analysers as well as a much higher specification.  Ninety per cent of the time the inexpensive debuggers are all you need. The problem is for the other ten per cent.  You may need to buy or rent a high-end debugger for some of the nasty stuff: believe me it is cost effective when time = money! But will your chosen all-in-one compiler/RTOS/debugger bundle work well with the top end third party debuggers for your targets?

 

Then, of course, you come down to the targets. The bundle of RTOS, dev kits, debuggers etc is not always available for all the targets the compiler company has compilers for. So you settle on a package only to discover that it doesn’t match the next processor that you want to use.   You will have to mix and match. Should you mix and match across the board?  Or should you change the target processor to one that fits in with your compiler’s all-in-one availability list?

 

Some “compiler companies” can supply the whole thing but are equally happy to supply any one (or more) component and will work with most third parties for the other components, as in the past. Usually you will find the support is better, as they are more inclined to work with the third parties to sort out problems.

Some of all-in-one compiler companies put a lot of pressure on having everything from them and don’t co-operate well with third parties. The level of support will also deteriorate. In house support is fine, but when you add in a third party item the problems always seem to be the other parties fault.

 

The choice of RTOS is too important to be a de-facto choice as part of a compiler bundle. Before you think that this is the desperate plea of a distributor looking at lost RTOS sales, most can supply compilers with, and without, bundled RTOS and various third party RTOS, so it makes little difference in terms of profit to a distributor but it  will make quite a difference to the customer’s project. 

 

Part of the problem is the pricing; a bundle is invariably cheaper than buying separate items. With most modern compilers, the IDE is effectively “free”, so I can see company accountants looking more at the bottom line than the right technical choice.  This is where good impartial advice for the long term is critical.

An additional factor is that silicon distribution companies will now not only “give away” the compilers with a heavy discount to sell their chips, but increasingly will give away or heavily discount the complete chain of compiler, RTOS, debugger etc. The problem is their support is for selling the chips and their view is strictly this quarter and next quarter. Besides, because they know their MCU does not mean they understand software development or RTOS. The margin they have discounted can be that needed to pay for support. I can see many people thinking they are getting a bargain, only to find they need a lot more help than is available as things progress.

 

In conclusion, are the compiler companies going the right way trying to put everything into one package?  Well the answer is still “Yes” and “No.” This model will fit some and not others. Choose very carefully as getting locked in to a system now may require more than just a change of compiler later. Get independent advice.

 

Author Details and contact

 

Eur Ing Chris Hills BSc CEng MIET MBCS MIEEE  FRGS   FRSA is a Technical Specialist and can be reached at This Contact

 

Copyright Chris A Hills  2003 -2008
The right of Chris A Hills to be identified as the author of this work has been asserted by him in accordance with the Copyright, Designs and Patents Act 1988