Embedded Muse 166 Copyright 2008 TGG October 6, 2008

EDITOR: Jack Ganssle, jack@ganssle.com

CONTENTS:
- Editor’s Notes
- Comm Monitors
- Book Review
- Coders Vs Programmers
- Jobs!
- Joke for the Week
- About The Embedded Muse

****************************************************************
This issue of The Embedded Muse is sponsored by Netrino.

Calling all embedded C programmers! Test your skills in the online Embedded C Quiz. In less than ten minutes, see how you measure up. No matter your score, you'll be automatically registered to win one of three colorful new iPod Nanos to be given away this month.

Start at http://www.netrino.com/Embedded-Systems/Embedded-C-Quiz-Muse
****************************************************************

Editor’s Notes

switch(city){
case San Jose:
case Phoenix:
case Austin:

Are you in the San Jose, Phoenix or Austin areas? I’ll present a public version of the Better Firmware Faster class in San Jose on December 8, Phoenix on December 10 and Austin on December 12. Registration and other info here: https://www.ganssle.com/classes.htm . You’ll earn 0.7 Continuing Education Units, learn a lot, and have more than a little fun. Sign up before November 8 and receive a $50.00 discount.
}

Emmett Kyle sent a link to this page: http://klabs.org/history/build_agc/ . If you’ve ever wanted to build your own Block I Apollo Guidance Computer, you’ve GOT to check this out!

Comm Monitors

http://www.botkin.org/dale/rs232_interface.htm

This is a circuit I've used in production for several years now with no issues talking to a wide range of PCs, laptops and other serial devices.”

Book Review

The MSP430 from TI is a 16 bit RISC-like microcontroller that sports extremely low-power modes and a nice mix of on-board memory and peripherals. TI offers some cool low-cost development platforms. Once a stealth part, it has garnered great market share.

An intro to embedded? Yawn, right? No, stay with me.

John shows aspiring developers how to write a simple C program to turn an LED on, first in C and then in assembly. These are complete tiny apps that will compile/assemble. He describes the intent of each line, and couples that description to the hardware design. He then reframes the assembly into relocatable code and shows what that is all about.

An intro to embedded C and assembly? Double yawn. Nope - hang in there.

Using the same careful explanations he grows the discussion to use buttons, timers instead of delay loops, and much more. The lessons are complete, detailed, and clear.

Then the good stuff starts for working MSP430 engineers. He describes in clear detail with code and hardware designs the use of the MSP430 and its peripherals. Need to run the SPI in a particular mode? The code is there. Want to get interrupts up? Just copy the listings (there’s no CD but he does provide a web link to the code).

He keeps drilling deeper, giving more complex examples that are all directly useable by any MSP430 developer. Oscilloscope traces, where applicable, ground the discussion into the physical effects we engineers need.

The MSP430 does have analog I/O, and John doesn’t neglect that. He talks about aliasing, signal/noise ratio issues, and handling the A/Ds. Yep – the math is there, too, not complicated at all, but essential to working with analog. A CS person or novice EE would learn a lot about electronic circuits from this material.

Unusually, this book is both a great introduction to embedded systems for the novice, as well as an incredibly-useful reference for experienced developers. Highly recommended. The folks at Newnes Press have offered Muse readers a 20% discount good till the end of the year – go to www.newnespress.com and use discount code 93682.

Coders Vs Programmers

Unless, of course, he or she is referring to a peon who does nothing but crank code.

Historically “coder” means someone who translates a very detailed design to C, C++ or whatever language is used. In the old IBM “chief programmer” days coders were an important part of the development team, but were at the bottom of the pyramid. It was assumed these folks were trainees or had little expertise, so they slaved at more or less rote translation activities. Coders were analogous to draftsmen, those skilled technicians who render engineering concepts into the important but dull drawings needed to actually build something.

Let’s face it: it’s not hard to write code. Even teenaged hackers manage to build simple systems. UML advocates often demonstrate that the machine itself can write the code from a sufficiently-detailed design.

The challenge we engineers face is designing a solution to a particular problem. I believe the real fun is in inventing the solutions, not in the dreary coding process. For me the most exciting and creative part of a project is doing the rough system design, figuring out what should be done in hardware and what in the firmware, and then blocking out the overall approach.

But the only complete design spec tends to be the code. There are a hundred little decisions we make as we type in C statements, from oddball exception handling to what happens if some really weird combination of inputs happens. What happens if the user presses all three buttons, belches and kicks the machine? In my experience virtually no design document captures every essence of what the program will really do.

In the embedded world there are few true coders. We’re highly trained engineers who code and design together, or who create the structure and then implement it in firmware. Perhaps we’d be more efficient if we did separate designers and coders, but this seems unlikely to happen. It’s certainly valuable to keep ones hands in the dirty business of actually making the system and getting it to work. The crucible of making things work always teaches us a lot about the limits of what we can actually build.

The “coders” word is usually used by managers who view software as a necessary evil, rather than a critical part of the value delivered to the customer. That attitude dooms projects and frustrates the staff.

Desktop developers embrace “programmer” as a job description. Perhaps that adequately captures the limited range of skills needed to crank out a Windows app. Me, I prefer “engineer”, a moniker that better describes the breadth of experience needed for embedded systems, where hardware and software seamlessly blend together to yield a product.

Jobs!

Joke for the Week

So how long is an attosecond? It is 1/1000 of a femtosecond. How long is a femtosecond? A femtosecond is one millionth of one billionth of a second. Or in scientific notation, a femtosecond is 1*10^-15 (1E-15), and thus, an attosecond is 1*10^-18 (1E-18). Or for short (pardon the pun), an attosecond is an insignificant amount of time.

Does this mean when your boss gives you an attoboy, he is giving you an insignificant amount of praise?

Free Embedded Muse newsletter - twice/monthly, hard-hitting technical info that goes to 48,000+ engineers. Click here to sign up or enter your email here: