nerd1951.com

I’ve been reading quite a bit about the ZigBee wireless standard.  The goal of ZigBee is to create a wireless network of low cost, low power sensors.  Some of the applications might include monitoring stock in a warehouse or measuring stresses on a bridge.  But home automation seems to have caused the most excitement in the ZigBee community.

Think of light dimmers and switches that could be controlled from anywhere in your home.  The control would not have to be tethered to an electrical outlet in order to communicate with your lights.  Or, you could have a thermostat in every room with fans and baffles hidden away in your duct work to allow room-by-room temperature control.  The alarm clock in your bedroom could tell the coffee pot and the heat to turn on in the morning just before you wake up and then turn the lights on for you.  In the long run these networks of sensors could help us use energy more efficiently in our homes.  I have a couple of other mad scientist/evil genius applications in mind but I don’t want to divulge them…..  yet hehe.

The ZigBee has a number of interesting features beyond low cost and low power.  The ZigBee standard specifies an ad-hoc mesh network topology that allows nodes to relay information.  If a node wants to send a message it does not have to be within ranges of the destination node.  Any of the nodes in the network can act as relay stations and route the message to its final destination.

The ZigBee Alliance has lots of information on their website.  If you can’t wait to start experimenting with this technology, MaxStream, Inc. has development kits available for $129. to $379. and individual ZigBee transceiver modules for as little as $19. in single quantity.

That’s the question I often get along with a blank stare when I tell people what I do for a living. “Embedded systems,” I say.  “Computers that are a component in a larger system like anti-lock brakes or your cell phone.”

While wasting some time during compiles today I found a nice resource to point people to if they want to know more than my one-sentence explanation; the Embedded System Wikipedia. They have a very nice write-up that explains what an embedded system is, a little history and then some nice technical details.

So the next time someone asks you, “You write software for what?” Just send them to http://en.wikipedia.org/wiki/Embedded_system

There was a time when many C programmers understood how the compiler mapped their code into machine language. Compilers were simpler then and the C programming language was a close model of how the underlying hardware operated. This knowledge led to techniques for hand optimizing C code for maximum performance.

Processors and compilers are much more sophisticated and complex today and most programmers do not have intimate knowledge of their compilers’ code generators. The old hand optimizing coding tricks have become little more than folklore and can actually degrade performance in some cases. Modern compilers perform optimizations that would be completely non-intuitive to human programmers. The compilers are doing a lot of work behind the scenes that we don’t see or understand.

This brings me to the use of C++ instead of C for embedded systems. Most embedded systems programmers feel that C++ is not suitable for embedded systems because of vague notions about processing overhead and extra storage requirements. C++ has the reputation for generating slow, bloated code. C++ does too much behind the scenes. In reality this is just folklore that is just as out of date as the hand optimizing tricks of the 1980s. Before you decide C++ is unsuitable you need some real facts.

So where can you find the facts? I would start with Stanley Lippman’s excellent book, Inside the C++ Object Model. The object model is the central feature that distinguishes the C++ programming language from C. This book digs into the guts of the C++ object implementation and will give you a good understanding of potential pitfalls that can cause performance and resource problems with C++. This is not just folklore. The book contains actual performance figures obtained from profiling real code.

Next I would check out  Scott Meyers’ books; Effective C++ and More Effective C++.  Scott’s books are filled with techniques for writing better C++ programs many of which are aimed at avoiding problems with code bloat and performance.

Finally, do some exploration on your own. I’ll have some numbers on code I’m writing posted soon but don’t take my word for it. Write some code in C and C++ and profile it yourself. Linux and most development environments have profilers and using them can yield some surprising results. Get the facts, as Sargent Joe Friday use to say “Just the facts.”

More Scientific Truth in Product Warning Labels is a parody of consumer warning labels. The difference is that these labels apply the results of modern physics to possible but highly unlikely dangers inherent in every day things since they are made of oridnary matter.  My favorite is:

ADVISORY: There is an Extremely Small but Nonzero Chance That, Through a Process Know as “Tunneling,” This Product May Spontaneously Disappear from Its Present Location and Reappear at Any Random Place in the Universe, Including Your Neighbor’s Domicile. The Manufacturer Will Not Be Responsible for Any Damages or Inconvenience That May Result.

 I have found that test equipment and books are especially prone to this phenomenon.

