Embedded software articles – from simulation to optimization
As I have done before, I am continuing to catalog a wide selection of my articles that have appeared at embedded.com. Another 4 today …
Simulation – better than the real thing?
With a complex embedded system, work needs to start on the software long before the hardware is available. Indeed, it may be necessary to commence work even before the hardware design is finalized. Software engineers need to test their code as they go along, so they need an execution environment from day 1. There are numerous options, which are reviewed in this article, with a particular focus on simulation technologies.
Blocking and non-blocking RTOS APIs
The primary purpose of a real-time operating system (RTOS) is to manage CPU time, distribute it between a number of tasks, and provide services to enable management of other resources such as peripherals. These functions are achieved in a variety of ways, but in most cases there is an opportunity for tasks to give a “hint” that they are able to relinquish the CPU for a while. Blocking system calls are one way to accomplish this. This article reviews how such calls work and when and how they are used. [If you would like to evaluate an RTOS for your next project, take a look here.]
Stand by or boot up?
Many embedded systems are devices that are used continuously, like, say, a central heating controller. Many others are switched on and off frequently, often only being used for short periods of time. These two modes of usage have a significant impact on the software design. In particular attention needs to be paid to power management. This article reviews the design parameters and trade-offs in the development of “occasional” use devices.
Code and compilers: small, fast or what?
All modern compilers generate optimized code. For embedded developers, good optimization is critical, as resources are always at a premium, but control of optimization is also essential, as every embedded system is different. In this article, the balance between fast and small code and the reasons for this choice to be necessary are considered. Additionally, examples are given where this “rule” is broken and fast, small code results, which leads to a reconsideration of the true function of a compiler. [You can evaluate tools for free here.]
