5 Embedded System Characteristics Every Engineer Should Monitor

No matter how complex an embedded system becomes, there are five key characteristics to every embedded system that develops should monitor closely. A few are obvious such as RAM and ROM usage; however, the others are often over looked by developers and can easily become a major sticking point in the design cycle.

Characteristic #1 – System Timing

Ask any developer the min, max and average execution times for a system interrupt or function and ninety percent of the time the answer will be a blank stare. When it comes to understanding the real-time performance for an embedded system, developers cross their fingers and hope for the best. Microcontrollers have gotten very fast and powerful, but they are by no means a general computing device where timing can be completely ignored. Developers need to understand how their system will respond if multiple interrupts fire simultaneously or if a user mashes all the buttons at once (my favorite test case to try which fails nearly 100% on the first attempt).

Modern microcontrollers provide developers with numerous tools to understand their system timings and responses. For example, ARM microcontrollers have trace capabilities that allow a developer to sample the PC counter at regular intervals and reconstruct the systems timing and execution path. Utilizing these tools can give developers insights into their system and provide them with real data as to how their system is performing rather than a hope and a prayer that the system is executing code the way a developer thinks it is.

Characteristic #2 – Execution Order

System timing is critical in a real-time embedded system and understanding instruction execution order is just as important. Understanding where the system is branching, jumping and what function or interrupts are executing when and in what order are critical. Systems have become so complex that we can think we understand what is happening but pulling trace data and visually seeing the code execution reveals a completely different story. I highly recommend developers investigate and become familiar with their microcontrollers trace tools. These modern-day tools provide visually engaging and insightful diagrams that just weren’t possible a few years ago and I’ve caught so many bugs using them that before I write a single line of code I setup my trace and bug trapping tools.

Characteristic #3 – Code Size

Every developer monitors code size, right? I would argue that they don’t! Most developers if asked how much code space a GPIO or SPI driver will take on their system don’t even have a place to go and look for the answer! All they know is that the last application they worked on had GPIO and SPI, but the final application used approximately 47 kB of flash space. We are notorious for not tracking the code usage details for our systems. Now in our defense, the code size can drastically vary based on the compiler used and even the optimization level and flags used. However, it can be extremely useful to track these details in order to aid future project planning and part selection. If you are interested in the potential differences between open source and commercial compilers I recommend checking out Open Source versus Commercial Compilers. In most cases today, monitoring code size has become less important because flash is pretty inexpensive and vendors have made it very easy to switch between different parts within the same microcontroller family based on code size.

Characteristic #4 – RAM usage

RAM is becoming the crucial factor in embedded software development. It isn’t uncommon for microcontrollers to flash space exceeding 16 kB but at the same time with the IoT, network stacks, communication and the focus on code reuse, RAM space is still at a premium. Throw an RTOS in the mix and an application could minimally require 16 kB. As developers create their software and implement it, they need to be monitoring where their RAM space is going. In an RTOS based system, it is not uncommon for developers to allocate ungodly amounts of RAM to thread stack space because it is difficult to estimate just the right size.

Characteristic #5 – Energy Consumption

Battery operated devices undoubtedly have energy consumption as a key requirement for the system design. Systems that have access to the grid often neglect energy since it isn’t a key requirement. However, given rising energy costs and limitations in natural resources, developers should still continue to monitor their devices to understand what their energy footprint is and how they can minimize the energy they use. Battery operated devices will obviously gain operational life between swapping out batteries or recharging the device. Devices that are directly connected to the grid can benefit consumers and end users by saving costs for electricity (yes, its minute but considered a few million devices and suddenly we have a lot of energy being wasted).

Conclusion

These five characteristics need to be monitored by embedded software developers as they create their systems. Using modern day systems can sometimes make monitoring these characteristics seem trivial or unnecessary but at the end of the day, the biggest issues I encounter in the field are always related to these five key areas.

7 thoughts on “5 Embedded System Characteristics Every Engineer Should Monitor”

  1. Energy Consumption: Not just for battery operated devices. Our machines consume tens of kilowatts, so mA are not a concern. But the inside of the box may be 60C or more from the 2% that doesn’t do work. So heat in the processor matters, sometimes a lot.

    1. 16 kB is correct. Using ThreadX, uC OS, FreeRTOS, etc as you create a half dozen tasks with stacks of 2 – 4 kB will give you about a 16 kB minimum RAM usage.

  2. Thanks for article.

    I want to check RAM usage, but I am not aware how should I track it. Suppose I allocated stack size as 10 KB and heap as 4 Kb , how should I track if these numbers less.more or appropriate. Please suggest.

    1. There are several ways to do this. In general, you can fill your stack and your heap with known values, a watermark, and then you can use your IDE’s memory viewer to periodically look and see how deep into the stack you are and how far into the heap you have gone. You can also use a static analysis tool to do a work case stack analysis.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.