Archive for August, 2007

An unfortunate consequence of a 32-bit world

Wednesday, August 29th, 2007 Nigel Jones

Back in the bad old days when I was a lad, one learned about microprocessors by programming 8 bit devices in assembly language. In fact I can still remember my first lab assignment – namely to multiply two 8 bit unsigned quantities together to get a 16 bit result (without the use of a hardware multiplier of course). One of the indelible lessons that comes from doing an exercise such as this, is that it can take many instructions to perform even the most innocuous of high level language statements.

I mention this, because today I was looking at some code written by a young engineer who was recommended to me. In examining some of his code, I noticed the following construct:

void some_function(void)
{
 ...
 ++ivar;
 ...
}

interrupt void isr_handler(void)
{
 ...
 --ivar;
 ...
}

Notwithstanding the fact that ivar should have been declared volatile, the most egregious mistake here was the assumption that the statement ++ivar is an atomic operation. Now if one is used to working on 32 bit machines, the concept of incrementing an integer being anything other than an atomic operation is of course ludicrous. However, in the 8 or 16 bit world where many of us labor in the embedded space, the idea of incrementing an integer being an atomic operation is equally ridiculous. The trouble is with bugs like this is that they are difficult to spot, and will only rear their head after months or even years of operation.

So, is this a case of an incompetent individual? Although nominally yes, I suspect that the real problem is that he was raised on a diet of big CPUs. Perhaps the universities could do these engineers a favor, and throw away the ARM based evaluation boards and replace them with an 8051 based system.

Home

Application notes code quality

Thursday, August 2nd, 2007 Nigel Jones

All manufacturers of microcontrollers publish application notes. Some of these application notes are of course nothing more than gussied up advertising drivel. However, many of these application notes contain useful information that can cut days, and sometimes weeks off a project. Having read hundreds of these application notes over the 25 years I’ve been doing this, I’ve come to the conclusion that whereas the application notes usually get the algorithms correct, the same can’t be said for the code. Too often the code is sloppy, with bugs that are apparent merely by code inspection. May be it’s just me, but whenever I see a sloppy piece of code, it makes me wonder about the underlying quality of the IC design.

I think this is unfortunate, since the manufacturer’s could do much to improve things in the industry by setting a great example. To this end, I think they should:

  1. Adopt a set of coding standards that all their code adheres to.
  2. Have the code reviewed, such that egregious bugs are caught.
  3. Make the code Lint free
  4. If they are aiming the product at the automotive industry, ensure it is MISRA C compliant.

The advantages to the IC manufacturer are legion:

  1. They look good (never a bad thing)
  2. All their application note code has the same “look and feel”. This encourages engineers to use their application notes, and hence their products.
  3. The code in the application note is usable “as is”, speeding time to market and generally giving the perception that their product is easy to use.
  4. Less experienced engineers are taught how to do things correctly – which presumably leads to higher quality products- which presumably translates into more sales.

I guess the thing that I find maddening about this, is that the manufacturers probably spend weeks or months developing the application note, and then let themselves down by presenting their solution in such a poor way. When I talk to the marketing folks for the CPU manufacturers, I make a point of bringing some of the more egregious errors to their attention. Perhaps if all of us did this, we could get a bit of a sea change in the industry.

Home