You may redistribute this newsletter for noncommercial purposes. For commercial use contact firstname.lastname@example.org.
The quality movement’s central observation is that building in quality inevitably results in lower costs. That’s the focus on my Better Firmware Faster course. It is possible to accurately schedule a project, meet the deadline, and drastically reduce bugs. Bring this class to your facility. More info here.
I'm now on Twitter.
|Quotes and Thoughts
"Theoretically, Software is the only component that can be perfect, and this should always be our starting point."
- Jesse Poore, IEEE Computer January 2004
|Tools and Tips
Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.
Last Muse Rod Bartlett recommended the grep-like tool ack!. Chris Lawson is a fan as well and sent this write-up:
ack! The greatest Linux tool you've never heard of.
If you've done any development on a Linux system, you're probably familiar with grep. Grep is a wonderful tool for searching through files to find a text pattern. Grep is invaluable for finding where certain variables and functions are used throughout code. However, as you may have quickly found out -- you need to tame grep with few command line options. Also, if you're using version control, or have compiled the project, or generated any documentation, you'll want to use find to weed out all the generated files (which also contain the text string you are searching for) and pipe that output into grep.
Fear not! There is a tool that does all this for you, and it's called ack! Ack was designed for programmers, so it only looks through source files and has most of the options you want enabled by default -- greatly reducing the number of keystrokes required for your search. Ack is available on OS X and many Linux distributions, including Ubuntu. Check out the installation instructions from their website. For OS X you will first need the "Homebrew" package manager. Debian based systems (such as Ubuntu) can just use apt-get. Due to legacy issues, ack is called ack-grep on Debian systems. Thus, I would recommend the follow-up modification to change the name to 'ack' on your machine.
OS X Install (Using Homebrew)
$ brew install ack
Ubuntu (Debian) Install
$ sudo apt-get install ack-grep
Ubuntu (Debian) name change
$ sudo dpkg-divert --local --divert /usr/bin/ack --rename --add /usr/bin/ack-grep
$ sudo cp /usr/share/man/man1/ack-grep.1p.gz /usr/share/man/man1/ack.1p.gz
What are you waiting for?! Go check out the website!
Dave Kellogg wrote:
Jitesh Patel had some tool suggestions for documentation:
|Freebies and Discounts
Thanks to the generosity of Imagecraft and BusBoard Prototype Systems we're having lots of giveaways this month. Feel free to enter both contests.
First, BusBoard has given me five of their Blinky Lights prototyping kits, which are designed to teach youngsters and the young-at-heart the fundamentals of electronics. I'll give one away each Friday for five weeks.
And there's a Jumpstart Microbox from Imagecraft, widely known for their inexpensive development tools. The Jumpstart Microbox contains a Cortex-M0 board, a shield with I/O, a new book about embedded C programming, and the toolchain. An included library makes working with the normally-complex I/O very easy. A winner will be selected before the next Muse. Enter via this link.
|Software is Too Important to be Left to Programmers - Take 3
Charles Manning had more thoughts about the recent discussions in the Muse (here and here) about software being too important to be left to programmers:
Software is by far the most complicated stuff in existence. On top of that it is invisible and defies all intuition except for very few people. Complex programming needs extremely high intelligence and ability to do right.
There are degrees of complexity in any engineering field. Consider short rail bridges over a 20ft streams vs the long multi-lane suspension bridges. The same occurs in software: a simple control task (eg. 8-bit timer in a toaster) vs avionics.
When you take a bridge engineer who is only capable of designing 20ft rail bridges and ask him to design a vehicle bridge over a wide body of water you get Galloping Gerty.
When you take a toaster software engineer and ask him to design a complex system you get Apollo 11 LEM software (which crashed 3 times during the landing sequence), F35 (software still delayed...) or other nightmares.
There are always pressures to pack in more features or shorten deadlines. Since nobody can see software duct tape there's always pressure to take short cuts or gloss over problems rather than fix them immediately. While most people have sufficient understanding of mechanical systems to not use duct tape instead of bolts to hold a bridge together, very few people understand the same with software.
Very, very few people understand software well enough to design it properly. Even fewer people understand software well enough to make the trade offs and compromising needed in all engineering exercises.
It might seem witty do dump on the software engineers, but the reality is that often it would be better to inject software engineers into other areas (mechanical, electrical or O-rings) where engineers are floundering trying to make a solution. I don't suggest that because software engineers have the specific knowledge, but more because software engineers are generally far better at asking probing questions.
Donn Dobbs added:
I would alter the phrase to read: "Software [design/architecture] is too important to be left to programmers."
I think Jim Berry's comment nails it. Having been in (and out) of the software development community since the late 1950's I've watched the evolution. The juncture that disturbed me most was when (for cost cutting I presume) the position of Systems Analyst was eliminated and that task was relegated to the job title of "Programmer-Analyst." Instead of having subject-matter experts specifying/defining/architecting new software products and supplying their documentation to programmers (coders), companies instead advertise and hopefully hire coders who just happen to also be subject-matter experts in _________ (fill in the blank). Rarely will you find the perfect individual who is a guru in both skills. And, even if you do, there is a built-in conflict of interest. Human nature says that if I'm the guy who has to eventually write the code, that fact is going to greatly influence my (unbiased) ability to specify a really good product that might be much harder to code.
Finally, Larry Marks had this to say:
Paul Bennett wrote "This will raise the question why we still have software that is buggy. A lot of it is the current attitudes pervading society. The need for the quick fix, want it now mentality that has been growing more prevalent."
Also the cost to fix a bug. When I was designing logic ICs for IBM in 1975-84, code (and even character generators) were in mask ROM, soldered to the PCB. The cost and turnaround time to fix a bug were huge--more than wiping out the entire profit on a product.
Was the code simulated and thoroughly tested in the lab? You bet it was, just as thoroughly as the logic chips. Very rare for a bug to escape. Now, of course, with flash memory and USB ports, as soon as it barely works, it's shipped. The consumer is expected to visit the internet to get and install the fixed code. (Can your grandmother do that?)
(As an aside, I do remember two character generator bugs. In one case the programmer was doing a German character generator. He was told to place "Double-S" at particular address. He inserted the section symbol, §, but it was supposed to have been the German glyph "ß" that replaces two sequential "s" characters. Fortunately it was caught in test although delay getting the correct mask ROMs held up shipment. How's your Yiddish? I have a Bißel.)
Jim Berry wrote "The unique characteristic of software engineering is that we are able to build our own designs through programming without the necessity of representing the design in a human-readable fashion to be handed off to a separate person for fabrication. That is a mixed blessing."
He's describing a flawed process. It IBM we distinguished "Software Architects" from "Coders." Jim may be talking about small shops or small projects (we had those too), but if you don't have design before implementation, no one knows what he is supposed to do. Since we're doing analogies here, do you think Bush or Obama writes his own speeches? No way. He discusses or sketches an outline of points to make, and maybe a preferred order and hands off to a speech-writer. You're in Boston, right? How about this: Seven books on speechwriters - The Boston Globe
Harlan Rosenthal responded to a joke in Muse 301 about excessive use of indirection:
This example of lots of indirection is a silly one (though technically valid) for multiple reasons:
- the names are meaningless, unless this is a summary of a soap opera, in which case it's still mostly meaningless
- no apparent reason for the indirection, particularly the multiple levels.
I just put something together in which there's a linked list of Active Device Blocks (one path of indirection), each of which points to (among other things) a Device Descriptor Block for the type of device it is (could be multiple active devices of the same type) and two different pools of buffers. The Device Descriptor blocks, in turn, point to three different types of attribute-description records (all consts) that can have variable numbers per device.
One could complain about the indirection, and duplicate more RAM (instead of ROM), copy things around that should always be the same (but now you have to worry about whether they really ARE the same, and remain the same), make unique copies of things that should be abstracted instances, and generally waste resources. Or you can have a system that SOUNDS complex in the abstract but is really no more complex than the average laundromat: "OK, we have 10 washers, 5 of this type and 3 of that type and 2 extra-large, and we have a single copy of the manual for each type in the drawer, and all of the coin mechanisms are the same type and one copy of THAT manual is in the drawer too . . . "
Maybe the problem is the perennial HW/SW divide. Hardware designers need to instantiate things; software designers are taught to abstract and commoditize things. Hardware designers think that separate ports need all separate registers with all separate names; software designers think that the separate ports should all be INSTANCES of a common STRUCTURE. Of course, an older generation of hardware designers that designed and used external UART and DMA chips thought that way too, because they were instantiating instances of a common structure; but the new generation has forgotten again, as if being on-chip confuses the issue.
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. There is no charge for a job ad.
|Joke For The Week
Note: These jokes are archived at www.ganssle.com/jokes.htm.
Lionel Hummel sent this:
The other day, I had a chance encounter with some programmers who actually prefer little-endian architecture. It was too weird. When counting to hexadecimal one hundred, they insisted on starting at 1 and ending at 0001.
|Advertise With Us
Advertise in The Embedded Muse! Over 25,000 embedded developers get this twice-monthly publication. .
|About The Embedded Muse
The Embedded Muse is Jack Ganssle's newsletter. Send complaints, comments, and
contributions to me at email@example.com.
The Embedded Muse is supported by The Ganssle Group, whose mission is to help embedded folks get
better products to market faster.