The problem of course in an embedded system is that undefined operations are just dangerous, so surely an embedded compiler will do something sensible, like return +32767 if you pass -32768 to abs? To test this hypothesis I whipped up the following code for my favourite 8 bit compiler (IAR’s AVR compiler).

#include <stdlib.h>
#include <inttypes.h>
#include <stdio.h>

void main(void)
{
    int16_t i;
    int16_t absi;

    i = INT16_MIN + 1;        /* Set i to one more than the most negative number */
    absi = abs(i);

    printf("Argument = %" PRId16 ". Absolute value of argument = %" PRId16, i, absi);

    i--;                    /* i should now equal INT16_MIN */
    absi = abs(i);
    printf("\nArgument = %" PRId16 ". Absolute value of argument = %" PRId16, i, absi);
}

If you don’t understand the printf strings, see this article. Here’s the output of this code:

Argument = -32767. Absolute value of argument = 32767
Argument = -32768. Absolute value of argument = -32768

Clearly abs(-32768) = -32768 is not a very useful result! If I look in <stdlib.h> I find that abs() is implemented as

  int abs(int i)
  {      /* compute absolute value of int argument */
    return (i < 0 ? -i : i);
  }

Clearly no check is being made on the bounds of the parameter, and so the result that we get depends upon how the negation of the argument is performed. Thus this leads me to my first suggestion, namely write your own abs function. I’ll call this function sabs() for safe abs(). The first pass implementation for sabs() looks like this (note you’ll have to include <limits.h> to get INT_MIN and INT_MAX):

int sabs(int i)
{
    int res;

    if (INT_MIN == i)
    {
        res = INT_MAX;
    }
    else
    {
        res = i < 0 ? -i : i;
    }

    return res;
}

Here’s the output:

Argument = -32767. Absolute value of argument = 32767
Argument = -32768. Absolute value of argument = 32767

I think for most embedded systems this is a better result. However what happens if you use a smaller integer than the native integer size (e.g. a 16 bit integer on a 32 bit system, or an 8 bit integer on a 16 bit system?). To test this question, I modified the code thus:

#include <stdlib.h>
#include <limits.h>
#include <inttypes.h>
#include <stdio.h>

int sabs(int i);

void main(void)
{
    int8_t i;
    int8_t absi;

    i = INT8_MIN + 1;        /* Set i to one more than the most negative number */
    absi = sabs(i);

    printf("Argument = %" PRId8 ". Absolute value of argument = %" PRId8, i, absi);

    i--;                    /* i should now equal INT8_MIN */
    absi = sabs(i);
    printf("\nArgument = %" PRId8 ". Absolute value of argument = %" PRId8, i, absi);
}

int sabs(int i)
{
    int res;

    if (INT_MIN == i)
    {
        res = INT_MAX;
    }
    else
    {
        res = i < 0 ? -i : i;
    }

    return res;
}

So in this case, the native integer size is 16 bits and I’m passing an 8 bit integer. Here’s the output:

Argument = -127. Absolute value of argument = 127
Argument = -128. Absolute value of argument = -128

Clearly, I still haven’t solved the problem, as I’d really like abs(-128) to be 127 when using 8 bit integers.  I suspect that I could come up with some fancy expression that handles all integer types.  However I’m a great believer in simple code, and so  my recommendation is that you write sabs() functions for all your integer types. Thus:

/* Safe 8 bit absolute function */

int8_t sabs8(int8_t i)
{
    int8_t res;

    if (INT8_MIN == i)
    {
        res = INT8_MAX;
    }
    else
    {
        res = i < 0 ? -i : i;
    }

    return res;
}

/* Safe 16 bit absolute function */

int16_t sabs16(int16_t i)
{
    int16_t res;

    if (INT16_MIN == i)
    {
        res = INT16_MAX;
    }
    else
    {
        res = i < 0 ? -i : i;
    }

    return res;
}

/* Safe 32 bit absolute function */

