(C) 2009 Hank Wallace
PREVIOUS – Embedded System Design Library: Selecting Features
NEXT – Embedded System Design Library: Myths
This series of articles concerns embedded systems design and programming, and how to do it with excellence, whether you are new to the discipline or a veteran. This article is about raw programmer productivity.
Do you understand what I mean by programmer productivity? If it takes you 10 hours to write a program, and the geek in the cubicle next to you takes 5 hours, you had better be updating your resume or working on your PhD. A productive programmer spends the minimum amount of time and money writing, debugging, documenting and deploying a program, and diagnosing problems in the field.
The first productivity block you need to examine is the toolset you use. Most of us use the IDEs (integrated development environments) that come from the manufacturer of the chip or system we are using. I have licensed IDEs installed from Microchip, Atmel, Cypress, Motorola, IAR, Hi-Tech, and on and on, about a dozen of them, total. And there are multiple versions of some, for example Microchip’s MPLAB. I have customers who insist on sending me MPLAB project files which I must open, so I have to keep old versions of MPLAB hanging about.
Each of these IDEs is different and klunky and hideous in its own way. Every one of them appears to have been written by graduate co-op students on summer break, with cool menu features and windows that have no useful function (see the last article about feature selection). There is zero interoperability between these IDEs, though some IDEs can be configured to call competitive compilers, if you have ten hours to spare.
These IDEs have different user interfaces, differing debugging capabilities, varying command structures, and disparate feature sets. They are all touted as the ‘best’.
And the editors in these IDEs are generally lame, not concentrating on productivity, but rather on cartoonish contextual coloring of source code.
Using these IDEs is a challenge because they do not work consistently. Most IDEs and emulators I have used (with the exception of the 1970’s Intel MDS800 — the ‘blue box’) have such quirky behavior that one must resort to a randomly determined procedure to get them to work. It’s kind of a Monte Carlo Emulation user approach, where you try this and that until you find the magic combination of commands and/or activities that gets your project moving. To that end, I have created a useful tool, a spinner device similar to what you find in board games. Next time you are befuddled by a poorly tested IDE, print this out and stick a bent up paperclip in the center as a spinner. You will soon have the answer to your problem.
As an employer, when I hire a programmer, I expect to see their hands on the keyboard, feet on the floor, eyes on the screen, hammering out code, documenting and debugging. When I see a hand on a mouse, I bite my tongue, and watch the dollars twirl down the drain.
The first programming productivity tool you need is a good programming editor. For years I used Brief, only because it was totally configurable. It’s not available now. Many programmers use EMACS or VI. Such editors, and others, are optimized for programming, not word processing. They are not based on some Microsoft edit component. They are fast and lean, with macro capability that makes repetitive programming tasks easy. If you are spending time positioning that razor thin caret between lower case L’s in your program, you are wasting time. Learn how to program without using a mouse and your productivity will double.
If you program without using macros, you are also wasting time. Using macros, you can cut and paste a listing of pin functions from a data sheet and programmatically transform the list into a compilable set of definitions in a header file. All that manual typing would take literally hours.
Some windowing editors and IDEs have macro capability, but the mix of keyboard and mouse activity confounds many macro recorders. Be careful when selecting an editor to be sure you get one with a good macro capability.
You might ask, if the usability of IDEs is so poor, how does one find bugs? Sometimes I do use the IDEs to find bugs by single stepping and examining variable values, but not often. In most cases, the IDE is good for loading and starting a program on the target. Many bugs are obvious after examining source code and the source documents, such as state machines. You won’t find me spending hours and hours stepping through code trying to determine what’s happening, because I already emulated the entire program thoroughly with my brain. (Programming is not a job or an art, it’s a discipline.)
Some IDEs and micros (most notably Microchip) require modifications to the firmware to allow debugging. This is a hideous disaster, and the notion that I should have to adjust my program to work with a debugger is sooo 1978. Did these companies never hear of JTAG?
Most compilers allow use from the command line. I generally use my favorite programming editor, then run the compiler from a make file from the command line. It generally runs faster than from within the IDE. Additionally, many IDEs pass a multitude of options to the compiler, and there is precious little way to know what the IDE is telling the compiler to do.
On a recent job, I watched as an engineer in another company spent two solid days trying to get a compiler/IDE configured correctly to program a PIC so that it would run with the proper memory space setup. When I was handed the project, I quickly created a make file which called the compiler directly, avoiding all that foolishness.
Given the propensity for vendors to update IDEs and kill any project compatibility, it only makes sense to have a make-based compile/link capability for your projects. After you are hit by a truck on the way to work, your successor will quickly understand all she has to do is type MAKE and press ENTER to rebuild your hugely overcomplicated and feature rich program!
Another productivity enhancer is writing programs that code for you. For example, a recent project required me to squeeze a 7500 element database into a tiny embedded OTP micro. The data was musical in nature, and an extension to a similar 4000 element database which contained some known errors, and while there were some patterns to the data, there were exceptions as well. I could have created the database by hand, but that would have taken months. I instead wrote a 10,000 line program to algorithmically generate the new and check the old and new data. That program took several days to write, but updates to the database are easy.
That program also generated C source code containing all the definitions and static data declarations. When the customer asked for modifications, I edited the generator program and ran it again, having confidence that the entire output was checked for errors and internal consistency.
I’ve also written programs that determine data tables quickly. Those programs can easily print source code for direct inclusion at compile time in header files. Using a spreadsheet to create the data works also, but then you need to write a macro to massage the information into source form.
As another example, I had an MSP430 controlling the user interface and general functions of a DSP audio product. The MSP430 loaded code into the DSP depending on user selections, and also changed instructions within the DSP in real time to control the sound effects being produced. Getting the MSP430 to seamlessly know what instructions in the DSP to change was a challenge and potential bookkeeping nightmare.
The solution was to write a program to parse the DSP source code for specific text tokens and save that information for the MSP430. For each DSP audio effects routine, the MSP430 was then provided with the location and purpose of each algorithm variable, so it could modify them in real time. Changing the relationship between the DSP and MSP430 programs required only running the parsing program I wrote, and recompiling.
Remember, embedded programming is about economically creating working, functional products in a reasonable amount of time. It is not about syntax coloring, configurable IDEs, glitzy windowing systems or XML. Collect a set of tools that will allow you to be productive.
Author Biography
Hank Wallace is the owner of Atlantic Quality Design, Inc., a consulting firm located in Fincastle, Virginia. He has experience in many areas of embedded software and hardware development, and system design. See www.aqdi.com for more information.