Embedded articles: RTOS performance, dev tools, memory utilization, debugging
I have finally caught up and this is the last aggregation of recent articles. From now on, all being well, I’ll post to alert readers of new material being available. This time the articles cover measuring RTOS performance, the use of open source tools, memory use optimization and approaches to debugging …
Why and how to measure your RTOS performance
In the world of smart phones and tablet PCs memory might be cheap, but in the more constrained universe of deeply embedded devices, it is still a precious resource. This is one of the many reasons why most 16- and 32-bit embedded designs rely on the services of a scalable real-time operating system (RTOS). An RTOS allows product designers to focus on the added value of their solution while delegating efficient resource (memory, peripheral, etc.) management. In addition to footprint advantages, an RTOS operates with a degree of determinism that is an essential requirement for a variety of embedded applications. This article takes a look at “typical” reported performance metrics for an RTOS in the embedded industry.
Embedded software development tools – a third way
What is so special about programming embedded software? More specifically, how does it differ from programming for desktop computers? Along with addressing these questions, this article looks at why there are so many options for embedded development tools – why such a wide choice? And what strategy makes sense for selecting them? Are free tools worth having or do you need to pay real money?
Optimizing data memory utilization
Optimization is very important to embedded software developers because they are always facing limited resources. So, being able to control the size and speed trade off with code is critical. It is less common for thought to be given to the optimization of data, where there can be a similar speed versus size tension. This article looks at how this conflict comes about and what the developer can do about it.
Who needs a debugger?
Although embedded software developers would like to think that they spend the bulk of their time designing software and coding it, that is not the case. Almost everyone actually spends more time getting the code to function correctly – a process that we call “debugging”. Different people have different ideas about what debugging actually entails and, with the advent of multicore designs, new challenges are presented. This article reviews debug approaches and technology and considers what is likely in the future.
This is a broad subject and there are a couple of Web seminar archives that might be of interest, which can be found here and here.