Controlling complexity is the central technical issue in software development and information hiding is the most powerful tool we have for controlling complexity.  Yet many programmers just don’t get information hiding.  It seems counterintuitive that hiding something can lead to better software quality.

The human brain can usually handle four or five variables or concepts at once without losing track of something.  In typical software applications there may be thousands of small details that have to be executed perfectly.  Information hiding is simply using techniques that allow you to concentrate on a few concepts at a time.

The first tool for information hiding is the subroutine which is as old as programming itself.  Good subroutines isolate functions that operate on a small number of variables.  A well written subroutine allows you to forget about its guts so that you can focus on the next set of problems.  This is why side-effects are so problematic and should be avoided.  The Standard C Library is a good example of a set of well behaved subroutines.  C and C++ programmers use them all the time without ever having to look at the source code to understand how they work.

The module is the next level tool for information hiding.  A good module contains a set of related functions and the data that they manipulate.  Unfortunately the C language itself has no concept of a module.  In C programming, modules only exist as a set of programming conventions and only work well if everyone follows the rules.

Object Oriented languages such as C++ and Java introduced classes and objects which replace the concept of a module.  These languages allow the programmer to explicitly define information hiding in a class through the use of private and public methods and data.  The explicit semantics of information hiding in object oriented languages like C++ and Java is one of their most important features for handling the complexity of modern software applications.

They usually don’t allow me out of the lab but I’ll be presenting a ninety minute session at the Embedded Systems Conference in Boston on Sptember 28, 2006. 

The title of the session is Efficiently Coding Communications Protocols in C++ and will cover coding protocol layers as C++ classes and a threading/queuing model that cuts accross protocol layers for better performance.  The examples are based on a serial port bootstrap application that uses PPP and TFTP.

Be honest, how many of you unit test your code before downloading it to an embedded target to debug? Not many I’m sure. On the other hand, would you accept a complex FPGA design if the hardware engineer had not run a simulation on it?

In most shops where I’ve worked, a hardware engineer who tried to debug a complex FPGA without simulating it first would be considered irresponsible. You just can’t test an FPGA in a target environment as well as you can test a simulation. Yet on the embedded software side, we download code to the target without a second thought and our software is really many times more complex than even the most complex FPGA.

I’ve heard the arguments against unit testing. We have timing issues or we have hardware interfaces to debug. These arguments have merit, timing issues and hardware interfaces can only be debugged in the target environment. However, most embedded software bugs are garden variety logic errors that can occur in any software application.

The other argument against unit testing is that it takes so long to write test code that simulates the hardware interfaces. In reality, this is the same argument that every software engineer makes for skipping unit testing. Yes, it does take time to write test code but unit testing saves time in the long run.

Unit testing allows you to debug most of your code in a friendly environment. There is no waiting to download code to the embedded target. The debuggers on Windows and Linux are faster, more reliable and have more features than embedded systems debuggers. There are test frameworks, such as cunit, that run under Linux and Windows that aren’t available for your RTOS. Finally, just writing the test code can help you uncover flaws in your design. It’s one more chance to examine the functions you are implementing.

Is it really worth the time it takes to download your software to the target, set up your debug probe and walk through the code? How many times do you want to add extra logging messages or printfs to your code while debugging? Take a tip from the extreme-programming folks and write your test code first, then the code. You’ll be much happier in the long run.

What more could I say?

Geek Rhythms has produced a CD of tongue-in-cheek hip-hop tunes about engineers.  You won’t ever see them on MTV but they were featured on NPR’s Marketplace. Their song Geek Dreams may even put a little engineer swagger in your step.

I’m using the Oki Semiconductor AME-51 Evaluation Kit to develop embedded software examples for my writing projects.  The kit includes an evaluation board with OKI Semiconductor’s ML67Q4051 ARM-Based processor.  The kit also contains a JTAG debug probe and a C/C++ software deveopment suite from IAR systems.

This kit is a great system for learning about embedded systems programming or for protoyping an embedded application.  It’s a steal at under $250.