Integer Log functions

A few months ago I wrote about a very nifty square root function in Jack Crenshaw's book "Math Toolkit for Real-time Programming". As elegant as the square root function is, it pails in comparison to what Crenshaw calls his 'bitlog' function. This is some code that computes the log (to base 2 of course) of an integer - and does it in amazingly few cycles and with amazing accuracy. The code in the book is for a 32 bit integer; the code I present here is for a 16 bit integer. Although you are of course free to use this code as is, I strongly suggest you buy Crenshaw's book and read about this function. You'll see it truly is a work of art. BTW, one of the things I really like about Crenshaw is that he takes great pains to note that he didn't invent this algorithm. Rather he credits Tom Lehman. Kudos to Lehman.

/**
 FUNCTION: bitlog

 DESCRIPTION:
 Computes 8 * (log(base 2)(x) -1).

 PARAMETERS:
 -    The uint16_t value whose log we desire

 RETURNS:
 -    An approximation to log(x)

 NOTES:
 -   

**/
uint16_t bitlog(uint16_t x)
{
    uint8_t    b;
    uint16_t res;
   
    if (x <= 8) /* Shorten computation for small numbers */
    {
        res = 2 * x;
    }
    else
    {
        b = 15; /* Find the highest non zero bit in the input argument */
        while ((b > 2) && ((int16_t)x > 0))
        {
            --b;
            x <<= 1;
        }
        x &= 0x7000;
        x >>= 12;
       
        res = x + 8 * (b - 1);
    }
   
    return res;
}

IEC60730

Atmel has a very interesting application note on IEC60730 Class B compliance. If you aren't aware of IEC60730, there is a nice introduction here. In a nutshell IEC60730 Class B compliance is a safety standard related to household appliances. Part of IEC60730 requires that one actively monitor that a microcontroller (if one is used) is functioning correctly. This seems to be a reasonable thing to do. However, as the Atmel application note shows, meeting this requirement requires one to constantly do things such as test memory, confirm that timers are operating at the correct frequencies and so on. Again conceptually this doesn't seem unreasonable. However, my concern with this is that the very act of confirming that the hardware is functioning could result in a system failure at a critical point, thus creating the very problem the standard is designed to prevent.

For example, it's hard to argue with the contention that the stack is the most used portion of memory in most microcontrollers. I think most engineers would agree that if the memory used for the stack malfunctioned then disastrous things would most likely occur. On this basis, a regular check of the Stack memory would seem to be in order. Maybe it's just me, but the thought of running a memory test on the stack area of a processor while simultaneously trying to respond to interrupts etc seems like a very tall order. Indeed, I can easily envisage a piece of code that is designed to test the stack area malfunctioning and causing a system crash and potentially causing the very thing it's designed to avoid.

I think what it comes down to is this. The reliability of hardware seems to me to be several orders of magnitude better than the reliability of software. Thus using software to validate hardware seems problematic. I'll be very interested to see what happens the first time someone gets hurt as a result of a malfunction in software written to conform to IEC60730. If you don't think this is likely, take a look at the size of the object code produced by Atmel's suggested tests. Then consider that many household appliances use microcontrollers that contain just a few kbytes of object code - and that the IEC60730 code will thus make up a very large fraction of the delivered code. On a simplistic statistical basis, we can assume that if 30% of the code in a product is related to IEC60730 compliance, then 30% of the bugs will be in that code. Given what the code has to do, my money is that the IEC60730 compliance code will have a much higher bug rate than the general application. Thus the probability of a failure occurring in the IEC60730 code is high - and someone will get hurt when the code fails.

As a parting thought, how exactly does one set about testing code that is designed to detect hardware failures internal to an integrated circuit. Although I'm sure I could come up some test protocols for some hardware, I suspect that the Heisenberg uncertainty principle will ensure that the very act of testing the test will result in a flawed test.

The perils of overloading