int32_t sabs32(int32_t i)
{
    int32_t res;

    if (INT32_MIN == i)
    {
        res = INT32_MAX;
    }
    else
    {
        res = i < 0 ? -i : i;
    }

    return res;
}

The above approach is all well and good, but let’s face it, I’ve added a lot of overhead for a very rare condition. So this raises the question as to whether there is a better way of doing things? Well in many cases we use the abs() function to check for some limit. For example

    if (abs(i) > SOME_LIMIT)
    {
        printf("\nLimit exceeded");
    }

In cases like these, you can use what I call a negative absolute function, aka nabs(). nabs() works with negative absolutes and so can’t overflow. To demonstrate, here’s the code:

int nabs(int i);

void main(void)
{
    int i;
    int absi;

    i = INT_MIN + 1;        /* Set i to one more than the most negative number */
    absi = nabs(i);

    printf("Argument = %d Negative absolute value of argument = %d", i, absi);

    i--;                    /* i should now equal INT_MIN */
    absi = nabs(i);
    printf("\nArgument = %d Negative absolute value of argument = %d", i, absi);

    i = INT_MAX;
    absi = nabs(i);
    printf("\nArgument = %d Negative absolute value of argument = %d", i, absi);
}

int nabs(int i)
{
    return i > 0 ? -i : i;
}

The output looks like this:

Argument = -32767 Negative absolute value of argument = -32767
Argument = -32768 Negative absolute value of argument = -32768
Argument = 32767 Negative absolute value of argument = -32767

Armed with this function, you merely flip your tests around, such that you have:

    if (nabs(i) < SOME_NEGATIVE_LIMIT)
    {
        printf("\nLimit exceeded");
    }

I’ll leave it to you to decide whether gaining the efficiency is worth it for the rather strange looking code.

As a final note, do a search for the abs() function on the Internet. You’ll find that most references don’t mention the undefined behavior of abs with INT_MIN as an argument. The notable exception is the always excellent GNU reference . It’s thus hardly surprising that most embedded systems use abs().

So what’s this got to do with embedded systems you ask? Well, when it comes to embedded systems programming, I think Chapman’s concept is spot on. While most people would probably agree that simplifying an embedded system is a good thing, I wonder though how many actively work so as to achieve this? In my case I regularly hold conversations with my clients which can be summarized as: Yes I can do that, but it comes at the expense of complexity – and complexity leads to bugs – and bugs are very expensive. I have found that clients are quite appreciative of this as it forces them to evaluate what is truly important about the product. Incidentally, when I first started in the consulting business, I thought that it was my job to give the client whatever it was they asked for. The fact that in doing so I was often giving them a serious disservice was quite a revelation when the penny finally dropped.

So what about the ‘adding lightness’ directive? Well clearly this is an interesting concept when it comes to firmware. I take it to mean that the code should be simple, easy to read, and fast in execution – in other words not unlike a Lotus sports car. If I have cause to re-read the code many months or years later and I find that the code has stood the test of time and is a pleasure to read, then I think I have achieved the required lightness. If by contrast the code is out of date and ugly to read then I know I have failed. In short it’s the difference between designing a Lotus Elan and an AMC Pacer.

NXP LPC17xx RTC registers

Of most interest is the column labeled ‘Reset Value’. You will notice that the values highlighted in red are ‘NC’. ‘NC’ means that the registers are unaffected by a reset condition. Furthermore, these particular registers may also be powered from an alternate power source such that they are also unaffected by loss of power. So why is this useful? Well I have found a couple of uses for them beyond the obvious and intended applications of maintaining date and time (for the RTC registers) and for providing non-volatile R/W storage for the General Purpose registers.

Communicating with the Bootstrap loader

Most embedded applications today contain a bootstrap loader (BSL). Although there are several ways of entering the BSL from the main application, the most common that I see is to force a watchdog reset, resulting in the CPU rebooting and starting up in the BSL. This technique is pretty good and I use it all the time. However I usually find it necessary for the main application to communicate some information to the BSL. For example, at a minimum the BSL needs to know that it has been intentionally entered for the purposes of performing a firmware update (as opposed to being entered as a result of a genuine watchdog failure). Under some circumstances I also need to pass other information to the BSL such as the port that initiated the update. In the past I have tended to pass this information via EEPROM. However with these registers available to me, I now use them for this task.

