Choosing the right platform for embedded software development

Developing software is hard.

Developing embedded software is even harder.

Besides contending with traditional pitfalls such as syntax errors like missing colons, logical errors like setting a variable to the wrong value, you are also challenged with complex low-level hardware details. This introduces new ways to break your software, from writing to the wrong address in memory to assembling code that doesn't execute as expected.

A key factor to manage software development is to reduce the number of variables that could break the codebase. The ‘minimize the differences’ mindset means testing the code frequently when a manageable number of lines have been written. It is a lot easier to debug and fix 100 lines of code than 10,000. This is an essential practice in continuous integration which I have already written about on this site.

When starting to develop embedded software, it is rarely a good idea to start testing right away on an FPGA or the target hardware. Issues with the physical connection, connection protocol, hardware drivers, implementation defined architecture features, toolchain settings, and the source code - just to name a few - are all possible, and effectively developing software with that many errors is unrealistic.

In this blog I’ll discuss the various platform options for embedded software development and go through when it is appropriate to choose one type over the others.

Hardware vs software-based options

There are many options to develop embedded software on, and the most appropriate platform depends on the project priorities and how far along the hardware and software development is. There are two main platforms: hardware-based and software-based.

Hardware platforms include development or off-the-shelf boards, FPGAs, and on-target testing which represents the final product. In general, these hardware platforms are good for accurate software testing as they mimic the final product’s system architecture but are difficult to scale to a large number of tests and bigger teams due to expensive cost and maintenance. They are traditionally used for a smaller number of more encompassing tests (such as system tests) and for software development towards the middle and end of a project’s lifecycle.

Software platforms include native executables, instruction set simulators, and virtual models. Native executables are cross-compiled to run natively on a x86 based machine with no virtual environment necessary. Instruction set simulators are used to run code compiled to run on the final target architecture. They are run in a virtual environment that simulates the instructions of the final target architecture. These platforms are useful at the start of a project to ensure that basic functions and code flow is working as expected and are quite simple to scale to large amounts of developers. However, they become less effective as software begins to interact with the details of the final target architecture and various peripherals. When software testing needs to become more accurate and representative of the final target system, another type of virtual environment can be leveraged.

Arm Fast Models are virtual models of Arm processors. Like instruction set simulators, Arm Fast Models run software virtually on x86 based machines. Unlike native executables and instruction set simulators, Arm Fast Model simulations are 100% functionally accurate to the hardware they represent. As a result, the maintainability and scalability of software simulators are combined with the target accuracy and toolchain. Third-party IP can also be modelled and connected to Arm Fast Models to create a more representative virtual platform to develop and test embedded software on.

General considerations for choosing the right platform

Understanding when to transition to the next platform is often a grey area and depends on each team’s unique software development environment, size, time vs price prioritization, and more. However, there are some general best practices to follow. A notable one, mentioned in the intro as well, is to not jump ahead testing on the final target system until some other testing and development has taken place already. This is for multiple reasons:

  1. Running large volumes of short tests (such as unit, smoke, and integration tests) on expensive hardware racks is a poor use of time and resources.
  2. Debugging software issues on physical hardware can often be tricky due to the lack of control and visibility of code running.
  3. Due to the complexity of connecting to, compiling for, and running on physical hardware, multiple errors can occur simultaneously, resulting in a difficult debugging session.

Due to these concerns, especially the last one, understanding what platforms can help reveal the types of software bugs is very helpful. Below is a list of each software development platform, with examples of what types of software errors the platform catches. Note that as the list goes on, examples will not be repeated, though platforms at the bottom of the list can catch the errors noted above them. This is not an exhaustive list and is intended to convey a general idea only:

  • Native Executable
    • Syntax errors
    • Program flow errors
  • Instruction Set Simulators
    • Toolchain issues (though sometimes tied to target CPU behavior this may not be caught)
  • Virtual Models based on Arm Fast Models
    • Toolchain setup and optimization errors
    • Floating point and subnormal number inaccuracies
    • Implementation defined behavior
    • Coherency maintenance
    • Cache maintenance
    • TrustZone setup and usage
  • Development board
    • Program timing issues
  • FPGA
    • Some third-party driver errors
    • Code depending on third-party IP errors
  • On Target
    • Remaining peripheral driver errors
    • Hardware-software expectation mismatches
    • System requirement mismatches

Moving straight from developing and testing embedded software on a native executable platform to an FPGA platform can result in multiple errors. Leveraging the benefits of virtual models and hardware platforms while running the code natively or on an FPGA can make the software development process smoother. Further, virtual platforms based on Arm Fast Models can be used to run large numbers of unit and integration tests that don’t require the additional granularity and system completeness that hardware platforms offer. Using this technique, it becomes easier to manage and scale a regression test suite while still developing the fine software details on hardware platforms such as FPGAs.

That being said, only you and your team know what the priorities are for the current project. There are many choices out there with many pros and cons, so you can pick a few platforms that work for best for the different product development stages.

Developing embedded control systems

Creating control systems in embedded environments introduce further complications and can be very difficult to code by hand. Arm and MathWorks have teamed up to solve the needs of software developers creating control systems, algorithms, and general DSP related code by integrating Arm Fast Model virtual platform technology into the popular MATLAB, Simulink, and Embedded Coder products. The resulting Arm Fast Model Support Package enables PIL and External Mode tests to be run on functionally accurate virtual platforms. This collaboration will be in spotlight at the upcoming Embedded World 2019 in Nuremburg, Germany:

See a live Arm-MathWorks demonstration at the Arm booth (Hall 4, 4/140)
- Listen to exhibitor talk on 27 Feb, 1-1.30pm, (Hall 3, 3/719)

Conclusion

Developing software is hard. Developing embedded software is even harder. With more variables to contend with, embedded software development teams must be smart about how and when they leverage software development platforms to minimize complications while maximizing efficiency. Arm Fast Models play a unique role among other the development platforms by combining the maintainability and scalability of virtual platforms with the functional accuracy of hardware platforms. Click below to get started today with a simple hello world example.

Get started today with a simple hello world example!

Anonymous