Recent Posts
sort by category
At a rather fundamental level this blog is about how I do embedded systems. Implicit in a lot of the articles is the concept that I believe what I'm doing is 'right', or at least 'better'. Well today I thought I'd write about something I got wrong (at least on the first pass).
This is the scenario. I'm currently working on an NXP LPC17xx ARM Cortex design. Like all modern processors, the LPC17xx has a number of sophisticated timers with all sorts of operating modes. Well it so happens that I ...
This blog is read by people from all over the world. I make this point not to brag, but rather to demonstrate that designing embedded systems is a truly global effort. Remarkably, despite this, it appears that a huge amount of embedded code is commented in English and / or uses English nomenclature for variable and function names. This is of course wonderful for those of us that are native English speakers. However I've often thought that designing embedded systems is hard enough without having ...
This post was originally posted in the wrong blog. I'm reposting it here.
Real-time systems design and RMA go together like peanut butter and jelly. So why is it that wherever I go in the embedded community, engineers are developing real-time systems without applying RMA? This is a dangerous situation, but one that is easily remedied by ensuring every programmer knows three things about RMA.
In case you are entirely unfamiliar with RMA, there's a handy primer on the technique ath...
While I am sure that I could extend the setting a bad example series of articles I think it's time to move on to other topics. Before I do so I'd like to give some final thoughts. The series has generated a lot of excellent comments. While the majority have been in response to a particular coding construct, a number of readers have expressed their frustration at how pervasive this problem is with vendor supplied code. My experience agrees with this assessment. In other words while this seri...
Real-time systems design and RMA go together like peanut butter and jelly. So why is it that wherever I go in the embedded community, engineers are developing real-time systems without applying RMA? This is a dangerous situation, but one that is easily remedied by ensuring every programmer knows three things about RMA.
In case you are entirely unfamiliar with RMA, there's a handy primer on the technique at http://www.netrino.com/Embedded-Systems/How-To/RMA-Rate-Monotonic-Algorithm/. I’v...
This is the fifth part in a series of articles in which I’m ‘highlighting’ what I consider to be lousy code provided by IAR in their NXP LPC1764 development kit. This code excerpt is taken from usb_t9.c in the AudioDevice project.
/*************************************************************************
* Function Name: UsbCoreReq
* Parameters: UsbCoreReqType_t Type
*
* Return: Int32U
*
* Description: Return device states
*
***************************************...
In real-time systems, as in life, anything that can go wrong will! A nurse could be using a GUI task to change system parameters on a ventilator just as the attached patient’s lungs demand the most help from another task. Or an interrupt signal could start acting funny, generating a stream of unexpected ISR invocations. Or all of those at once. And something else.
The designers of hard real-time systems must design for such a worst-case. They must ensure that sufficient CPU and memory ...
This is the fourth part in a series of articles in which I’m ‘highlighting’ what I consider to be lousy code provided by IAR in their NXP LPC1764 development kit. This example is taken from the VirtualCom project but can be found in almost all of the projects.
This code excerpt is taken from a file 'Terminal_18_24x12.c".
/*************************************************************************
*
* Used with ICCARM and AARM.
*
* (c) Copyright IAR Systems 2006
...
On an ASIC, my ISR had to write a 1 in one place and a 0 in another place to acknowledge (ack) the interrupt. The hardware engineer I talked to tried to explain how one was an interrupt bit so that is why it needed a 1, but the other bit is a status bit it needed a 0 to clear the status. It was a little confusing; my ISR had to clear both bits before it could exit. In most ASICs I had dealt with, I wrote 1s to ack. In a few others, I wrote 0s. To come across one where I had to use both a 1 and a...
This is the third part in a series of articles in which I’m ‘highlighting’ what I consider to be lousy code provided by IAR in their NXP LPC1764 development kit. This example is taken from the Accelerometer project. The accelerometer is accessed via an I2C bus, and so the main purpose of this example code is to demonstrate how to use the I2C interface. If you have ever had to write an I2C driver you will know that they are deceptively hard. In my case the project I'm working on does ind...
This is the second part in a series of articles in which I'm 'highlighting' what I consider to be lousy code provided by IAR in their NXP LPC1764 development kit.
The following function is taken from the LCD_Demo project.
/*************************************************************************
* Function Name: Dly100us
* Parameters: void *arg
* Return: void
*
* Description: Delay [100us]
*
***********************************************************************...
About a month ago I bought an ARM evaluation board from my favorite compiler vendor, IAR Systems. Like most people I bought the board in part because it comes with a lot of example code showing how to configure the peripherals on the NXP LPC1768. Upon receiving the board, I hooked it up and started browsing the example code that came with it. To my dismay I discovered a plethora of what I consider to be shoddy coding practices. Now I am well aware that one person's shoddy practices is anothe...
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...
Site Feed