Recent Posts
sort by category
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...
Regular visitors will no doubt have noticed a rather dramatic change to the visual appearance of this blog. EmbeddedGurus has grown dramatically in the last year and so we've moved to a better platform (Wordpress) to manage the growth. Although the switch over from Blogger has been relatively painless, it's still necessary for me to manually check all my previous posts making sure they are right. I should have this done in the next few days at which point I will resume regular blogging.
If yo...
I am pleased to announce that the EmbeddedGurus website has been redesigned. Among the new features of the site are:
1. A dynamically updating home page, featuring the most recent posts from all of our bloggers. If you prefer, you may view these posts by category.
2. A common look and feel to all of the individual blogs.
3. The ability to search individual blogs, as well as to easily browse from one post to the next and via tags and categories.
4. A sixth guru named Gary String...
Welcome to the new Embedded Bridge blog on the newly-redesigned Embedded Gurus website. So why the word, "bridge"? It is not used in the literal sense of bridges that carries human or vehicular traffic. (Although I came across this embedded bridge in Inc Magazine. Roll the mouse over numbers 1 and 4.)
I used "bridge" in the conceptual sense to enable two sides to work together, bridging the gap between the two, and establishing processes, procedures, and protocols between the two. I have wr...
The following is an example of a cache-related embedded software bug that is a real challenge to solve for several reasons, not the least of which is the fact that the actual problem was masked in the debugger's view of memory.
One nasty bug that came up recently for us was the realization that we were not flushing the instruction cache after leaving the bootloader which had a very confusing effect when running our application. In our design our code pretty much runs out of flash. Our bootloade...
Today's post is motivated by the events that happened yesterday in Austin, Texas. For my overseas visitors, a software engineer, Joe Stack, decided to fly his light aircraft into an office building that housed the regional offices of the IRS (the American tax office). He created tremendous damage and likely murdered at least one person, while killing himself. Notwithstanding that I wrote just a few weeks ago about the propensity for engineers to be involved in terrorist acts, what is relevant ab...
Failure to tag certain types of variables with C’s 'volatile' keyword, can cause a number of symptoms in a system that works properly only when the compiler’s optimizer is set to a low level or disabled. The volatile qualifier is used during variable declarations, where its purpose is to prevent optimization of the reads and writes of that variable.
For example, if you write code that says:
g_alarm = ALARM_ON; // Patient dying--get nurse! &n...
Technically, the problem of a non-reentrant functions is a special case of the problem of a race condition. For that reason the run-time errors caused by a non-reentrant function are similar and also don’t occur in a reproducible way—making them just as hard to debug. Unfortunately, a non-reentrant function is also more difficult to spot in a code review than other types of race conditions.
The figure below shows a typical scenario. Here the software entities subjec...
A race condition is any situation in which the combined outcome of two or more threads of execution (which can be either RTOS tasks or main() plus an ISR) varies depending on the precise order in which the instructions of each are interleaved.For example, suppose you have two threads of execution in which one regularly increments a global variable (g_counter += 1;) and the other occasionally resets it (g_counter = 0;). There is a race condition here if the increment cannot always be executed at...
Last year a friend had a St. Jude pacemaker attached to his heart. When he reported an unexpected low battery reading (displayed on an associated digital watch) to his doctor a month later, he learned this was the result of a firmware bug known to the manufacturer. The battery was fine and would last on the order of a decade more. His new-model pacemaker's firmware didn't include a bug fix that was provided the year before to wearers of old-model.Another friend owns a Land Rover LR2 SUV with ...
This is the eleventh in a series of tips on writing efficient C for embedded systems. Today's topic will, I suspect, be slightly controversial. This post is based upon two basic observations:
Passing parameters to functions is costly.
Conditional branch instructions can be very costly on CPUs that have instruction caches (even with branch prediction).
I don't think that too many people will disagree with me on the above. Despite this I too often see a style of coding that incurs these c...
It seems that barely a month goes by when I'm not asked my opinion on compilers. Sometimes I'm simply asked what compilers I use, while other times I'm asked my opinion on specific compilers - with GCC being by far the most asked about compiler. I've resisted writing about this topic because quite frankly it's the sort of topic that people get very passionate about - and by passionate I mean frothing at the mouth passionate. It seems that some folks simply can't accept the fact that someone does...
Today's post is prompted by an email I received from Michael Burns. With his permission I have reproduced his email below.
Hi Nigel,
What is your opinion on the usage of goto in C?
Sometimes when a routine has many conditions [usually for error handling] I have used a do {..} while(0); loop with breaks thus avoiding both deep nesting and repeated checks with a status variable.
For example:
unsigned int XXX_ExampleRoutine (unsigned int XXX_instance, unsigned int *XXX_handle)
{
unsi...
Last month I received an interesting e-mail in response to a column I wrote for Embedded Systems Design called The Lawyers are Coming! My column was partly about the poor state of embedded software quality across all industries, and my correspondent was writing to say my observations were accurate from his perch within the automotive industry. Included in his e-mail was this interesting tidbit: I read something about the big Toyota recall being related to floor mats interfering with the accele...
I've been writing about the practice of embedded software development--in the form of books, articles, columns, conference papers, and blog posts--for nearly 15 years. (How time flies...) I also served as editor-in-chief of Embedded Systems Design magazine for about 3-1/2 years in the middle. But it wasn't until August of last year that it occurred to me to write an e-mail newsletter.My newsletter is called Firmware Update, and it is published about every 3 weeks. &nb...
Today's' post was prompted by an excellent comment from Phil Ouellette in a recent newsletter from Jack Ganssle. In a nutshell Phil was advocating strobing switches with an alternating voltage waveform, rather than a direct voltage in order to minimize corrosion and premature switch failure. This happens to be an area in which I have some experience and so I thought I'd extend the concept a little bit and also give you some food for thought.
The basic idea behind Phil Ouellette's comments is ...
Rate Monotonic Analysis (RMA) is a way of proving a priori via mathematics (rather than post-implementation via testing) that a set of tasks and interrupt service routines (ISRs) will always meet their deadlines--even under worst-case timing. In this blog, I address the issue of what to do if two or more tasks or ISRs have equal priority and whether round robin scheduling is necessary in an RTOS to deal with that special case.First a little background. In order for the schedulability...
A couple of years back, my wife and I remodeled our kitchen. In the process, we replaced our oven and range with a Kenmore Elite slide-in unit, similar to the one in the picture below. My wife was pretty nervous about buying an oven with a display and a keyboard--because she understood that meant embedded software with its all-too-frequent crashes and upgrades. At the time, I assured her that oven controller firmware was the sort of thing anyone who could spell 'C' could write.But now my day ...
A while back I wrote a blog posting on using lookup tables as a means of writing efficient C. Since then, every day someone looking for basic information on lookup tables ends up on this blog - and I suspect goes away empty handed. To help make their visits a bit more fruitful I thought I'd offer some basic information on how best to implement look up tables in C. Given that this blog is about embedded systems, my answers are of course embedded systems centric.
So what is a lookup table? Well...
Site Feed