Debugging

If you are plagued with your system taking unexpected resets, then it’s a relatively trivial matter to write some debug code that writes context information to these registers. For example most RTOS provide mechanisms for calling user functions prior to performing a task switch. Within this function it’s trivial to write the task ID to one of these registers. Then it’s just a matter of putting a breakpoint on the entry into main() to discover which task was running when the reset occurred. Once you have it narrowed down to a task, you can then instrument functions in a similar manner.

I suspect I may find other uses for these registers in the future. Suffice to say I’d really like it if this feature became widespread across all processor families.

No editor support for splitting the window

The title says it all. Text editors back in the DOS allowed you to open a file and look at various parts of the file at the same time via split windows. This is such a fundamental operation for text editors that I couldn’t believe it wasn’t supported. Do the developers of MPLAB use an editor with this limitation?

No single file compilation

There appears to be no way to simply compile a single file. Instead one is forced to perform a make. Not only is this really time consuming as make wades through all the files that aren’t relevant, it’s also a pain because:

• It forces you to correct problems in the first file that make finds to process – rather than the one you are interested in.
• If the compilation passes, it proceeds immediately to the link and download phase – regardless whether you want to or not.

A baffling debugger configuration interface

The first time I tried to download to the debugger, I received an error message telling me that there was a problem with the configuration bits. I beat my head against the issue for a few hours and in the end called a colleague who is a Microchip Consultant (Matt).  Matt told me that he avoided using MPLAB, but vaguely recollected that you had to configure the debugger to explicitly download to the target. Well Matt was spot on. I was just left wondering why anyone would want to debug code without having it downloaded first.

A joke of a simulator

While I was waiting to get hold of Matt, I experimented with the simulator. Despite the documentation saying that various peripherals were supported, I found that the simulator simply didn’t support them. Matt confirmed that the simulator was a piece of junk that no one bothered using.

Unnecessary variable scope limitation

I’m not sure if this is an IDE or a compiler issue. Anyway, when debugging within MPLAB, I discovered that if I had the temerity to declare a variable as static, then the only time I could examine its value was if the variable was in compiler scope. That is, if I was stopped in file foo.c, then the debugger would not let me see the values of static variables declared in bar.c. As a result, I was forced to declare variables as global simply so that I could look at them. Quite frankly, it blows my mind that in 2011 an IDE can force you to adopt lousy programming practices because of its limitations.

No pointer dereferencing

In a similar vein, I discovered that MPLAB only shows you the values of pointers, and not what they are pointing to. I thought that limitation disappeared at least ten years ago.

Limited support for ‘large ‘arrays

The PIC18 doesn’t handle arrays or structures greater than 256 bytes very well. However the Microchip compiler guys came up with a decent work around that is quite straight forward to use – until you want to look at the array in the debugger. In a nutshell all you seem to be able to do is examine the array / structure in the memory window. You can forget about looking at 16 bit integers, or other such ‘complex’ constructs.

Breakpoints that aren’t where I put them

I discovered that placing a breakpoint on a function call was highly problematic. In some cases the break would occur prior to the call, and in other cases it would occur after the call. If I wanted the breakpoint in the called function, I’d put it there myself, thank you.

Anyway, I could go on – but I think you get the picture. What I don’t get is this. Microchip is a big successful company. Why, after a decade of trying can’t they come up with a decent development environment? It has got to be costing them a lot of design wins when people such as myself cringe at the though of having to use their tools.

Before I delve into the uses of #warning, I must warn you (if you would pardon the pun) that #warning is a non standard directive. However it is supported by IAR, GCC, Microchip’s C18 compiler, Hi-Tech and probably a whole raft of other vendors. In other words, it’s pretty standard for a non-standard feature.

