Recent Posts
sort by category
I'm a middle-aged man, so you can guess what this blog is about…
Yes, that's right, bathroom fixtures!
Today we are examining the high-tech, highly political, and seriously flawed attempt at conservation by reducing the rate at which your plumbing can deliver water.
I lived in my house for over 20 years and the bathroom fixtures are showing their age. In something resembling temporary insanity I bought a couple of new faucets. They were chosen because they were attractive and reas...
Regular readers will know that low power designs are an interest of mine. Indeed one of the very first blog posts I made lamented how difficult it is to ascertain how much energy it takes to perform various tasks typical to an embedded system. Thus it was a pleasant surprise to receive an IAR newsletter today announcing a tool ('Power debugging') that is explicitly designed to help one lower a system's power consumption. The tool isn't available yet, but if the propaganda is to be believed it...
One of the interesting aspects of being an embedded systems consultant is that I get to look at a lot of code written by others. This can come about in a number of ways, but most commonly occurs when someone wants changes made to an existing code base and the original author(s) of the code are no longer available. When faced with a situation such as this, it is essential that I quickly get a sense for how maintainable the code is - and thus how difficult changes will be. As a result I have devel...
This is the fourth in a series of tips on lowering power consumption in embedded systems. For this post I thought I'd delve into the common task of transmitting serial data. I compare polling and interrupting and show you how a hybrid approach can sometimes be optimal.
Almost every embedded system I have ever worked on has contained serial links. At its most abstract level, a serial link takes in parallel data and converts it to a serial stream. This serialization inherently takes longer than...
About 14 months ago I bought a name brand laptop from a well-known retailer. I declined the extended warranty so I should not have been surprised when the power jack inside the laptop cracked 63 days after the warranty expired. The damage was disabling as the external plug had to be propped at a severe angle to charge the computer. Unfortunately it would have to be repaired.
A quick call to the retailer told me I was in trouble. They said the repair would require replacing the motherb...
A common question engineers often wrestle with is how long hardware will take to do a requested task so firmware can take the next step. Engineers implement different designs (both in hardware and firmware) depending on the length of time, and these designs have varying impacts on hardware and firmware complexity and overall system performance. Understanding their ramifications during the design phase helps balance the load between hardware and firmware.
Based on the hardware and firmware imp...
One of my major recreational pursuits is bike riding. I live in a rural area with some great terrain, and more to the point a very low traffic density. Naturally on a 5 or 6 hour ride one does encounter some traffic and I'm always struck by the different degrees of consideration afforded to cyclists by motorists. Some are extremely solicitous and will wait so that they can pass you slowly and with a wide separation; others are complete jerks and will pass you as close and as fast as possible, of...
Doctors and Engineers are two of the most respected occupations in our society. While both are highly educated and highly intelligent, in my opinion there are far more differences between the two careers than similarities. For example, an engineer may be expected to start with a blank sheet of paper and design a complicated system, but a doctor starts with an incredibly complicated system (the human body) and tries to figure out why it's not working right.
Both groups can have substantial...
In my previous post, "I hate RTOSes", I have identified blocking as the main cause of the particular brittleness and inflexibility of the programs based on RTOSes. Here I'd like to discuss techniques of minimizing blocking and eradicating it completely from the application-level code. In other words, I'd like to show you how to use an RTOS for building responsive event-driven software.
For reasons I've outlined before, experienced RTOS users have learned to be weary of peppering the code with...
I have to confess that I've been experiencing a severe writer's block lately. It's not that I'm short of subjects to talk about, but I'm getting tired of circling around the most important issues that matter to me most and should matter the most to any embedded software developer. I mean the basic software structure.
Unfortunately, I find it impossible to talk about truly important issues without stepping on somebody's toes, which means picking a fight. So, in this installment I decided to co...
This is the twelfth in a series of tips on writing efficient C for embedded systems. Like the previous topic, I suspect that this will be a bit controversial. As the title suggests, if you are interested in writing efficient C, you need to be wary of switch statements. Before I explain why, a little background will be useful. I did all of my early embedded systems programming in assembly language. This wasn't out of some sense of machismo, it was simply a reflection of the fact that there were n...
Several years ago I came across a register that, at first glance, seemed to be a typical register with several read/write bits. Upon closer inspection, I saw that one bit behaved differently, depending on its state and whether I was writing a 1 or a 0 to it. Since firmware had to handle that one bit differently from the other bits in that register, I saw that it would be difficult for firmware to safely handle both types in the same register. I was able to reduce the risk of mishandling that reg...
Today's post is motivated in part by Gary Stringham. Gary is the newest member of EmbeddedGurus and he consults and blogs on what he calls the bridge between hardware and firmware. Since I work on both hardware and firmware, I'm looking forward to what Gary has to say in the coming months. Anyway, I'd recently read his posting on Early hardware / firmware collaboration when I found myself looking at a fairly complex schematic. The microprocessor had a lot of IO pins, most of which were being use...
A reader of my monthly Firmware Update newsletter recently sent an e-mail to ask:
I am a firmware engineer. I read your recent blog post regarding the C stack, about which I have two questions: First, how can I increment or decrement the size of the stack in my code? Second, what size should I choose?
Here's what I told him:
The size of the stack is set either in the linker command file or in the C or C++ startup code. You should be able to learn more about how to change the stac...
It remains unclear whether Toyota's higher-than-industry-average number of complaints regarding sudden unintended acceleration (SUA) is caused (in whole or in part) by an embedded software problem. But whether it is or it isn't actually firmware, the company has clearly denied it and yet still developed an embedded software "image problem". They've brought some of this on themselves.
Side Note: I think it is a net positive that journalists, the mass media, and a broader swath of the general...
Although today's post is the first real post on the new EmbeddedGurus, it's special for another reason. This post is being jointly written with John Regehr. John is an Associate Professor of Computer Science at the University of Utah and maintains an excellent blog, Embedded in Academia which I heartily recommend. This blog posting grew out of a lengthy email exchange which started with John alerting me to some blatant plagiarism of my work and then evolved (dissolved?) into what you find ...
Dynamic memory allocation is not widely used by embedded software developers—and for good reasons. One of those is the problem of fragmentation of the heap.
All data structures created via C’s malloc() standard library routine or C++’s new keyword live on the heap. The heap is a specific area in RAM of a pre-determined maximum size. Initially, each allocation from the heap reduces the amount of remaining “free” space by the same number of bytes. For example, the heap in a partic...
A few years ago, I was invited to a high-level design review of a new SoC. The proposed design contained an I/O block that needed features added. I successfully convinced them to replace that block instead with an existing block that had the needed features, had seen silicon, and had a functional driver. Months later on real hardware, bringing up the driver for that block was painless.
This incident illustrates the benefits of early collaboration between hardware and firmware engineers. All t...
Every programmer knows that a stack overflow is a Very Bad Thing™. The effect of each stack overflow varies, though. The nature of the damage and the timing of the misbehavior depend entirely on which data or instructions are clobbered and how they are used. Importantly, the length of time between a stack overflow and its negative effects on the system depends on how long it is before the clobbered bits are used.
Unfortunately, stack overflow afflicts embedded systems far more often than...
The other day I went to the gas station and encountered a shiny new pump. It had a liquid crystal display to interact with me and on top of the pump was a medium sized monitor. My first thought was "wow – nice", but that first impression didn't last very long. I was a little disappointed with the responsiveness of the display and authorization of my credit card seemed to take longer than usual. I began thinking the company had not gotten their money's worth from the engineering departm...
Site Feed