Go here to sign up for The Embedded Muse.

Embedded Muse 216 Copyright 2011 TGG November 7, 2011

You may redistribute this newsletter for noncommercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go to https://www.ganssle.com/tem-subunsub.html or drop Jack an email at jack@ganssle.com.

EDITOR: Jack Ganssle, jack@ganssle.com

Editor's Notes

Lower your bug rates. And get the product out faster.

Sounds too good to be true, but that's the essence of the quality movement of the last few decades. Alas, the firmware community didn't get the memo, and by and large we're still like Detroit in the 1960s.

It IS possible to accurately schedule a project, meet the deadline, and drastically reduce bugs. Learn how at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/onsite.htm .

Quotes and Thoughts

printf("Goodbye, Dennis");

/* From The Economist */

big.LITTLE

Once upon a time computers were so expensive that they were used sparingly. That persisted far into the microprocessor age. But in many cases things have changed; a lot of embedded systems today sport multiple, even hundreds, of CPUs.

Declining silicon costs enabled this, of course, and increasing computational demands encouraged it. Other factors have had a hand as well. It's interesting that so many systems use a big processor running Linux, to take advantage of the GUI, filesystem, networking and all, and one or more additional CPUs to run the real-time, deeply embedded aspects. This is a triumph of reuse. And it's a very strong statement about how much has changed in the 40 years (this month) since the 4004 was introduced. Computers are now so cheap it's common to add them to reduce software development costs.

But there are other reasons to toss in more processors. ARM's just-announced big.LITTLE strategy marries a Cortex-A15 (a honking-fast CPU designed to power the most demanding smart phones) to a Cortex-A7. The A7 has the same architecture as the A15 but is designed to trade off performance for better power efficiency. TI's OMAP5 couples a pair of Cortex-A15s to twin Cortex-M4s, but those two architectures are very different. With an A15/A7 combination applications can migrate between cores. The idea is to shut down the power-hungry A15 when running relatively undemanding code and use the A7. (To ensure maximum complexity, ARM talks about clusters of CPUs; a typical application will have multiple A15s and A7s.)

The company claims various benchmarks put the A15 at two to three times faster than the A7, but the latter uses two to four times less power. How much power? ARM doesn't say, at least anywhere I can find. It's dependent on a lot of factors, like process technology, and I suspect we'll see few naked A7s or A15s; most will be buried in an SoC. There will be a lot of other power-consumers on those chips.

The Cortex-A7 in 28 nm geometry occupies just 0.5 square mm, truly a minute amount of silicon.

Unsurprisingly, the target market is mobile phones. The industry expects that ARM licensees will release their first products using the big.LITTLE technology in 2013.

Interesting Sites

http://www.eeweb.com has a number of interesting places for electronics people. I find the "toolbox" (on the upper right part of the screen) especially useful.

Another site worth checking out in these power-challenged days is http://low-powerdesign.com.

When interviewing I always ask candidates (those with experience) about their dumbest mistake and what they learned from it. Those with no mistakes are generally those with no experience - or are perhaps truthiness-challenged. Do you have any?

Tom Harris had a few submissions: "I don't know if these qualify, but they follow a pattern. On the positive side, they were attempts at more efficient life through programming, which is why I got into programming in the first place. On the negative side, though, they almost lost me my job.

"My very first job involved typing names and addresses from the phone book into a computer, for a marketing mailing list. This dates me as well before phone books on CDs let alone internet. The interview was a phone call, from a 15 1/2 year old (me) with a newly-minted work permit, which I almost blew by saying I knew how to program. The hiring manager said, "you can't have the job -- you'll be bored." I promised up and down that I wouldn't, and rushed over on my bike before he changed his mind. A few weeks into the job, I discovered that though I typed quickly, I could go faster if I didn't have to press <Enter> after each name and address. So I modified the data entry system to recognize the last field in a record, save, and go to the next one. The boss was mad! I had modified his production code, and proven, from his point of view, that he should never have hired a programmer. I begged to stay, and he gave me my own account on the machine as long as I promised to stay out of his code. That satisfied me -- I went back to inefficiency in data entry, and occupied my off hours writing a program to generate 3D mazes. And then another one to solve them because they were too hard. So I'm not sure which part was the dumb part, but I did almost lose the job twice.

"A later job started on a Friday morning when I was between jobs and bored. A gum-chewing temp agency secretary saw me walk in, said, "You, buddy, you know Lotus 1-2-3?" I said I did so I started right away Monday at the legal department of a major entertainment company. (True. I could not make this up. All the visitors to the office were either lawyers in suits or people with funny hair -- the clients.) My job was to type financial records from paper printouts into the computer. I did ask why, if there were computer printouts, they couldn't just copy the files from the computer that had printed them. I was told that the tapes were lost. All paid the same for me. Here I noticed that some of the columns of numbers were dependent on others. Since I had been hired for knowledge of Lotus 1-2-3, I modified some of the columns to contain formulas so I wouldn't have to type the numbers. When the boss found out, he told me I'd have to do it over manually, without formulas! Why? Because the data was going to be evidence in a court case, and if there were formulas, the other side would claim that the data was not unmodified. So I retyped that data, but at the end of two weeks, decided I'd had enough. The boss was shocked -- I was leaving already? I pointed out that I was from a temp agency, so short-term assignments were not surprising, but just out of curiosity, asked how long he had expected me to stay. His answer: "Forever! You were doing a great job!" Again I'm not sure which is the dumb part -- left as an exercise for the reader.