The use of #warning is simple enough:

#warning This is a warning

This will result in the compiler issuing a warning with the text ‘This is a warning’ printed to stderr. Please note that, just as for #error, there is *no* requirement that the text be in quotes. If you insist on putting quotes around the text, then they will be printed to stderr as well.

With the syntax out of the way, here’s some of the ways that I use #warning.

Protecting Incomplete Code

Very often when I’m coding, I like to get the big picture in place without worrying about the minutiae of the implementation details.  As a result I end up with functions or loop bodies that are incomplete. In these cases I simply add a #warning to alert me to the issue. For example

void foo(void)
{

#warning To be completed

}

Thus what happens now is that whenever I compile the module, I get a warning (i.e. reminder) that there is something important still to be done.

Commenting Out Code

I *never* comment code out anymore as part of the debugging process, as it is simply too easy to forget that the code has been removed. Instead I use this construct:

void foo(void)

{

# if 0

   /* Code to be temporarily removed is here */

#else

#warning Temporary debug construct. Fix me!
   /* Experimental code goes here */

#endif

}

In this case whenever I compile the module, I get a warning (i.e. reminder) that I have some experimental code in the image.

The Key Final Step

While the above are useful constructs, the real power of #warning comes if you configure your compiler to treat warnings as errors for the release build. If you do this and you have inadvertently left incomplete or debug code in the image, then your compilation will fail. In short, this technique will guarantee that you never release code that includes / excludes code that shouldn’t / should be there. That’s effective C.

Previous Tip

If you have ever had a vegetable garden then you will know that they are magnets for rabbits. Furthermore, you will soon find out that it takes extraordinary efforts to keep the rabbits out, as they have a tremendous ability to circumvent all sorts of fences.  When faced with such a problem, it is sometimes advisable to build a rabbit patch. The basic idea is this – you plant your garden and put a fence around it, and then on the outside of the fence you plant a second vegetable garden that is purely for the rabbits – i.e. a rabbit patch. The rabbits feed on the rabbit patch and leave your real garden alone because they would have to exert effort to get to it – and they don’t need to as there needs are satiated by the rabbit patch.

So what has this to do with embedded systems? Well let me describe a scenario to you that is almost certainly all too familiar to anyone that has been doing this for a few years.

It’s dog and pony show time and marketing is coming to pronounce judgement on your latest creation. Now if you are fortunate, the folks in marketing are a pleasure to work with. However from time to time, you run into someone who is incapable of attending a dog and pony show without offering criticisms / complaints. (I’m talking about the sort of person who would have criticized Michelangelo’s David at its unveiling). When faced with such an individual, I have found that the answer is to build the embedded system’s equivalent of a rabbit patch. It works like this. You intentionally put into the demonstration something that obviously isn’t quite right. Come time for the dog and pony show, the complainer latches on to the ‘problem’, and proceeds to explain in detail why it is wrong. You sit there and graciously accept the pearls of wisdom dispensed to you. You can then proceed to the meat of the presentation and get some useful work done.  The meeting ends and our protagonist walks away happy – and you have managed to actually have a useful and productive meeting. Naturally the fix to the ‘problem’ is a flick of a compilation switch.

So now you know what a rabbit patch is. I encourage you to use it sparingly. I also encourage you to watch out for it being used on you! I have sat in on a couple of presentations where I’m pretty sure a rabbit patch has been deployed. Fortunately I’m also pretty sure the rabbit patch wasn’t for my benefit…

On a personal note, I’m expecting to return to my normal blogging schedule. The long awaited hardware test may actually make an appearance soon.

