Tweet Follow @jack_ganssle
Go here to sign up for The Embedded Muse.

TEM Logo The Embedded Muse
Issue Number 305, May 16, 2016
Copyright 2016 The Ganssle Group

Editor: Jack Ganssle, jack@ganssle.com

   Jack Ganssle, Editor of The Embedded Muse

You may redistribute this newsletter for noncommercial purposes. For commercial use contact info@ganssle.com.

Contents
Editor's Notes

IBM data shows that as projects grow in size, individual programmer productivity goes down. By a lot. This is the worst possible outcome; big projects have more code done less efficiently. Fortunately there are ways to cheat this discouraging fact, which is part of what my one-day Better Firmware Faster seminar is all about: giving your team the tools they need to operate at a measurably world-class level, producing code with far fewer bugs in less time. It's fast-paced, fun, and uniquely covers the issues faced by embedded developers. Information here shows how your team can benefit by having this seminar presented at your facility.

I'm now on Twitter.

I have a new video out. It's a review of Rigol's new DSA 815-TG spectrum analyzer. It packs a lot of punch in a very (for an SA) inexpensive package.

Quotes and Thoughts

When someone complains about defects in software, remember this is a new profession. Civil engineers had their problems as well. According to Rising Tide by John Barry, in the 1800s one out of four new bridges collapsed and one of three tunnels flooded.

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.

Star Simpson has some really cute PCBs:

I've been working with Forrest Mims (author of Getting Started in Electronics and the Engineers’ Notebook series) on turning some of his circuit projects into real physical hardware called the Circuit Classics (circuitclassics.com). The idea is to make it possible for a new generation of people to have the experience of learning through his drawings/work — especially in a post-Radio Shack era.

Ahmed Fathy wrote:

I just wanted to add a follow-up on Time Benson's post regarding the UMLet in Issue Number 304,

I would like to mention plantUML as well. it is very similar to UMLet however it is installed as an Eclipse plugin, and the UML code is typed in your source code files as a comments (between /* ..... */)

The beauty of this plugin is that, you keep the rendering window open and jump with your cursor between your source files/ different sections and you get the UML diagram of it (if you have written than earlier for sure).

I find it very useful mainly in a state machine code where you have the big switch case on current state and incoming event and state changes based on that. having a state diagram at the top of such a function is very useful.
another scenarios are class diagrams to show inheritance and class relations. and finally an activity diagram in complicated scenarios is very useful to show blocking vs non-blocking or async calls.

You can integrate plantUML it into wikis, so you copy/paste same code to get is on your wiki page, also there is a MS word / open office templates.

Carlo Putte suggested:

Most designs start with mind-map of some sort. We have been using freeplane (follow on from freemind I think) for some while now:http://freeplane.sourceforge.net/. It is cross platform and simple to use.

Freebies and Discounts

BusBoard giveaway

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've got one more to give away. Enter via this link.

Micro Logging

Ralf Holly has a logging suggestion:

I've just finished a blog post about a very efficient logging approach for constrained systems: I call it "micro logging".
Instead of logging expensive C strings, you basically just log addresses of dummy constants, where the symbol name of the constants serves as the "log string". These addresses are then converted back to beautified symbol names at the receiving side with the help of the linker map file. Of course, these technicalities are hidden behind a set of macros:

#include "mlog.h"     

  uint32_t readInput()  { 
  MLOG_INFO(Enter_readInput); 
  uint32_t sampledValue  =  IoGetRawInput(); 
  ... 
  if  (sampledValue > MAX_SAMPLE_VALUE)  { 
    MLOG_WARN_VALUE(Sampled_value_exceeded_threshold,  sampledValue); 
    sampledValue  =  0; 
  } 
  ... 
  MLOG_INFO(Exit_readInput); 
  return  sampledValue; 
} 
      
Check it out at: https://www.approxion.com/?p=1768.
More on Apollo

I received many comments about the article in the last Muse about the Apollo Guidance Computer. Here are a few of those replies:

Jon Woellhaf:

I very much enjoyed reading your defense of the AGC. I too think it was a remarkable achievement. It would be fun to see how many of us today could reproduce it given the same hardware constraints. Few, I think.

Your "correction" of the first quote in Visseer's book reminded me of this story. I hope you enjoy it.