This post is coming to you from Sweden - a very fine country that I heartily recommend visiting if you get the chance. (If you're wondering why I'm in Sweden - I'm here on business as one of my clients is located in Gothenburg). Anyway, the fact that I'm in Sweden is relevant to this post, as to get here I had to put myself at the mercies of United Airlines. Now the fact that the flight over here was less than perfect wouldn't be news to any of you that travel regularly. However, the reason that the flight was a disaster is relevant, as I'll now try and explain...

Upon arrival at the United check in desk at Dulles airport, I was greeted by an array of self check in kiosks, with a total of one real live human being to take care of baggage check in. Thinking myself to be computer savvy, I negotiated the check in kiosk with ease, only to be told that:

1. I had to see the human in order to check my bags in, and
2. The system was unable to assign me a seat and that seat assignment would be done at the gate.

The first instruction was par for the course, while the second instruction I found to be very strange. Anyway, I shrugged my shoulders and went over to the sole person working the desk. There was one gentleman in front of me. This gentleman, not unreasonably asked if he could use some of his frequent flier miles to upgrade to business class. No problem said the United employee, who proceeded to rattle the keys. After 5 minutes, he announced that although the system was showing that seats were available in business class, the computer system refused to allow him to assign a seat. This was the second clue that things were heading south in a hurry. It then took the clerk another 10 minutes to wait list the gentleman (giving a total processing time of 15 minutes). Although it's possible the clerk was incompetent, I got the impression that he really knew what he was doing, and was just being stymied by the system.

Anyway, I checked my bag in and proceeded to the gate. When I got to the gate, I found another 100+ passengers that also had no seat assignments. When eventually I got called to the counter, I found a harried women with a sea of boarding passes printed out in front of her. She was manually searching through them trying to find my name. Eventually she found it and handed it over. My nature being what it is, I politely inquired as to the reason for this astonishingly strange system of assigning seats and issuing boarding passes. Apparently this was the opportunity that the clerk had been waiting for to vent her frustration, as she gladly explained to me that the powers that be had over booked the flight. And so my gentle reader, we come to the point of this post. It was apparent that the United system was unable to handle an overbooked flight correctly, and rather than degrade gracefully, had all but collapsed. At which point I started making some snarky comments to myself about database programmers and how surely all database programmers worked in that field because they couldn't handle the rigors of the embedded / real time world and that any half decent embedded systems person would never make such an elementary mistake. It was then that I had my epiphany. We make the same mistake in the embedded world all the time. When was the last time you used RMA (Rate monotonic analysis) to guarantee that all your tasks would meet their scheduling deadlines? How many failures of embedded systems are caused by overloading (or over scheduling) and the failure to correctly assign task priorities. How many times do weird things happen in your code that you just shrug off as "one of those things"? In short, I found myself cutting a break to the poor sod that wrote United's code. I was still ticked off though!

A new way to tell if something is an embedded system

Periodically someone tries to come up with a definition of an embedded system. For example there is an excellent and oft cited definition here. What got me thinking about this topic is the latest gadget I love to hate - my Verizon Treo phone running Windows mobile. A few years ago, there would have been no doubt that a cell phone was an embedded system. Today, the Treo, the i-Phone etc are all running versions of traditional computer operating systems, and are much more computer like than they are an embedded system. So the question is what are they - an embedded system or a computer?

Well today I offer a new simple test to tell if these devices are fish or fowl (foul is perhaps more appropriate), to wit:

"Is the device a pain in the neck to use?" If the answer is "yes", then it's a computer. My Treo is a computer. Enough said!

Electronic Component Footprints

As well as writing code and designing hardware, I also do PCB layout. I started doing this after I discovered it was often faster for me to layout a board myself than to try and convey all my requirements to a board layout person. If you've ever done PCB layout, you'll know that getting information about a device's footprint is a real pain. What you may not know is that this is a major source of errors on printed circuit boards, resulting in costly board re-spins and project delays. These errors come about for several reasons.

1. Getting the information. Many manufacturers include packaging information directly into the parts data sheet. Other manufacturers (TI being a principal offender) instead just cite a packaging part number and say something contrite like "See our website for the latest information". One is then forced into searching a gigantic web site to discover that packaging style WP8 is what the rest of the world calls SO8. I don't mind them decoupling the packaging information from the part data sheet. I just wish they'd get with the program and discover something called Hyper-linking (it's only been around since the 1960s).
2. Footprints are usually dimensioned as if they were a mechanical part. By this I mean that the drawing is usually rendered like most mechanical parts. Unfortunately, the layout package I use (and I suspect most of the others) treats a footprint as an electrical component. This results in all the pads being on an X-Y grid, with pin 1 usually being at (0,0). What this usually means is that one has to spend time performing a series of elementary trigonometric calculations in order to work out where to place the pads exactly. As you may imagine, this is a major source of error in footprint creation. The frustrating thing for me is that for the mechanical person providing the footprint information, it would be trivial to have their CAD system generate the information in a way that is directly usable.
3. Many suppliers of mechanical components now offer solid models of their parts on their websites. Typically the models are offered in a number of formats (ProEngineer, Solid Works etc). Thus, if I'm using say a valve from this supplier, I don't have to create the model. I just download it and incorporate it into my working drawing. Why then do suppliers of electronic components not do the same thing for part footprints? I suspect the answer is that no one ever selected a part to use in a design because it made the layout person's job easier.
4. Lastly, you may be unaware that the footprint for a surface mount part differs depending on whether it is to be reflow soldered or wave-soldered. Some companies (mainly in Europe) supply both footprints. Too many however simply supply the reflow footprint and leave it up to the lowly layout person to try and work out what the footprint should be for wave soldering.

So what's the point of this screed? Well, our industry is all about getting products to market as soon as possible at the lowest possible cost. Component manufacturers could help their customers (which in turn would help them) achieve this goal by simply providing information that removed the footprint bottleneck.

Omniscient Code Generation

Hi Tech Software has recently been making a lot of noise about its "Omniscient Code Generation". In a nutshell, the technology appears to defer code generation until the entire program has been compiled, and then look at everything before generating the final object code. The end result is a dramatically more compact (and presumably faster running) program image. I haven't had a chance to play with the compiler yet (in part because it's still in beta testing). If they have done what they claim, then Hi Tech should be commended. On my list of things to check out about the technology will be:

• Is the technology smart enough to track function calls via function pointers? If it is, then this is truly a neat piece of technology. If instead, it's one of the limitations of the product, then its usefulness to me has just plummeted.
• Does the technology also track function calls from within interrupts? My experience is that interrupt handling is still the poor relation of compiler technology. If Hi Tech does this, then I'll be impressed.

Also of interest to me is how other compiler manufacturers will respond. Keil has performed global register coloring on its 8051 compiler for years. I suspect that the Hi Tech approach is a step beyond this, so there's a chance that Keil will be finally knocked from their #1 position in 8051 code generation. IAR offers a multi unit compilation option with some of its compilers. However, this option isn't integrated into its Embedded Workbench, so it's practically useless. With Hi Tech offering compilers for ARM, PIC & MSP430 I can see this really creating a burst of competition in the industry. Excellent!

An unfortunate consequence of a 32-bit world

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:

int ivar;

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.

Application notes code quality

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.

Size matters

Periodically I get printed propaganda from the semiconductor manufacturers touting their latest and greatest ICs. Evidently the marketing folks are convinced that size matters because the size of the IC is almost the first thing they tell you now. A recent example from Maxim has the headline: "Smallest, Most Efficient and Flexible Notebook Fuel-Gauging Solution".

Well size does matter. However, it seems to me that the industry has gone too far. More and more devices are being offered only in chip scale packaging (CSP). As a result, it is all but impossible to hand build a prototype, let alone cobble together a breadboard. The result of this is that in many cases it simply doesn't make economic sense to use the part simply because CSP requires the prototype board to be machine built at a cost of thousands of dollars.

I think the manufacturers are aware of this problem and are trying to address it by offering evaluation boards. While these are OK for the breadboarding phase, they don't solve the prototyping problem. Furthermore even if the project can justify the cost of machine built prototypes, probing the part or (heaven forbid) making modifications to the board is virtually impossible. The bottom line IC manufacturers. Offer all your parts in a package that can be handled by people. Please.

Understanding Stack Overflow

I suspect that many, if not all bloggers are somewhat narcissistic. In my case it shows through in that I use one of the free services that keeps track of how many visitors I get and what brought them to this blog. Well, it turns out that many of the visitors to this blog get here not because of the brilliance of my writing, but because they did a Google search on "stack overflow" often qualified by PIC, or MSP430 etc. For many of these visitors I suspect they leave empty handed. Thus in an attempt to make these visits less pointless, let me give you my take on what causes a stack overflow in an embedded system.

First of all, go read the Wikipedia description of stack overflow. There's nothing wrong with the description - it's just incomplete from an embedded systems perspective.

On the assumption that you are getting a stack overflow and that you aren't performing recursion or attempting to allocate a large amount of storage on the stack, what can be going wrong? Here's a check list.

1. What's your stack size set to? If you don't understand the question then you need an introductory course to embedded systems programming. If you do understand the question - but don't know the answer - then this is the most likely source of your problem. How can this be you ask? Well, most embedded systems compilers are designed to work with a particular family of processors. The low end of the family may have a tiny amount of memory (e.g. 128 bytes). As such setting the default stack size to 16 bytes may be a sensible thing to do. Thus, your first step is to ensure that the stack size is set to something reasonable for your system.
   
2. Which stack is overflowing? Many processors / compilers support / implement multiple stacks. A typical dichotomy is a call stack (upon which the return addresses of functions are stored) and a data or parameter stack (upon which automatic variables are stored). If you are using an RTOS, then typically there will be a shared call stack while each thread will have its own data stack. Thus is it the shared call stack that is overflowing, or is it the parameter stack associated with a particular task? Once you've made the determination which stack is overflowing then finding out exactly what gets placed on that stack will help lead you to the solution to your problem. If you can see no obvious high level language construct that is causing the problem, then the single most likely cause of your misery is an interrupt service routine...
   
3. An interrupt service routine can use up an extraordinary amount of space on the stack. For a discussion of how this arises and its impact on performance, see this article. This problem is compounded if your system allows interrupts to be nested (that is, it allows an ISR to itself be interrupted).
4. Certain library functions (printf() and its brethren are prime offenders) can use an enormous amount of stack space.
   
5. If you are writing partially in assembly language, are you failing to pop every register that you pushed? This often occurs if you have more than one exit point from a function or ISR.
6. If you are writing entirely in assembly language, did you set up the stack pointer correctly and do you know which way the stack grows?
   
7. Have you made the mistake of programming a microcontroller that you don't understand? For example, low end PIC processors have a tiny call stack which is easily overflowed. If you are programming a PIC and don't know about this limitation, then quite frankly, I'm not surprised you are having problems.
8. If none of the above solve your problem, then I'm afraid you are most likely in to a stack over-write problem. That is, a pointer is being de-referenced that results in the stack being overwritten. This can often arise when you allocate an array on the stack and then access an element beyond the end of the array. Lint will find a lot of these problems for you. If you don't know what Lint is, see this article. If you do know what Lint is and aren't using it then you deserve to be faced with these sorts of problems.
   

Continued Fractions

Once in a while something happens that makes me realize that techniques that I routinely use are simply not widely known in the embedded world. I had such an epiphany recently concerning continued fractions. If you don't know what these are, then check out this link.

As entertaining as the link is, let me cut to the chase as to why you need to know this technique. In a nutshell, in the embedded world we often need to perform fixed point arithmetic for cost / performance reasons. Although this is not a problem in many cases, what happens when you need to multiply something by say 1.2764? The naive way to do this might be:

uint16_t scale(uint8_t x)
{
    uint16_t y;
    
    y = (x * 12764) / 10000;

    return y;
}

As written, this will fail because of numeric overflow in the expression (x * 12764). Thus it's necessary to throw in some very expensive casts. E.g.

uint16_t scale(uint8_t x)
 {
     uint16_t y;
     
     y = ((uint32_t)x * 12764) / 10000;

     return y;
 }

Our speedy integer arithmetic isn't looking so good now is it?

What we really want to do is to use a fraction (a/b) that is a close approximation to 1.2764 - but (in this case) has a numerator that doesn't exceed 255 (so that we can do the calculation in 16 bit arithmetic).

Enter continued fractions. One of the many uses for this technique is finding fractions (a/b) that are approximations to real numbers. In this case using the calculator here, we get the following results:

Convergents:
1: 1/1 = 1
3: 4/3 = 1.3333333333333333
1: 5/4 = 1.25
1: 9/7 = 1.2857142857142858
1: 14/11 = 1.2727272727272727
1: 23/18 = 1.2777777777777777
1: 37/29 = 1.2758620689655173
1: 60/47 = 1.2765957446808511
1: 97/76 = 1.2763157894736843
1: 157/123 = 1.2764227642276422
2: 411/322 = 1.2763975155279503
3: 1390/1089 = 1.2764003673094582
1: 1801/1411 = 1.2763997165131113
1: 3191/2500 = 1.2764

We get higher accuracy as we go down the list. In this case, I chose the approximation (157 / 123) because it's the highest accuracy fraction that has a numerator less than 255. Thus my code now becomes:

uint16_t scale(uint8_t x)
 {
     uint16_t y;
     
     y = ((uint16_t)x * 157) / 123;

     return y;
 }

The error is less than 0.002% - but the calculation speed is dramatically improved because I don't need to resort to 32 bit arithmetic. [On an ATmega88 processor, calling scale() for every value from 0-255 took 148,677 cycles for the naive approach and 53,300 cycles for the continued fraction approach.]

Incidentally, you might be wondering if there are other fractions that give better results than the ones generated by this technique. The mathematicians tell us no.

So there you have it. A nifty technique that once you know about it will make you wonder how you got along without it for all these years.

H1-b visas and Economics 101

USA Today has a story today about how 123,000 applications were received within 48 hours of this years H1-b visa lottery being opened on April 1. Given that there are 65,000 visas granted a year, there seems to be a large mismatch between supply and demand. Although the USA Today story talks about some of the sexy positions (Supermodels! Complete with alluring photograph!), the reality is that most of these applications are for the fields of electronics and computing, including embedded systems.

This topic interests me, in part because I came to the USA on a similar visa program (actually an E2 - but that's another story).

Anyway, whenever this topic comes up, there's normally some quote from a high tech industry executive explaining that they simply can't get enough talented folks - and hence the need for the program. Whenever, I see this argument advanced, I'm always struck by the failure of the journalist to ask a basic question - namely "What would you do if the program was eliminated?" I suspect that the honest executive would answer:

1. Lobby like mad to get it reinstated
2. Pay what I had to to get the talent I needed
3. Look to put the work where the talent is (i.e. ship it overseas).

Whereas I could probably discourse for a long time on answer 1, it's the other two that intrigue me.

The reality today is that enrollment in engineering is dropping. If one was to look at non first / second generation immigrant enrollment, I'd hazard a guess that it has all but collapsed. This is despite the fact that engineering in general (and electrical engineering in particular) is always one of the highest paying jobs upon graduation, with recent graduates earning about $65K, versus the $30K earned by your typical liberal arts major. So, what would happen if these salaries doubled? Would this be enough to attract more home grown talent in to the industry? Economics 101 would suggest that if you raise the salaries high enough then supply will rise to meet the demand. The question is, by how much would salaries have to rise?

Economics 101 also suggests that as the price of a good / service rises, it is highly likely that the consumer will look for a substitute. At present this works by bringing folks in on the H1-b program. If the program was eliminated, then I assume that this would be done by shipping more work overseas.

I guess this leads me to the point of my post. The USA prides itself on its capitalist approach - and the belief that the free market is inherently the best way to solve all (OK, most) problems. As a result, Americans normally abhor government interference in the market place. But isn't that exactly what is being done here?

If we genuinely believe in the free market, then the H1-b visa program should be abolished. Salaries would rise for engineers, more students would study engineering - and more work would go overseas. I have no idea whether the end result would be beneficial to engineers or not. It would however be ideologically consistent.

The economic purists might argue that the H1-b visa should be scrapped in the sense that anyone who wished to work here should be allowed to do so. I agree that this is also ideologically consistent. However, the reality is that the USA limits immigration in all fields. Thus to be truly consistent this would require the USA to do the same for all jobs - which is tantamount to saying there are no limits on immigration - something which isn't going to happen.

Crest factor, Square roots & neat algorithms

I've been programming microcontrollers for about 25 years now - and can count on one hand the number of times I've needed to compute the square root of an integer. This curious drought came to an end recently when I needed to compute the Crest Factor of the line voltage being used to power a product I was designing. (For the uninitiated / rusty out there, Crest Factor is the ratio of the Peak : RMS of a waveform. For example, A sine wave has a CF of 1.414, whereas a square wave has a CF of 1.000).

Why, you might ask, do I need to compute the CF? Well, the product uses triacs to control a number of AC loads. If the system is inadvertently powered from a square wave inverter, or just a really lousy generator, then the triacs will not self-commutate - and I could never turn off the loads. Thus to prevent this unfortunate scenario, I need to know how good (i.e. sinusoidal) the line voltage is. The CF is a direct figure of merit that allows me to make this decision.

Evidently, the computation of CF requires one to compute an RMS voltage, which in turn requires one to calculate the square root of a number. For various reasons, I need to compute the CF on a mains cycle by cycle basis - and I'm using a 7.37 MHz ATmega CPU. Thus, the computational efficiency of the algorithm is important.

Now IAR has a nifty little algorithm that computes an approximate square root. See http://supp.iar.com/Support/?note=18180&from=search+result

However, this gets blown away by the algorithm described by Crenshaw in his wonderful book: Math Toolkit for Real-Time Programming, CMP Books. ISBN 1-929629-09-5.

The code in his book is for computing the square root of a 32 bit unsigned integer. I adapted it to give the square root of a 16 bit integer. Here's the code:

static inline uint8_t friden_sqrt16(uint16_t val)
{
 uint16_t rem = 0;
 uint16_t root = 0;
 uint8_t i;
 
 for(i = 0; i < 8; i++)
 {
  root <<= 1;
  rem = ((rem << 2) + (val >> 14));
  val <<= 2;
  root++;
  if (root <= rem)
  {
   rem -=root;
   root++;
  }
  else
  {
   root--;
  }
 }
 return (uint8_t)(root >> 1);
}

This will compute the exact square root of a 16 bit integer in about 268 clock cycles on an AVR - i.e. in about 33 microseconds on an 8 MHz AVR processor.

To Crenshaw's point - don't just blindly use the code, but endeavor to understand how it works. Only then will you see it for what it truly is - a work of art. Thanks Jack.

Tool Upgrades

As a consultant that does hardware , firmware & software work for my clients, I use a large array of software tools - half a dozen compilers, schematic capture and PCB layout tools, analysis tools as well as the usual gaggle of productivity tools that non-engineers also use. Throw in the tools for running a business and my PC is a regular treasure trove of applications.

With all these tools, the number of upgrades / updates is starting to get out of hand. Every week, it seems I'm updating a major application. The most common scenario seems to be:

1. I haven't used a tool in a month or so.
2. I invoke it - and it tells me that an update is available. Often the mandate is 'mandatory' or at least 'recommended'.
3. I accept the update.
   
4. The download proceeds. Some of them are simply enormous (Ever downloaded the Xilinx Webpack IDE?)
5. The patch then proceeds. The time to execute the patch is often considerable.
6. Finally - the dreaded 'You must restart your computer' directive. I've a dozen applications open, web pages marked, manuals at strategic places - and now I have to close them all down.
   

Having gone through all this rigmarole, I can finally start using the tool. Of course by now, I just want to 'get on with it', and so the release notes often get cursory attention. Inevitably, if I do read the release notes then I find the upgrade is completely useless to me (e.g. support for a new device that I'm not using). If I don't read the release notes then of course there's this really neat feature that's been added that really makes life easier - and I don't find out about it until weeks later.

Well - enough complaining. Do I have any suggestions? I think so. I'd like tool vendors to realize that their tool isn't the only one in the box - and that many of us use it on a less than daily basis. With this perspective, I'd like the tool vendors to do the following:

1. Download upgrades in the background. A lot of applications already do this - they all should.
2. Inform me there is an update available when I close the tool rather than open it. That way I can allow the update to occur while I'm off doing productive work elsewhere.
   
3. Do everything you can to avoid requiring the user to re-boot their computer.
4. Limit updates to one or two a year. I know product managers want folks on support contracts to feel they are getting their money's worth - but this only works if my life revolves around that tool - and it doesn't!
   

Wanted - a new performance metric

In the bad old days, the two major performance concerns in CPU selection were whether a CPU had enough processing power and memory to get the job done. Although these are still issues, it's a rare problem that requires more bandwidth and memory than can be provided by the CPU vendors.

By contrast, today, well over half of the systems I work on are battery powered, and so I find the major question I have when designing an embedded system is 'how long will the battery last?' If you can work this out from studying the data sheets of the various CPU vendors then you're a better engineer than me.

Thus to solve this problem, I propose that we introduce a new performance metric - namely how much energy (Joules) does it take to perform a set of standard tasks. Rather than the usual bunch of quasi meaningful benchmarks, I'd like to see benchmarks such as:

1. How much energy does it take to receive and transmit one thousand characters through an asynchronous serial port running at 38400 baud?
2. How much energy does it take to perform a task switch using a standard RTOS such as uCOS-II?
3. How much energy does it take to perform one thousand A2D conversions?
4. How much energy does it take to execute a 64 tap FIR filter?

With metrics such as these, the task of choosing the best CPU (and compiler for that matter) would be made much easier. I'm quite prepared to let off the hook those vendors that aren't selling CPUs aimed at the portable market. For the other guys (TI, Atmel, ARM etc) it's time to step up to the wattmeter and be measured.

Wanted - .TEC password

It's time for my first rant - you have been warned!

I recently bought a new computer, complete with a gorgeous 24" flat panel display. The flat panel supports a speaker bar - which I also bought. The installation instructions for the speaker bar are quite straightforward - align the tabs on the bar with the holes in the display, and push until the bar clicks in to place.

Well, on my system, there's no click. The display seems to lack the spring loaded latch necessary for this to work.

I have now had four email exchanges with 'technical support'. The first didn't read what I wrote, the second told me that this was a big issue and would take several days to resolve, the third did a keyword search on 'speaker bar' and sent me a bunch of useless links, and the fourth decided that my problem was that I didn't understand the installation instructions - and so sent me another copy of them.

In short, I've been treated like a moron.

I suspect that some / many / most people that contact technical support lack, ahem, technical acumen. Well, if you are reading this blog, the chances are you are not such a person. I also suspect that you've had a similar experience - which got me to thinking. What I need is a .TEC password. Just as Microsoft's .NET password lets you manage your net identities, a .TEC password would tell the recipient that they are dealing with someone who really can, at the very least, align two tabs with their mating holes and push - and so should be treated accordingly.

Thanks for listening.

RIP VOIP

As someone that has worked in telecomms, I was excited by the arrival of VOIP. However, after two years of variable quality, extended outages and just plain weird behaviour I've had it. It's clear to me that VOIP just isn't ready for prime time and so I have decided to pull the plug. The latest frustration - an inability to receive incoming calls for the last four days - with no resolution in sight. The technical support department informs me that it's a 'router programming error'. Whether they really mean a router configuration error, or a bug in the router firmware is unclear. Regardless, it's presumably a tough enough problem that it can't be fixed in four days.

The really bad news here is my experience when I tried to get Verizon to provide me with a POTS line. One of my prime reasons for jumping on VOIP as soon as I could was my feeling that Verizon was a dreadful company - one with questionable ethics and really awful customer service. Today, despite calling the number on the Verizon website for 'add a new line', I had to endure a voice prompted menu system and three different people before I could do the most mundane thing Verizon has to offer - order telephone service. For this privilege, Verizon is charging me a $44 start up fee (to plug a few numbers into a computer) and a cost double that offered by my VOIP provider. Apparently Verizon has not had its business suffer enough - yet.

So what's the relevance of this tail of woe to embedded systems? Not much really, other than to note that when the latest and greatest doesn't live up to its billing - one ends up with very annoyed customers. So next time marketing wants to over-hype what you can deliver, rein them in hard and fast. Your customers will thank you.

Help! My third party source code doesn't comply with my coding standards

Two big trends in the embedded world are on a collision course - and the resolution isn't going to be easy. The two trends are the requirements that all code meet internal coding standards and the use of third party code.

Organizations have been gradually been getting religion about having and enforcing coding standards. As well as spelling out what the source code should look like, and making rules for what is kosher, many internal standards now also require code to be 'Lint free', and also possibly that it conform to various standards, such as those laid down by MISRA.

Simultaneously, organizations have been striving to improve productivity. One way of doing this is to turn to code re-use. Code re-use is normally discussed in the context of code that you've already developed being re-used in subsequent projects. However, a far more powerful paradigm is to use code that others have developed. Need a CRC algorithm, or a way of computing a MD5 hash - head to the Internet to find your source code. Have a need to develop a complex state handler - hello visualSTATE. Need to develop a GUI - take your pick from a plethora of component suppliers. Now if you were developing for a PC, most of this code would be supplied in binary format. However with the plethora of embedded targets and compilers, the chances are you'll get source code that you'll need to compile.

Now, the chances of the source code matching your coding standards should be nil. So what is to be done? My experiences to date have been pragmatic - but not pretty.

For small pieces of code, I simply rewrite them to bring them up to standard.
For third party libraries, such as a graphics library, it is usually impratical, if not illegal, to modify the source code, and so one is forced to accept the code as is.
For machine generated code, even if it's small, rewriting the code is pointless, since the chances are you'll be regenerating it later and over-writing your work. Thus, once again, one is forced to accept the code as is.

So what is to be done? At present, my coding standards procedure allows one to issue a variance where code doesn't comply (in pretty much the same way that MISRA allows variances to be issued). Although this is OK, let's recognize it for what it is - a cop out. What we really need are the suppliers of source code to recognize and adhere to various 'standards'. For example:

1. Use the C99 data types folks. I'm tired of seeing UINT8 definitions everywhere when ISO has stipulated that a uint8_t data type is an 8 bit unsigned type.
2. Make your code Lint free. If you're selling source code, it's in your interest to make it as clean as possible. PC-Lint from Gimpel is the gold standard, so make sure you can pass it with a clean bill of health (and I don't mean by suppressing every complaint it has).
3. Make your code MISRA compliant. MISRA can be a pain - but their intentions are good. If nothing else, making your code MISRA compliant will increase the size of your target market. This issue has been recognized by IAR to whom I'd like to congratulate for making the code generated by the upcoming new release of visualSTATE MISRA compliant.

What if you are just an honest Joe, just putting code out there for all to use and enjoy? Well why not adhere to the same rules? It'll make your code more useful - and after all isn't that the point of publishing it in the first place?

Unexpected uses and the consequences thereof

I'll pose today's blog in the form of one of those lateral thinking questions - which you may want to try and solve before moving on to the rest of the post.

An engineer walks into a meeting, unpacks his laptop and an Ethernet hub, powers both up and then connects an Ethernet cable between the laptop and the hub. No other connections are made to the hub. Explain.

Well I suppose two obvious answers are that the engineer is nuts (likely), or that the engineer doesn't understand the basics of Ethernet technology (less likely). Of course, in this case, the engineer is me, and while I can't really attest to my mental state, I do know a thing or two about Ethernet. So what is causing this strange behaviour?

Well, like many engineers, I use some very expensive software. The vendors of this software, in an effort to protect their product from unpaid copying, lock the software to the computer's NIC. (For the uninitiated, every Ethernet interface IC on the planet has a unique MAC address. Thus any computer with a NIC has a built in unique identifier). Now the vendor of my laptop (Toshiba), in a sensible effort to conserve power, powers down the NIC when it detects no valid signal on the Ethernet port. When the NIC is powered down, it can't respond to requests for its MAC address, and so the copy protection scheme complains and I can't run my expensive software.


Who is to blame here? I can't really fault the SW vendor for wanting to protect their investment, and I can't blame Toshiba for wanting to minimize the power consumption of their product. I suppose it would be nice if Toshiba provided a utility to prevent the auto power down - but that's probably inconsistent with them trying to make the system easy to use for the average consumer. I think the answer is that the fault lies with us in the engineering community. We value great tools, but apparently enough of us (and our employers) are dishonest enough that we'll copy them if we get the chance. Apparently part of the price we pay for this is looking like idiots when we walk into meetings...

Knowledge versus Understanding

Every month or two a 'Technical Recruiter' from one of the larger placement companies calls me up to see if I'm available for work. Most of the time I'm not, and so the conversation terminates quite quickly. However, once in a while I am available, and so the inevitable request for an updated resume is made. After sending an updated resume, the 'Technical Recruiter' calls back to discuss what you have to offer.

Well, for the first time in several years I recently went through this rigmarole. The conversation with the recruiter was both illuminating and yet rather depressing. To paraphrase, the conversation went like this:

Recruiter: "What RTOS experience do you have?"

Me: "VxWorks, MicroC/OSII, Embedded Linux, various bespoke systems"

Recruiter: "No others? "

Me: "Isn't it more important that someone understands the benefits and limitations of an RTOS rather than knowing the particular API of a specific RTOS?"

Recruiter: After a long pause. "Our clients like someone that can hit the ground running."

I see two possibilities here.
1. The 'technical recruiter' has no technical knowledge and is nothing more than a matcher of acronyms and buzz words.
2. His clients really are saying to him, we need someone with experience of XYZ RTOS.

If it's the latter, then it appears that knowledge is a more highly prized commodity than understanding. Personally, given the choice between someone that knows an RTOS API and someone that really understands priority inversion, can discuss the pros and cons of RMA as a scheduling algorithm, and can explain the implications of making an RTOS call from within an ISR, then I'd take the latter any day. Of course, one might claim that an experienced user of XYZ RTOS should be aware of these sorts of issues. However, in my experience, large swathes of the folks out there using an RTOS really don't have a clue about what it's doing for them - and what it's costing them.

Thus my point is this. Next time you are looking for help, think about what you'd like the person to understand - as well as what they should know. I suspect you'll end up with better help.

Fuse Blown

As a professional developer of embedded systems, I use a lot of sophisticated tools and best practices in order to create the best embedded applications I can. Today, however, I ran into an issue which makes a mockery of much of what I (and presumably you) do.

So what is this issue you ask? Well, in case you are unaware, two very popular microprocessor families (PIC & AVR & probably others) require one to configure multiple parameters in their microcontrollers via fuse bits. These parameters typically cover critical hardware parameters, such as oscillator type and frequency, brown out settings, code protection bits and so on. These fuse settings are NOT programmable from within the application and hence are typically outside the programmer's direct control. Thus a solution based upon devices in these families consists of both the programming image (i.e. the binary representation of your code) and also the fuse bit settings.

Now, this wouldn't be too bad if there was some way to combine both sets of information in to one master programming file. In fact both Microchip and Atmel allow one to do this within their IDE's. However, what happens when one needs to have the microprocessors programmed on a high speed production gang programmer? Well, I found out today - and it isn't pretty.

The procedure is to supply an Intel Hex record file for the application, and to provide the programming house with an email detailing the required fuse settings! So, after using all the sophisticated tools at my disposal to craft a working embedded system, I ultimately have to rely upon the manual transcription of configuration bits in to a programmer to ensure that the end product is actually programmed the way I need it to be.

This is patently absurd! We need an industry standard programming file that allows both the program image and the configuration bits to be defined, independent of the manufacturer, so that we can be confident that devices are programmed the way we want them to be. (Incidentally, checking a first article device is only of limited benefit, since in many cases, we want to set a lock bit that prevents anyone (including oneself) from reading anything about the device).

Does anyone out there have any ideas on how we can get this problem solved?

Legal Limbo

I don't intend to write much about political issues, since it isn't the purpose of this blog. However, when something arises that affects a lot of us in the high tech industry, then I'll make an exception. The case in point today is the proposed legislation in the US Senate that attempts to codify the administration's position on detaining terrorism suspects, interrogating them etc. I'm no lawyer, so I have to rely upon the expertise of others in understanding what the legislation is all about. In this case, I'm relying upon the testimony of Senator Patrick Leahy.

At this point, you're probably wondering what this has to do with embedded systems. Well, have a read of this excerpt from Senator Leahy (The full text appears here). I'll then make my point.

Today we are belatedly addressing the single most consequential provision of this much-discussed bill, a provision that can be found buried on page 81 of the proposed bill. This provision would perpetuate the indefinite detention of hundreds of individuals against whom the government has brought no charges and presented no evidence, without any recourse to justice whatsoever. That is un-American, and it is contrary to American interests.

Going forward, the bill departs even more radically from our most fundamental values. It would permit the president to detain indefinitely—even for life—any alien, whether in the United States or abroad, whether a foreign resident or a lawful permanent resident, without any meaningful opportunity for the alien to challenge his detention. The administration would not even need to assert, much less prove, that the alien was an enemy combatant; it would suffice that the alien was "awaiting [a] determination" on that issue. In other words, the bill would tell the millions of legal immigrants living in America, participating in American families, working for American businesses, and paying American taxes, that our government may at any minute pick them up and detain them indefinitely without charge, and without any access to the courts or even to military tribunals, unless and until the government determines that they are not enemy combatants. [Emphasis mine]

I'm a legal resident alien in the USA. Huge numbers of the people I know in the embedded systems field are also non-citizens of one form or another. I find this very disturbing and I suspect they will to. Now imagine if you were a talented person from overseas who was considering moving to the USA in search of a better life. Maybe it's just me, but I suspect that a lot of those folks would eschew the USA and opt for other pastures. If that happens, then the life blood of the high tech industry in general (and embedded systems in particular) will dry up.

Am I being overly dramatic here? Quite possibly. However, if you were, for instance, a muslim contemplating a move to the USA, what would you do if this indeed becomes the law of the land?

Reset Reason

The title of this post is rather ambiguous and can be read several different ways. This is no accident as it reflects the ambiguity that I see concerning the most fundamental event in an embedded system's life - reset. Being a consultant, I get to write a lot of my own code. I also get to read a lot of other people's code and the one area where I almost never see much thought given is to handling the various causes of a system reset. In the bad old days, you were reset and that was all you knew. Today, however, modern processors contain registers that may be interrogated to determine the cause of the last reset. For example, an AVR processor I am working with lists the following possible causes:
Power Up
Brown Out
External Reset
WatchDog
JTAG

Based on my experience, I'd say that 99% of the embedded systems out there don't care what caused their last reset. This strikes me as foolhardy. At the very least, an embedded system should keep track of the number of times it has taken a watchdog reset for post deployment quality analysis (you do do this don't you?). Furthermore, a portable system should take remedial action if it underwent a brown out reset - presumably indicating that the battery is failing. As for a JTAG reset, could this be construed as an attempt by someone to determine the inner workings of your system - and if so what should you do about it?

I have been involved in systems where support for handling the different interrupt sources has been added as an afterthought - and it shows. As a result, I've come to the conclusion that the only way to handle this is to think about it from the start, and to know up front what needs to be done for each of the different reset sources. If you go through this exercise, you'll find that your startup code becomes a lot more sophisticated. You'll also find that you've designed a better system - which after all is the point.

Datasheet Errors

As someone that also designs hardware for a living, I spend a lot of time reading data sheets. Recently I have had to deal with a rash of data sheet errors. I'm not talking about minor errors. I'm talking about colossal, fundamental errors, whereby the device simply does not do what the datasheet describes. How can this be I ask myself? I think there are two possibilities:

1. I have to wonder whether this is one of the consequences of IC design being moved off-shore such that the designers of the IC are non English speakers, and consequently are in no position to proof-read the data sheet.

2. With new ICs being introduced at a phenomenal rate, is this simply the case that so much information is being generated that these sorts of errors are to be expected hence forth?

I'm inclined to think that option 2 is the more likely. If this is the case, why aren't the engineers that are designing these parts insisting upon reading the datasheet before it's published? The next thing you know, the software industry will expect its customers to find their bugs for them...

Five Nines Reliability or POTS versus VOIP

My ISP has just recovered from a system wide crash that resulted in a 20 hour outage. Notwithstanding that it resulted in loss of email etc, it also resulted in the loss of my VOIP service. After decades of POTS , the telephone companies have rung out all the bugs and we have a service that just works. By contrast, the internet (and by extension VOIP) is still in it's infancy, such that the availability is simply pitiful by POTS standards.

I'd love to know what percentage of internet outages are caused by software failures - and I'd like those developers to have to pay me for every minute my system is down!

Encrypted email and NDAs

Being a consultant, I do business with a lot of different companies - nearly all of which require a Non-Disclosure Agreement (NDA) to be executed. Most of these NDA's require me to protect the company's intellectual property as if it was my own. So far so good. Once the NDA has been executed however, I'm continually amazed at how often I get sent schematics, source code, technical documents, projects plans etc as attachments to unencrypted email. I send out my digital signature (public key) on all my emails, so it's a trivial step for people to send me encrypted mail. It makes me wonder how many trade secrets are being lost every year simply because the default is to send out email as plain text. Shouldn't your company insist that all email be encrypted and that all external vendors provide them with public keys before any sensitive communication take place?