Now flights from the east coast of the USA to Europe tend to be night flights, and this flight was no exception. Being a seasoned traveler I have my trans-Atlantic night flight routine down pat. Get settled in, have something to eat, put on the noise cancelling headphones, select a classical music channel and then try and sleep for the rest of the flight. I followed my routine, and after selecting the appropriate music channel, I selected the volume control icon. This resulted in a pop-up window from which I adjusted the volume to something reasonable. I then made the fateful mistake. Rather than exiting the volume adjust window, I simply hit the ‘on/off’ button. This of course doesn’t turn the system off, it merely blanks the display. I then settled in for my nap. Several hours later, I woke up and wondered how far into the flight we were and thus decided to take a look at the real-time route map. Accordingly I turned the display ‘on’ and was rewarded with what I expected to see, namely the volume control screen. A photograph is shown below:

When I touched the Back button, nothing happened. Hmmm thought I, has my system died? Answer – no. I could still adjust the volume, and I could still mute and un-mute the audio. I could also turn the system ‘on’ and ‘off’. Clearly the problem was that there was no ‘back’ associated with the Back button. Needless to say, United Airlines wasn’t going to reboot the entire system so that I could experiment some more, plus I was tired. Anyway I resolved to experiment some more on the return flight.

Thus a week later I’m on a Boeing 777 with the same in flight entertainment system. I brought up the volume control page and did nothing. After about 30 seconds, the pop-up window auto cleared. This was the clue I needed. I thus brought up the volume control page again and immediately turned the unit ‘off’ and then a few seconds later ‘on’. When I did this the back button worked correctly. I repeated the exercise a few more times, and it always worked. I then repeated the exercise, but this time I waited longer than the screen timeout period. Voila – lockup. Clearly this was a case where there was a gaping hole in the state machine that was driving the user interface. At this point I found some interesting thoughts crossing my mind:

• Idiot. Now you can’t watch any movies.
• I bet the designer didn’t use a formal state machine tool such as visualSTATE, or QP
• Whenever there are two distinct ways of exiting a state (in this case, user action or the passage of time), life gets complicated
• Preserving state across a ‘power down’ is always difficult
• I hope the guy that wrote the in-flight entertainment  system had nothing to do with the flight control systems on the plane!

Anyway if you find yourself on a plane with an in-flight entertainment system in the near future, see if you too can crash the system – and let us know how you did it.

P.S. I woke up this morning to read that a computer ‘glitch’ effectively grounded United Airlines yesterday. See this for thoughts on United’s computer system.

Anyway at about 25 miles into the ride, I noticed that my Incite bike computer was showing that I had ridden 34 miles. This struck me as unlikely, and so I asked Bill what mileage he had on his computer – 25 being the answer. I thus cycled through the computer screens, until I came to this one (photo courtesy of Bill Tan).

Apparently the computer thought that I had hit 132.6 mph at some point – and obviously sustained it for quite a while for me to gain about 9 miles. Now to understand how this could come about, you need to know a little about my bike computer. The computer consists of two parts, the User Interface (shown above) and the pick up. The pick up senses wheel rotation by a magnet passing close to what I assume is a Hall Effect Sensor. Now whereas many bike computers transfer the signal along a cable to the display, mine transmits it using an RF link – and this I suspect was the root cause of the problem. My guess is that at some point in the ride, I rode into an area of RF interference that the display interpreted as signals from the pickup. The firmware in the bike computer appears to have blithely accepted the RF data as valid and thus produced the ridiculous result shown here.

Now I have often been faced with this kind of problem – and the solution is not easy. However IMHO Incite really fell down on the job here. If I had been writing the code, I suspect that I’d have done the following:

1. Median filter the data to remove random outliers. (Incite may be doing this).
2. Sanity check the output of the median filter. If the answer is ‘impossible’ (like a human pedaling a bicycle at 132.6 mph), then reject the data and let the user know that something is amiss. Incite did neither of these things.

Rejecting the data is actually a little harder than it sounds. If you reject data, what do you replace it with? Common choices are:

1. Zero
2. The most recent valid data
3. The average of the last N readings.

Each of these has its place and is application dependent.

Letting the user know that something is amiss, is usually straight forward – flashing the erroneous value is the normal solution.

Anyway, the bottom line is that a wise embedded engineer always sanity checks the incoming (and outgoing) data. If you do you are less likely to end up as the subject of a blog posting.