"Finally, your reader Steve Litt sent a link to his website ostensibly as a submission to this same "dumbest things" category. True, the page he sent did fit that, but I browsed his site about troubleshooting, including, but not limited to http://www.troubleshooters.com/tuni.htm#_The_10_step_Universal_Troubleshooting, and found it impressive. He has put into words what makes the go-to people for solving problems, while also showing the importance of maintaining "right attitude" so that we don't do dumb things ourselves. At least not too often."

Anja Zoe Christen sent this: "Concerning the story of the dumbest thing one did; (un?)fortunately it wasn't me, but applying an unsuitable input voltage to some piece of hardware by accident or dumbness isn't as uncommon as you might think. One of my favourite was a guy whose sleeve caught the voltage knob of the power supply and before you could say "oops", the circuitry was powered by 12V instead of 3.3.

"Much better in terms of long-term effect were the guys at another facility within a big company, who connected an array of about 100 antenna amplifiers not to the usual 28V bus voltage, but 100 voltage unregulated primary voltage. Was slightly inconvenient for the budget and schedule so to say...."

From anonymous: "I was cleaning up some old files and found something I thought you might enjoy. Years ago, I once worked on a large development effort for a product we designed and built for another company. At the time the project started the engineering group lacked embedded developers so three contractors were hired to design the software architecture and get the work started.

"One contractor in particular had the most peculiar programmer style. He was an old time 8051 assembly programmer who could program assembly code in any language. He also insisted on using cryptic 8 character variable names for everything. My belief is that he thought that if he made his code obscure enough he would ensure that we would hire him to maintain the code.

"Here is an abbreviated example of how he coded.

void nvNVbftRA(void)
{
     unsigned char bftpzcnt        ;
     far unsigned char *bftpzfpt   ;
     far unsigned char *bftpzspt   ;
...
     for (bftpzcnt = OTBCCNT +1, bftpzfpt = nvNVbuff + OTBCCNT, bftpzspt
= nvNVbuff + OTBCCNT + NVPAGSZ;
     bftpzcnt != 0 ;
     bftpzcnt--, bftpzfpt--, bftpzspt-- )
     *bftpzspt = *bftpzfpt ;
...
}

"Note that most of the strangely named variables are local to the function and are only used in the for loop. What makes this even worse is that all of this bizarre looking code could have been replaced with a single call to memcpy. His code worked, but it was not a lot of fun to work on.

"Over the years, the subject of providing the source code to the customer was discussed several time and one of the project leads suggested that we run a code obfuscator program on the source code if forced to turn it over. I reassured him that this would not be necessary since the contractors had already done the equivalent of that on their code.

"Two years after the project completed I attended my first Embedded Systems Conference and one of the presentations was on the top 10 things not to do in an embedded development project. Turned out we had embraced 9 out of 10 one of these things in that project. The only thing we got right is that we used a version control management tool (PVCS). From memory (I don't have the bad 10 list in front of me).

"- Didn't use an RTOS because we thought we couldn't afford the overhead. Instead we used interrupts and a round robin scheduler. Problem was making sure that time critical stuff got done on time. To do this each thread (I am using the term thread very loosely here) included state logic to ensure it didn't try to do more than permitted when it was its turn to run. An RTOS would have greatly simplified the design of the software and most like would have consumed less memory and run faster in the process. I think the real problem was that the contractors were unfamiliar with RTOS and didn't want to expose this. If the only tool you know how to use is a hammer, then screw heads are going to get battered.

"- All thread communication was by means of shared global data. Each thread's state control variables were global and threads examined (and changed!) each others state control variables to accomplish necessary interactions. It took me years to smoke all of these unnecessary close couplings out the project code (I performed maintenance on the code for the life of the product).

"- Used a single global.h file that contained ALL global variable definitions for both the C code and assembly code (interleaved definitions with creative use of c and assembler comment symbols). To make it even more complicated the project was written to compile both 8051 and 8051XA versions of the code (we had both a lower cost simplified version and higher cost more complicated version of the product compiled from the same code base). The preprocessor really got a workout each time you compiled the code.

"Best yet, one of the contractors (the guy from the obfuscated code example above) managed to force an overly complicated variable type naming convention on us that that was like Hungarian notation on crack. For example a far unsigned char was defined as a FUCByte and yes we pronounced this just like you would expect us to.

"I can't remember the rest of the "10 Don't Do this" list, but we found examples in this project for each of the other rules. It was amazing that we not only got the project done early, but that it was a very successful product. We had a great marketing guy (from the customer) who did an excellent job of knowing what he wanted the product to do and prioritizing functionality. We would not have succeeded without him."

Jobs!

Let me know if you're hiring firmware or embedded designers. No recruiters please, and I reserve the right to edit ads to fit the format and intents of this newsletter. Please keep it to 100 words.

Joke for the Week

Note: These jokes are archived at www.ganssle.com/jokes.htm.

From Craig Heilman:

An engineering student was walking across campus when another engineer rides up on a shiny new motorcycle. "Where did you get such a great bike?" asked the first. The second engineer replied "Well, I was walking along yesterday minding my own business when a beautiful woman rode up on this bike. She threw the bike to the ground, took off all her clothes and said 'Take what you want.' The first engineer nodded approvingly "Good choice; the clothes probably wouldn't have fit."

About The Embedded Muse

The Embedded Muse is a newsletter sent via email by Jack Ganssle. Send complaints, comments, and contributions to me at jack@ganssle.com.

The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get better products to market faster. can take now to improve firmware quality and decrease development time.