The Secret to Successful Scaling: Use a Flexible Toolchain

1. What are the most important factors for choosing an embedded processor? (Source: Embedded Computing Design, 2017 Embedded Market Study)

Choosing the right software and tools that scale to the application controller (low-end controllers to application-specific MCUs) and offer easy-to-use, comprehensive software solutions can save you significant time and stretch your tool investment well into the future.

With multiple options among today’s software and development tools to choose from, it can be tough to find the right match, especially as software and tools become more complex and important. Therefore, selection should be done with the future in mind:

• You might end up changing the microcontroller in a next project, because you need different peripherals or more RAM or flash.
• If you select a flexible and scalable toolchain, the ultimate goal is to reuse the environment from project to project and then scale it for any new supported devices.

Flexibility and scalability can be achieved by organizing the set of software and tools based on your needs as building blocks (Fig. 2). The secret is to select and combine the blocks for scalability and reusability in multiple projects.

2. Software and development-tool building blocks.

So here are my thoughts on each of these tool blocks:

Host

Developers need a host machine that can run all of the tools—one with lots of RAM and SSD disk space. In addition, a host environment makes things much easier. Not every IDE or toolchain is available for Windows, Linux, or Mac.

Make sure that all tools do run on Mac, Windows, and Linux, and that the files and settings can be exchanged easily. (Linux-based systems are mostly used for Embedded Linux related projects, while Windows is more dominant on the lower end (non-Linux) targets). If you can, avoid any node-locked or otherwise restricted software or tools, as this will limit the way and location where you can use it.

Build System

To build the application for a device, developers must compile all of the source files. For this, a compiler, assembler, linker, and libraries are all required. That build system can be a simple batch or script file, or integrated development environment (IDE).

• Compiler: While the majority of embedded applications are still implemented in C, consider compiling it in C++ mode to take advantage of stronger type checking.
• Integrated development environment: Consider an IDE for a more sophisticated make file or an integrated build system. Eclipse-based IDEs support manual make files and “managed” make files. To scale for larger projects, your build system should take advantage of parallel builds to utilize the multiple cores on the host system.

Libraries

3. Multiple library options with different levels of functionality.

Using libraries and reusing code is extremely helpful. Build tools typically come with standard (ANSI C/C++) libraries, but it is wise make sure that they have been tested against these standards.

• Optimized libraries: Look out for optimized libraries for embedded usage—they can reduce your application RAM and flash footprint. But, keep in mind that these libraries might not be compatible with the standard or only implement a subset of functions. Insist on getting the sources for the libraries, because debugging it and then rebuilding the libraries with your settings speeds the iterations. Also check that you can choose the level of functionality in the libraries so that it scales with your application needs (Fig. 3).
• BSPs and SDKs: Microcontroller vendors typically provide a set of drivers as a board support package (BSP) or software development kit (SDK). Examples are great, but having production-quality software and drivers is much more valuable than demo code only.
• Device/board specific: Typically, when device drivers are available, they only support a subset of the capabilities (e.g., support only polling mode, but no interrupt mode). This makes finding quality, comprehensive drivers and middleware even more important. Make sure that the SDK is tailored for the device or board you’re using (Fig. 4).
• Open source: As for the libraries that come with the compiler, carefully check the licensing conditions, since “open” doesn’t always mean you can use it the way you want.
  
  

4. Software-development kits (SDKs) should tailor to your board.

Middleware

There are many good communication stacks, graphics libraries, database systems, real-time operating systems (RTOSs), and other middleware to choose from. As for these libraries, developers need to understand the licensing conditions. The usual challenge with middleware is how well it integrates into your application or how well it fits with the other middleware. Good examples, tutorials, and documentation can make a huge difference in integrating middleware.

Editor

A good editor helps the developer to get the job done. This can be accomplished with a simple text editor up to the most fancy and advanced editing system. An editor should scale so that it can be used for small text changes up to large refactoring, as well as be “scriptable” with good shortcuts and navigation helpers. Source block folding/unfolding is very handy if working with large source files, or the function to jump to a variable or function declaration or definition.

5. Here’s an editor with the code-completion feature.

There might be a learning curve as for everything. However, helpers like code completion (Fig. 5) can provide a productivity boost.

Collaboration

For tracking purposes, a version control system (VCS) is a must, especially as development teams get larger and more dispersed. With an integrated VCS, work items can be tracked from simple “to-do” entries in the source code, up to full requirements and bug tracking systems.

Support

Let’s face it; rarely does a project go by where you don’t need some level of support. Having an online community to help answer questions is a good first check before selecting a toolchain. But if problems get too complex, finding software and tools that offer professional support and service options can be a lifeline to rescue a project.

Miscellaneous Tools

6. A graphical clock-configuration and code-generation utility helps boost productivity.

The ability to extend the set of tools and capabilities is always a desirable feature. Can you install the “extras” you like? Are there plugins available, and how many? Can the tools be extended with my own set of functionality? With devices getting more complex, dedicated tools for pin multiplexing and clock configuration (Fig. 6) (that generate the source code for the application) can really boost productivity.