In mid July, 1975, I went to work for Powers Regulator, a maker of hospital-type pneumatic tube transfer systems. I had been hired as an electronic test technician. My job was to test and repair circuit boards hand assembled by the girls out back in the shop. Can you believe we actually repaired things in those days?

Over the next couple years I built many test fixtures. The most complex was controlled by a Texas Instruments 960B minicomputer -- the same computer that ran the pneumatic tube systems. I programmed it in assembly language. My test programs worked well, but were difficult to debug or modify. I'd fix one problem and later find I'd created one or two more. I was envious of the professional programmers on the other side of the building, and wanted to learn how they were able to write programs that were easy to understand, test, and modify. And I naively thought they could do that!

In September of 1978, Powers promoted me to "Scientific Programmer" and I joined the pros on the other side of the building. My job was to maintain and modify the code that controlled the pneumatic tube systems.

I spent my first month as a professional programmer trying to understand the system control code. It was immensely complex! To help me understand it, I made a call diagram that showed how all the three dozen (or so) modules interacted. It looked like a drawing of a bowl of spaghetti and meatballs. Module A would sometimes call module B, and it might or might not return to A. Module B would sometimes call module C and module C would sometimes call module A, but other times call module D, etc, etc. I learned later that "Spaghetti Code" was common.

At the end of that first month, I was ready to resign as a programmer, having convinced myself I didn't have the intellectual capacity to understand programs written by "professionals."

Right at this time, I somehow heard of the book Techniques of Program Structure and Design by Edward Yourdon (1976) and bought a copy. The book saved my career!

I still remember sitting at my desk in the computer room and reading it for the first time. I don't know what triggered it, but I soon had an epiphany. I closed the book and said out loud, "There's nothing wrong with me, this code is just crap!"

I followed Yourdon's advice and was soon able to write well structured programs that were easy to correct and modify -- even those written in assembly language.

Interestingly enough, Edsger Dijkstra thought the book was pretty much nothing more than "junk and trash" in his scathing published review. Well, at the time it was my GO TO (pun intended) book, and it now has a place of honor on my wall behind the glass in its own frame. And I still use GOTOs judiciously where appropriate. So there, Edsger.

A few years ago I wrote Yourdon and thanked him for saving my programming career. I couldn't resist teasing him about a statement he made in the book: "Unless you are very rich and eccentric, you will not enjoy the luxury of having a computer in your own home ..."

He graciously wrote back and acknowledged he'd been teased many times about that comment.

Thanks for the Muse, Jack. I always enjoy reading it.

Rob Aberg wrote:

The links to Apollo technical details in Embedded Muse #304 turned out to be very interesting - Amazon will be happy with me. Readers who want a quick technical intro to the the Lunar Module Digital Autopilot and don't have access to Eldon Hall's book might enjoy Dick Gran's article on the topic, which includes a download link for a 3 degree of freedom (3-DoF) Simulink model of the control system feeding a model of the LEM's inertial behavior:

  http://www.mathworks.com/company/newsletters/articles/fly-me-to-the-moon-then-and-now.html 

Dick was in the Grumman Guidance and Control group on a field assignment to the MIT Instrumentation Laboratory from 1963 to 1966.  

Nick P wrote:

You had a nice write-up on Apollo Guidance Computer and mission. Yet, it was alarming you didn't once mention the woman behind its success: Margaret Hamilton. She and her team practically invented software engineering in a vacuum with many lasting techniques of high-reliability design. Then, seeing where the problems showed up, she invented the first, correct-by-construction tool to go from formalized requirements to semi-automatic design to automatic generation of code, tests, and traces. A NASA review, plus reading papers, showed it had serious usability issues due to constraints needed to pull that off plus performance problems.

Yet, here's a woman and team starting out in 1960 that invents the core of software engineering then implements high-assurance, systems engineering right after. She totally succeeded on former, saving Apollo mission during failure, with mixed results on latter. That's very remarkable and we probably owe Apollo success partly to her team and their methods. Wired points out she snuck the stuff in there because NASA mocked her belief that astronauts could make mistakes. (Lol.) Next time some fool mocks Apollo software tell them to look at the stack of source code Hamilton is holding up in Wikipedia picture. Then, ask if they've ever wrote that much code in constrained, unreliable environment in assembler without *a single failure* in production. I'm betting not. :)

Wired - Her Code Got Humans to the Moon
http://www.wired.com/2015/10/margaret-hamilton-nasa-apollo/

