Developing a Scalable Firmware Development Environment

Selecting the right combination of tools and environment for a scalable development environment can be difficult when surrounded by customized tools.

Jacob Beningo

May 11, 2016

4 Min Read
Developing a Scalable Firmware Development Environment

Being organized is so important to being efficient and recently as I was going through my rather large development kit and debugger collection, I realized how most development tools and environments are really specialized and not scalable.

Take for example my discovery of the dozen or more debuggers I found stashed away in my closet; I-Jet, J-Link, U-Link, TDS, tiny, pickit (2 and 3), ice and others. What can professional developers do to minimize the need for all these tools and work in an environment that can easily scale from one project to the next?

For starters, because I work as a consultant, I have no clue what processor architecture or brand may be thrown in front me but I’ve noticed eight times out of 10 times the processor is ARM based (Cortex-M class). Because ARM is so popular, I’ll focus on an attempt to put together an ARM based development environment that is scalable and easily used from one project to the next. With an architecture pinned down, there are two critical pieces every embedded software engineer needs to be concerned with, compilers and debuggers.

Compilers and debuggers, while two distinct and separate pieces of the development environment, can unfortunately be closely related and tied to each other. For example, the IAR I-Jet is supported in the IAR compiler and that is about it. The I-Jet is proprietary and has some extra technology built in for low power measurement among other features. As a developer wanting to use as few debuggers and compilers as possible, I have to be careful to not select a debugger that is tied to a single compiler. Instead, I need to try to find a third party debugger such as a J-Link that is supported in nearly every compiler. (Keep in mind I’m not saying to throw away or never get one of those proprietary debuggers because they do serve an important role in certain applications and situations).

Selecting the right compiler has always been a sticky point for many of the engineers and companies that I encounter. One of the biggest hurdles I see is companies want professional tools but they usually don’t have the budget to purchase five seats of a three-thousand-dollar compiler that requires renewal every year. Instead, many seem to opt for either pairing GCC with Eclipse directly or use a free Eclipse based tool provided by the microcontroller vendor that has been completely customized. That sounds good right?

The problem is that the customizations of each microcontroller vendor IDE makes switching vendors difficult. Even though they are all based on Eclipse they can have significant differences that require precious time to get up to speed. An alternative to using the home grown vendor IDE is to use Atollics’ TrueSTUDIO. TrueSTUDIO is an ARM based development environment that is based on Eclipse but has the added advantage of being professionally maintained and the Lite version, which has no code size limitations, is completely free. The full version adds advanced debug and code analysis features that can be turned on when needed for around $60 dollars a month.

At the moment, in my quest for a development environment that scales between microcontroller vendors, I’ve boxed up all my debuggers except for my Segger J-Link Ultra+. I’ve removed the plethora of IDE’s and compilers from my development machine (I had 10!). I have my Atollic TrueSTUDIO Pro installed (I would use the LITE but I’m doing a lot of work on modern real-time debug techniques) and have multiple microcontroller vendor projects going all within a single environment. So far, development seems simpler and I still have access to professional development tools that keep me moving at the speeds my clients have expected to come from me. My only regret is that I had thought of this earlier and saved myself the expense of buying so many tool chains.

What combination of tools and environment have you found work well together to get a scalable development environment? We all have our experiences and preferences and I would love for you to share yours below.

Jacob Beningo is principal consultant at Beningo Engineering, an embedded software consulting company. Jacob has experience developing, reviewing and critiquing drivers, frameworks and application code for companies requiring robust and scalable firmware. Jacob is actively involved in improving the general understanding of embedded software development through workshops, webinars and blogging. Feel free to contact him at [email protected], at his website www.beningo.com, and sign-up for his monthly Embedded Bytes Newsletter here.

About the Author(s)

Jacob Beningo

Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses by improving product quality, cost and time to market. He has published more than 300 articles on embedded software development techniques, has published several books, is a sought-after speaker and technical trainer and holds three degrees which include a Masters of Engineering from the University of Michigan.

Sign up for the Design News Daily newsletter.

You May Also Like