Verification

All systems need to be tested and verified. Considering this important requirement from the beginning of the project is imperative to success. Start with “white box” testing, which tests internal structures and the workings of the application. Then move to “black box” testing, which tests system functionality, and consider tools that use an external testing framework, maybe even driven by a requirements management system.

Also, consider a build server that allows for continuous integration. In this scenario, developers can submit their changes, which then get built by a server running automated tests on test board farms.

Debugger

Often the most time-draining, debugging is critical to embedded design. No matter the RTOS selection (bare metal or established OS), having the ability to debug small bare-metal applications up to complex ones running with one or more operating systems, is a real winner.

Can you easily debug on assembly level up to complex C++ classes? Can you inspect the RTOS with its tasks/treads and the other entire kernel-related information (Fig. 7)? Does the debugger have a command line interface and can it run from scripts and in headless mode in an automated test environment?

7. It’s important to be able to inspect RTOS tasks.

Incredibly helpful is the ability in the debugger to watch variables or expressions while the target is running. Also valuable is the ability to debug an application from anywhere in the world using a network connection, enabling global teams to collaborate using the same hardware.

Run Control

Debugging an application typically requires hardware and a probe. Programming or flashing a small application doesn’t rely much on the download speed of the probe. However, for larger applications, this saves a considerable amount of time.

• Multi-CPU and multicore applications: With these applications on the rise, it’s important to understand if the tools can debug multiple cores, devices, or boards at the same time, or if they debug remote boards with a network wired or wireless connection.
• Broad MCU support: As well, it’s good to ask if the debug probe can be used for a wide range of devices and microcontroller vendors. Are there probes that can address your needs, from the inexpensive (Fig. 8) so that everyone of the team can have one, up to a really fast and powerful one that might be used by a few to solve the really hard problems?

8. The SWD/JTAG Debug Probe (NXP LPC-Link2) is an inexpensive option.

Analysis

If the application runs on the target device, it doesn’t mean it runs well or is optimized for low power. Analysis is required. Independent of the problem to be solved, it’s good to have the full range of tools available, from static analysis and software instrumentation up to full hardware trace.

• Static code analysis: Think about using static code analysis, which checks, for example, the source files against coding standards or checks that variables are always properly initialized. Free tools are good, but be prepared to invest in premium tools.
• Dynamic code analysis: These tools offer profiling and coverage and are extremely helpful to spot performance problems or identify gaps in the verification and test suite. Entry-level software tools instrument the source code, have a level of intrusiveness, and require more RAM and flash on the device. The ARM Cortex-M architecture, for example, includes hardware tracing facilities that can be used with low-cost debug probes for analysis (Fig. 9). High-end hardware tools utilize the more advanced device trace facilities and are able to stream off data from the target with minimal impact or intrusiveness. Make sure that the board design supports hardware trace.

9. Application profile with SWO.

Device

Having software-development tools that support multiple microcontroller architectures allows for flexible scaling. Tools can support a broad range of devices and architectures (Fig. 10).

If the toolchain doesn’t support different MCU and CPU architectures, it will be next to impossible to add extra device support. It’s always good to choose a device that has different options in clock speed, package and pinouts, and flash and RAM sizes so that it can scale with your application and device switching isn’t later required.

10. Tools can support a wide range of devices and boards.

Integration

An IDE, like the one shown in Figure 11, can bring a level of integration from loosely integrated to fully integrated. Finding one that’s in between ensures interoperability and keeps things separate for flexibility and scalability. Tools with productivity features built in (e.g., automation, macro recording/playing, or multi-monitor views) can add such an amazing productivity boost to the overall suite. Looking for tools with productivity in mind is advisable.

Is it possible to interface with CAD/EDA tools, like information about pin layout, device package used, pin multiplexing/muxing and pin configuration? How easy is it to use it with everything integrated? Eclipse, for example, offers helpful plug-ins and built-in version control support. However, for the more complex, a dedicated and external version control system client is needed. The point is to use the level of integration (and complexity) as it fits best for the task.

11. Shown is an Eclipse-based IDE.

Conclusion

With all that’s required by embedded engineers to get their products to market, it’s no wonder they lean on software-development platforms as one of the biggest decision points in selecting which controllers/processors are right for their designs. The pain points are high and require comprehensive software to ease development.

Integrated development tools that (1) support a broad set of MCUs, (2) are built on industry-leading (and often open-source) frameworks, (3) remove the project lengthening cost of switching MCUs or toolsets, and (4) pull it all together into a set of cohesive, optimized enablement solutions that work together is a developer’s dream.

NXP Semiconductors can help embedded designers get to market faster with its integrated software development tools, including the MCUXpresso IDE, SDK, and Config Tools that were featured in the figures.

References

GNU ARM embedded toolchain

Eclipse-based IDE (NXP Semiconductors)

Configuration Tools (NXP Semiconductors)

LPCLink-2 debug probe