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.

• Editor's Notes
• New! Public Better Firmware Faster Class near Boston
• Quotes and Thoughts
• Tools and Tips
• What I'm Reading
• The FRDM-KL25Z Eval Board with mbed
• Visualizing Code
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that it’s not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See https://www.ganssle.com/onsite.htm.

I will be doing a public version of this class on November 1 in the Boston area. There's more information later in this newsletter.

The Muse has been on holiday for the summer, but is resuming publication with this issue. I have been on the road, spending most of two months overseas on a number of separate trips. It's always great to meet engineers in every corner of the world, and to see how many problems are shared across very different cultures.

The upside of the travel is that experiments I've been running since last year can continue to collect data while I'm gone. If you're following my articles on embedded.com you know I'm exploring the issues in ultra-low power systems, particularly those that must run from a coin cell for years. Turns out no one knows much about how coin cells behave in these applications, so I've been discharging them slowly to profile their operation. The experiments have collected hundreds of thousands of data points on Energizers, Maxells, and Panasonics; Duracells are on the test jig now. I'll be sharing the data soon.

Bob Kritchevsky writes:

If you know of a place to donate boards, let me know and I'll share that with readers.

What? No Embedded Systems Conference this Fall in Boston? The show was canceled; now there's just the West Coast version in April.

It's not the ESC, but I'll do a public version of my one-day Better Firmware Faster class near Boston November 1. It will be held at a hotel near Routes 90 and 495, about 38 miles from Boston's Logan airport and 39 from TF Green (Providence, Rhode Island). This is the first public version of the class in two years.

This is a very fast-paced (and fun!) full-day course that teaches better ways to produce firmware. I'll show how to drastically cut bug rates and shorten schedules. Plus, I cover technical issues that are unique to embedded systems, like dealing with real-time issues.

The average IT shop removes just 85% of the system's bugs prior to shipping; firmware companies get 95%. We embedded people do much better than the rest of the software industry! But 95% means we're still shipping with 3 to 4 bugs per thousand lines of code. We can - and must - do better. Studies show that fewer bugs nets faster delivery. That's what this class is about.

There's more information here, and this is the course's brochure.

Seating is very limited so sign up today.

A client reported better than an order of magnitude improvement in quality over 7 quarters using the techniques from this class.

"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live."
- Martin Golding

Please submit neat ideas or thoughts about tools, techniques and resources you love or hate.

Tony Whitley suggested:

Luca Matteini likes yEd:

Experimental Security Analysis of a Modern Automobile - The results are scary. Makes me yearn for my old 1966 VW Beetle.

How Technology is Destroying Jobs – MIT Technology Review, Jul/Aug 2013. There have been a lot of articles lately showing how tech is replacing jobs; this is one of the better ones. A fascinating graph shows GDP per capita going gangbusters while household income is sinking. Unlike some of these articles, the author notes that recent employment downturns may not be a result of tech; it’s hard to isolate such factors from other macroeconomic trends.

Learning from the Past to Face the Risks of Today - Communications of the ACM June 2013. The story of lessons learned from developing spacecraft software, by noted researcher Nancy Leveson.

Undefined Behavior: What Happened to My Code? and Defining the Undefinedness of C - Two papers exploring sometimes unappreciated gotchas in C.

If you haven't checked out mbed.org, do surf over to that site. The short story is that these ARM folks have several low-cost single-board computers based on Cortex-M series MCUs. Though one can use traditional development tools to build systems around the boards, they also give you access to a free on-line compiler. Using just a web browser one types in the code, presses compile, and a binary file immediately downloads onto your computer. The mbed boards connect to the host computer via USB and look like flash drives; copy the binary to the drive, press reset on the board, and the code starts to run. Since it's web-hosted, you can use a Windows, Mac or *nix host system.

It's time-consuming and frustrating setting up a modern IDE. Then one has to learn the environment's nuances just to get a lousy "Hello world" program to run. With mbed's on-line compiler one goes from zero knowledge about their tools to a working program in about five minutes.

But there's more. Though I'm a huge fan of the Cortex-M, these are very complex parts with I/O that's sometimes baffling to set up. The mbed folks provide libraries that make using the peripherals practically trivial. For instance, this is a complete program that toggles bit 2 on GPIO port C:

#include "mbed.h"
  DigitalOut port(PTC2);

int main() {
  while(1) {
    port=1;
    wait_ms(100);
    port=0;
    wait_ms(100);
  }
}

No complicated pin setup required. DigitalOut associates the pseudo-variable "port" with pin PTC2. The wait_ms(100) function waits 100 milliseconds, and is also part of the rich set of support functions mbed provides.

Here's a complete program that maps in a filesystem to write to the MCU's flash memory. It creates a file named out.txt. This makes building data loggers trivial:

#include "mbed.h"
int main(){
  LocalFileSystem  local("local");
  FILE  *fp = fopen("/local/out.txt", "a");   
  fprintf(fp, "\n  Writing to flash memory");
  fclose(fp);  
}

It's equally simple to printf to the USB port. Use Teraterm or a similar program to capture text on the host computer

I recently bought Freescale's FRDM-KL25Z eval board from Digikey for the princely sum of $12.95. That's right, 13 bucks for a 32 bit MCU on a board with a couple of USB ports, accelerometer, and capacitive touch slider. ("FRDM" is a whacky mnemonic for "Freedom" as in "Freedom Development Platform.")