A personal note

I apologize for the abysmal rate at which I have been posting. I moved house this spring, which coupled with me being extremely busy has resulted in there simply not being enough hours in the day. When that happens, something has to give. I hope to return to my normal blog posting rate in July.

#define N_ELEMENTS(X)           (sizeof(X)/sizeof(*(X)))

Its nominal use is to determine the number of elements in an incomplete array declaration. For example

void foo(void)
{
 uint8_t bar[] = {0, 1, 2, 3, 4};
 uint8_t    i;

 /* Transmit each byte in bar[] */
 for (i = 0; i < N_ELEMENTS(bar); ++i)
 {
  txc(bar[i]);
 }
}

Clearly this is quite useful. However, once you have this macro in your arsenal you will eventually run into a conundrum. To illustrate what I mean consider the following code:

#define BUF_SIZE    (5)
void foo(void)
{
 uint8_t bar[BUF_SIZE] = {0, 1, 2, 3, 4};
 uint8_t    i;

 /* Transmit each byte in bar[] */
 for (i = 0; i < BUF_SIZE; ++i)
 {
  txc(bar[i]);
 }
}

This uses the classic approach of  defining a manifest constant  (BUF_SIZE) and then using it to define the array size and also as the loop limit. The conundrum is this: is one better off using N_ELEMENTS in this case as well. In other words, is the following better code?

#define BUF_SIZE    (5)
void foo(void)
{
 uint8_t bar[BUF_SIZE] = {0, 1, 2, 3, 4};
 uint8_t    i;

 /* Transmit each byte in bar[] */
 for (i = 0; i < N_ELEMENTS(bar); ++i)
 {
  txc(bar[i]);
 }
}

This code is guaranteed to operate on every element of the array bar[] regardless of what is done to the array declaration. For example:

#define BUF_SIZE    (5)
void foo(void)
{
 uint8_t bar[BUF_SIZE + 1] = {0, 1, 2, 3, 4, 5};
 uint8_t    i;

 /* Transmit each byte in bar[] */
 for (i = 0; i < N_ELEMENTS(bar); ++i)
 {
  txc(bar[i]);
 }
}

In this case I have changed the array declaration. The code that uses N_ELEMENTS would still work while the code that used BUF_SIZE would have failed. So from this perspective the N_ELEMENTS code is more robust. However I don’t think the N_ELEMENTS based code is as easy to read. As a result I have oscillated back and fore over the years as to which approach is better. My current view is that the N_ELEMENTS approach is indeed the better way. I’d be interested in your opinion.

1. Embedded systems design, not hardware design
   The test is intended to test the hardware knowledge of persons writing embedded code. It is NOT a test for persons that will be designing hardware. Thus questions about the minutiae of hardware filter design are not what I’m looking for.
2. Traps
   The best questions will be examples from your past where someone got into trouble because they didn’t understand something about the hardware that you thought they should have.
3. Why
   As well as posing the question (and giving the answer!), please explain why you think it’s important that someone should know what you are asking.
4. Oscilloscope and logic analyzer
   I expect that the questions will cover circuits, processor architectures and tools. While I’m interested in all three, I’m particularly interested in elegant questions that will allow the questioner to determine if the candidate knows how to use an oscilloscope or logic analyzer.
5. Original
   Please don’t send me any copyrighted or plagiarized material. Links are of course fine. (I mention this because not only is it legally and morally wrong – but I’m also tired of people ripping off my work and claiming it as their own).
6. Attribution
   If I choose to use your suggestion, then tell me how you’d like it attributed. Full name + email address through anonymous are all fine.
7. Early bird…
   If I get multiple similar suggestions, then the first one received gets the credit.
8. Fame
   By sending me something you are agreeing to let me publish it. Other than attribution (and the accompanying fame ), no other compensation will be given.

Anyway, if you’d like to participate then contact me

Thanks! I expect that I will publish the article in a few weeks.