Embedded tools – the third way

A significant factor in getting any job done properly is having the right tools. This is true whether you are building a kitchen, fixing your car or developing embedded software. Of course, it is the last of these that I am interested in here. I have been evangelizing on this topic for years (decades!). The problem is that there is a similarity – arguably superficial – between programming an embedded system and programming a desktop computer. The same (kind of) languages are used and software design techniques are fairly universal. However, there are really some major differences …

There are three key areas of difference between desktop and embedded programming:

1. The degree of control required by the embedded developer is much greater, in order to utilize resources (time and memory) effectively.
2. The approaches to verification and debugging and quite different, as an external connection and/or a selection of instruments need to be employed. Also, further tools may be needed to optimize the performance of the application.
3. Every embedded system is different, whereas every PC is basically the same. This means that the tools (like the programmers) need to be much more flexible and adaptable.

Because there are so many desktop programmers, who are all working in the same environment, there is a huge demand for tools. The result is that very good tools are effectively (or literally) free. The apparent similarity of embedded to desktop programming means that developers have a misguided expectation that their tools should be free too – regardless of their specialized needs and much lower demand level. In the electronic design (EDA) world, there is no such expectation. Tools are valued and price tickets are commonly in five figures.

There are essentially three ways that embedded developers can currently get tools:

1. They can purchase commercial tools that are dedicated to the needs of the embedded developer. This is undoubtedly the best approach, but their costs are not insubstantial. There is a reasonable expectation that the tools will work “out of the box” and that technical support is available.
2. They can take open source (“free”) tools, which have been adapted for embedded use, or do the adaptation themselves. The direct costs are, of course, lower, but the extra time needed to get the tools in shape and to obtain support from the open source community cannot be ignored.

But, maybe there is a third way. What if a vendor were to take the best-in-class open source tools, comprehensively adapt them to the needs of the embedded developer, add some additional tools that fulfill their specialized requirements and offer this as a reasonably priced package? This package might be available in various editions, recognizing the diverse needs of embedded developers, and be available for immediate purchase and download on the Web. High quality technical support would also be available. For users with particularly specialized needs, services would be available to further adapt the tools to fit their specific requirements.

How does that sound?

This entry was posted on Thursday, February 16th, 2017 at 5:48 am. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.