Margaret Hamilton, achievements, and picture of source
https://en.wikipedia.org/wiki/Margaret_Hamilton_%28scientist%29

Articles on her website (htius.com) about her methods
http://htius.com/Articles/articles.htm

Regarding her website, just ignore USL stuff to jump straight to "Universal Systems Language: Lessons from Apollo" focusing on "Apollo Beginnings" section and subsections on p2. It shows how they determined most root problems in systems and code then kept devising clever methods to prevent or catch them. Most stuff I read about in 2016 from CompSci is dealing with the same problems but with more usable specification languages. Dijkstra et al's published work of solved a *subset* of these *years later*. Talk about being ahead of the curve on software/system design and reliability.

Finally, several readers recommended Chariots for Apollo: The NASA History of Manned Lunar Spacecraft to 1969 which is NASA's official account of the systems. I really enjoyed it - but most readers will find it tedious. The book is packed with names of individuals and committees. And more names, and even more committees. Nothing that happened wasn't mediated by a slew of them. The book is short on technical details and long on management issues. I'm reluctant to recommend it as only a die-hard Apollo fan won't give up 50 pages in. But the few of us that find Apollo endlessly fascinating will get a different perspective on the program.

On Maintainable Software

Alan Ott responded to my review of Building Maintainable Software. He makes a point I've been stressing for years - that programming is just a subset of software engineering:

The question of "is this maintainable" is one that should be on the mind of every developer every time they have their editor open. The hard part about doing as the title suggests is not the desire, will, or ability from those in technical leadership; it's often the ability to communicate the methods and goals of maintainability to the other members of the team in ways they don't just understand, but internalize.

I'm always surprised at the number of software developers who think the C or whatever they learned in college is all they really need to know, and the number people who fall into software development from other disciplines who think it's "easy" because they made it through an intro programming book and can hack together something that "works." Professional software developers, of course, understand that "working" code is just the tip of the iceberg, and things like code quality (and standards), exception management, proper source code management (SCM)[1][2], build systems, testing, documentation, and repeatability are the things which make software development into a discipline[3]. Getting stuff to "work" and then leaving it there is the equivalent of nailing 2x4's together in your garage with no plan. Sometimes it gets you to the goal, but it can hardly be called "engineering."

Alan.

[1] To anyone who has recently made a commit message reading "changes," "bug fixes," "integrated dev branch," or otherwise used non-descriptive, improper language to describe their changes, this doesn't count as engineering. Work doesn't get to stop when it's no longer fun.

[2] As a user of the distributed SCM, I've become increasingly convinced this is the right way to do software development. There are so many dimensions of distributed SCM that provide a positive impact, but the largest of which is the idea of sending a pull request to your team leader, rather than every junior engineer pushing directly into the master repository. We wouldn't accept changes without review in other engineering disciplines, why should it be done in software?

[3] There is no shortage of debate around whether software engineering is really an engineering discipline. Flame wars aside, Software development can certainly be done with discipline, but often is not.

Jobs!

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.

From Charlie Moher:

I saw this online at electro-tech-online.com, posted user moniker tcmtech. It's his summary of the essentials of the most common forum questions asked. Funny enough perhaps to pass along.

1: How can I tell if my lights are out without getting out and looking.
2: How can I use way too many components to charge a simple battery.
3: How can I use a microprocessor to blink a LED.
4: How can I get the last nanowatt of energy out of a AA battery for under a $50 investment.
5: How can I build a common device without actually using common parts.
6: How can I build a store bought device using salvaged parts from several of the same store bought devices I already have that still do work.
7: How do I run some device off a power source not designed to run it.
8: I am cheap and have no common sense can some one help me out.
9: Do you have my home work done yet.
10: How do I make something work when I don't even know how to describe what it is.
11: How do I solve an unlikely problem that is realistically never going to happen.
12: How do I convince others that what I think is right without evidence or proof to support my opinions.
13: If I took my OCD meds would this scenario I am so worried about still seem important to me.

Advertise With Us

Advertise in The Embedded Muse! Over 25,000 embedded developers get this twice-monthly publication. For more information email us at info@ganssle.com.

About The Embedded Muse

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. We offer seminars at your site offering hard-hitting ideas - and action - you can take now to improve firmware quality and decrease development time. Contact us at info@ganssle.com for more information.

Click here to unsubscribe from the Embedded Muse, or drop Jack an email.