mbed supports this board. There's a little bit of setup required to switch from Freescale's native software to mbed's, but that's only a couple of minutes work, and then the on-line tools are available.

Freescale's user manual is short and not completely correct (e.g., the power section does not reflect the latest board rev, though the schematic is correct). It also has nothing useful about the mbed tools, so go to mbed.org for more information.

The FRDM-KL25Z board

Freescale's has done an excellent job with their Kinetis family of Cortex-M MCUs, offering a range of variants that address many deeply-embedded needs. The FRDM board is loaded with a Kinetis KL25Z128VLK4 MCU, which is a Cortex-M0+ CPU sporting 128 KB of flash that runs at up to 48 MHz. It has an unknown amount of RAM (the microcontroller's datasheet says "up to 16 KB"; Digikey's web site says "16 KB"), and includes USB and the usual raft of peripherals.

Most of us will not use some of the features, but do try one of the accelerometer demos available on the mbed site. I found the one that couples inclination to the color space of the RGB LED pretty cool.

The board does not come with headers, which you'll almost certainly want, but those are cheap from the usual distributors.

I am amazed by biotech’s ability to image and create two and three dimensional models of the microscopic world that’s far beyond our human senses. Scientists have developed tools that morph a molecule’s structure into these strangely beautiful and (to a biologist, I guess) very descriptive views. The ability to see, rotate and manipulate the models leads to insight and understanding.

A visualization of an entire insulin molecule.

We in the firmware world also manipulate and create tiny, unseen objects. Create? Not really; the electrons flow out of the wall socket. Move? No, transistors gate the flow of current. Maybe “organize” is the operative word. But even “organize” implies a process of sorting, which implies there’s something being rearranged. One might argue that a program actually exists as charges embodied in Flash memory, or magnetized areas on a disk, or a stream of bits poring over a ‘net connection. Yet none of those are essential elements of software; it’s a fungible non-commodity perhaps best described by not-terribly enlightening word “enthalpy.”

Our job is to reduce entropy, to struggle against the Second Law of Thermodynamics. Put that way it sounds pretty noble!

So we’re building, or organizing, things of enormous complexity that don’t really exist. And we’re doing that with extraordinarily crude tools. Microbiologists can look at a picture of Insulin and even build a 3-D representation. They can see exactly how a ketone, for instance, might bond to the molecule.

But we’re single-stepping through source code, squinting through a tiny window at only a few lines at a time of a mega-LOC monster.

Our "visualization" gives us a tiny snapshot of the system. It's like looking through a keyhole.

Architects build scale models of their proposed buildings so the customer can see exactly what he’s getting, and the designer can visualize the structure in something close to its ultimate reality. Civil engineers do the same; they’d never plop a foot-thick structural analysis on the mayor’s desk. Aeronautical engineers use 3-D representations on the computer screen to find parts that interfere with each other.

Where visualization techniques don’t exist the problem is usually poorly-understood. Neurologists’ MRIs and PET scans produce only macroscopic, blotchy patches depicting blood flow. They can zoom in on individual synapses, axons and dendrites with an electron microscope, just as we can completely understand a gate. But such Descartes reductionism hasn’t, as yet, taught them how the brain functions.

Code, of course, is generally incomprehensible and our attempts at abstraction mostly pathetic. Flow-charts, data flow diagrams and even UML drawings are not pictures of a program; they’re analogies, different ways of expressing the ideas embodied in the software. But analogy is indeed all we have.

I’ve tacked the Insulin picture over my desk to remind me of the poor state-of-the-art of software development, and continue to search for other analogies that can more graphically illustrate the meaning of our code.

“Code” is indeed the correct word to describe our creations, for we take a crude specification and transcribe it into a computer program using a ciphering system not unlike that of the Enigma machine. “for (i=0; i++; i<end)fn(i);” means nothing to our customers – it’s a code that does somehow instruct the machine to do something. But there’s no direct correspondence between even those cryptic phrases and bits in the computer – a compiler surely scrambles and optimizes the for loop into dozens of instructions scattered nearly at random over perhaps thousands of bytes of memory. Once smart developers could understand machine code, but now with RISC machines and highly-optimizing compilers that possible only with extreme effort.

The three actors in our drama – customer, programmer and machine – all speak different languages poorly bridged by inadequate tools.

The future surely must hold a different analogy for software development. Our brains have huge vision centers, which is why we understand best via graphics and visualization techniques. But those depictions have to have a ring of the familiar, as does the image of Insulin. We need a different way to visualize computer programs, something that’s visceral and dramatic. Something that’s a far cry from a 50 pound listing.

Someday we’ll have a virtual reality environment that puts programmers into the center of the software, to illustrate data movement and real-time events. There will be a zoom control that lets customers back off from details yet clearly see the features. Managers will get a different view entirely, one that shows details of development progress, quality and costs both incurred and projected.

After all, a picture is worth a thousand functions.

What do you think? Is the future merely more dreary source level debugging and heroic translations of inadequate specs into C?

Let me know if you’re hiring embedded engineers. 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.

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

Advertise in The Embedded Muse! Over 23,000 embedded developers get this twice-monthly publication. .

The Embedded Muse is Jack Ganssle's newsletter. 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.