Tweet Follow @jack_ganssle
Go here to sign up for The Embedded Muse.
TEM Logo The Embedded Muse
Issue Number 315, October 17, 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 non-commercial purposes. For commercial use contact info@ganssle.com.

Contents
Editor's Notes

 

I'm now on Twitter.

Quotes and Thoughts

"This attitude has even affected the way we speak about software through the use of the term 'legacy applications'. Legacy applications are the core applications that enable a business to operate, but due to neglect are practically impossible to maintain and enhance. I cannot think of any other fields in which we are stupid enough to entrust the care and maintenance of essential, expensive assets to the people least qualified to look after them." - Pete McBreen in Software Craftmanship

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.

Jon Titus found a nice Android app:

High-school math has changed greatly over the last 50+ years, so I decided to find out what's new in form and teaching techniques. Many of the books I saw use calculators to plot and compare functions.  (Plots would have helped me get through college calculus with less pain.)

During the last few weeks I looked at several high-end graphing calculators from TI, HP, and Casio but decided against buying a device I'd use for a while and then forget how to use. While looking around I discovered a science/engineering graphing calculator app for $5 that runs on Android devices. I put it on my Kindle Fire and have started to learn how to use it.  No calculator could beat the price, so I thought you and your readers might like to know about it.  Here's the link: http://www.mathlab.us/calc/index.html.

Freebies and Discounts

I've had one of Digilent's Analog Discovery USB oscilloscopes around here for some time and will be giving it to a lucky winner at the end of October. It's a nice unit - 5 MHz, two analog channels, 16 digital, and a pair of waveform generators. Note: The little black Analog Discovery is this month's giveaway, not the Agilent scope in the background! (I reviewed the Analog Discovery here).

Enter via this link.

Segmented Memory Feature in a Scope

Modern digital oscilloscopes are marvelous devices that offer so many features that their user manuals have page counts that rival War and Peace's. Some of those features are really useful, but are sometimes so buried in the documentation that users don't know about them. One of these is segmented memory, which is available on some scopes and optional on others. I find it incredibly useful on occasion, though something I don't need to use often.

Suppose you want to look at multiple events with deep horizontal resolution, but those events come infrequently. Crank up the time base and the memory will fill quickly; the second, third and Nth iteration of that event might not get captured.

With segmented memory the scope divides the acquistion buffer into a number of sub-buffers. A trigger fills sub-buffer number 1. The next trigger fills number 2, etc. Even if the triggering events are separated by long stretches of time you can still capture very high resolution profiles around multiple triggering events.

A mixed-signal scope captures both analog and digital signals; generally two to four analog and 16 digital channels. If it has segmented memory it will (at least, for the models I'm familiar with) store all of these channels in the segments. That can be really handy if, for example, you're troubleshooting a state machine. A particular digital state can trigger the scope so you can see what happens every time that event occurs.

This is an animated .GIF showing the use of segmented memory. In this case I'm watching the dither between two signals that come every 100 ms. The scope is triggered on the yellow pulse (not visible) and the scope is sweeping at 10 ns/div. That would swamp the scope's buffer, but here it is divided into 35 segments. The animation is from me selecting which memory segment to display; I captured the screen each time I selected a different segment. If your email client can't show animated .GIFs you can see this here.

Two of my scopes have this feature. The Keysight MSO-X-3054A lets you select the number of segments to use, ranging from 2 to 1000. The image above is from that instrument. Siglent's fairly new SDS2304X supports up to 80,000 segments.

I don't often use the segmented memory feature, but occasionally it is a real godsend.

Tips For Aspiring Developers

In the previous issue Michael James asked what tips would you give a newly-minted firmware developer. Scott Romanowski suggested:

Think about the system changing as it runs. Sequence matters. You're probably maintaining some code that uses global variables and interrupts. Think of what could happen if your code gets interrupted, could a global you're using be changed? If you're writing a routine that implements a state machine, think of what might happen between calls. Can something else change your state, maybe for you to a reset state? Is it safe to do that from any state?

Think about error conditions and recovery paths.

Jason Long contributed:

I've mentored university engineering students in embedded systems for 16 years. The observation that I share with them is that as students, you write a lot of code and are surprised when it works. As engineers, we write a lot of code and are surprised if it doesn't work. This is just another way of saying what is at the root of Michael's thoughts: we need to spend time designing, learning, and understanding every aspect of our hardware and firmware. Doing this work up front and incorporating it into the design is the essence of "a little effort at the start saves a lot of effort at the end."

Paul Carpenter had a detailed list:

1/ Start with knowing and WRITING DOWN
a) What overall the complete system has to do
b) Write down the facts you DO know including system and part response times
c) Write down the things you DON'T know
d) Write down the LIMITS (real world, system, software) you know

2/ Understand each part of the system and follow the RAR principles: Resolution, Accuracy, Response Time (of parts and system)

3/ Think hard on what relates to what and find out what is easy and what is hard
a) To appease managers, get some of the easy stuff going quickly to show some results that may change later.
b) Get to understand and TEST and DOCUMENT parts of the HARD stuff until you can combine it.
c) Measure and Document RESPONSE TIMES of EVERY PART

4/ THINK and WRITE down results. Review what you have. See what can and cannot be done

5/ NOW consider thinking about your solution(s) and how to implement them. Working downwards and WRITE down the details of each section from the BOTTOM UP.

Daniel Wisehart stresses iteration:

On tips for aspiring developers, I have a bit of a different view on it now, than I did years ago, when I would have said something similar to what Michael James wrote.  I now think that it is important to stress the iterative nature of the development process.  Otherwise, aspirants think of "writing the code" as a step, that once completed, is not returned to again, or at least not very much.  By planning for iteration from the beginning they learn to attack a problem in bite-sized pieces.  It can help keep them from going days and days down the wrong path, only to find late that an early assumption is wrong.

In the style James used:

  • Think hard about how to divide up the project into small sections and layers on top of completed sections: your development plan.
  • For each small section or layer--which should take a week or less to complete--think hard about how you are going to test the latest piece: your test plan for this section or layer.
  • Given your test plan, think hard about how you are going to code this small section.
  • Write your system code and your test code.  Come up with test cases that will be important during integration testing of the completed project.
  • Test your latest small section or layer with the other small sections you have already completed.
  • Show what you have to others and invite comments.
  • Got back to your development plan and work on the next piece.

Charles Manning had advice for parents:

We homeschooled our kids. As an embedded developer with two sons (now in their 20s) with an interest in engineering, programming etc, I was often asked by other homeschooling parents about things they could do with their children who had an interest in programming/embedded.

The first point I always made to them is that embedded development is primarily about breaking design down, understanding design and problem solving. These are transferable skills. Younger kids can learn that playing with Lego, especially if they do problem solving in a reasonably structured way: How can you make that lighter? stronger? Why did that wall break? Why did it break here and not there?

The other critical skill is the ability to view software as a physical entity (a huge Rube Goldberg machine) rather than code on a bit of paper. If kids are working with robots then get them to actually physically do the actions the robot has to perform (eg. actually walk along, bump into something, then back up and turn around). This helps them be able to experience algorithms much deeper than just looking at it on paper or a screen.

Once a child gets to, say, mid teens and can really do some programming the first thing to do, IMHO, is to set up a github account. Apart from getting the source management skill going early, this also gives them a way to share code or discuss code (eg. with a mentor).

There are excellent courses on the www for teaching simple Python etc.

Something simple like an Arduino is a good way to cut embedded teeth, but an Arduino doesn't have long legs and might need to be replaced by something more capable.

Vic Plichota's advises people to learn their CPU:

I'd say:  Assiduously learn your target machine's architecture!  Sooner or later, high-level debugging will be inadequate and you need to single-step through machine code.  If you don't understand the disassembly, then you are well and truly up the creek without a paddle.

Dave Telling's advice comes from long experience:

1. Find a company/position where there are already experienced programmers/engineers, so that you have "real-time" access to people who can help you.

2. This is controversial, but it might be beneficial for others like me: spend perhaps less time reading/studying, and more time actually writing code for a real project. Find some application and figure out to implement the code. Most can only retain so much without the added impression derived from using something. It is kind of like riding a bicycle - you can read about how to do it, the physics involved, etc., but at some point you have to get on the bike and actually ride!

3. Learn about the varieties of hardware interfaces - serial, I2C, SPI, and others, and do small projects that allow you to experiment with, and become comfortable with, them.

4. Work on deliberately adding to your capabilities. For example, I am not a fan of pointers, but I pushed myself to learn to use them as necessary for my projects.

5. Remember that online search is your friend! Don't be afraid to ask questions about things that don't seem to make sense, but make the effort to find the answer yourself before posting in a forum or user group.

Ashleigh Quick suggested:

  • Have a wide ranging curiosity outside engineering and software: architecture, history and "why is that like it is" lead you all kinds of directions, make you more rounded, and lead to inspiration in the least expected places.
  • Study more than just software, or engineering. If still in a university, try and pick wide ranging subjects including some that challenge your abilities. In a long lifetime you never know where those things will take you, but having some knowledge that's outside the norm is likely to make you more employable.
  • Read widely, keep abreast of technology, techniques, systems, security and processes. (Don't ever stop trying to learn).
  • Develop a good BS detector – especially for methodologies, experts (!), trends, and predictions of the future.
  • Write a lot of code, outside your comfort zone.
  • Ask "what if" and "why". Dig into the output of compilers to look at the generated code, and see what happens if you change the source.
  • Always write code assuming that the next person to maintain it is a homicidal maniac who will come looking for  you if it is unintelligible, poorly commented, uses variables like "i" and "frob", has lousy layout, or does not use whitespace.

James Owen wrote:

Think *far* more about testing than you're doing. If you cannot figure out how to test the program/system, then it's broken (Owen's second law). Since it is *acknowledged* that software development is at least 50% debugging -- more like 95% in my experience -- testing is of supreme importance.

Luca Matteini thinks about robustness:

Imagine that your hardware and firmware is driving you and your car on a highway, and gets struck by lightning or your wheels pass over a hole. Robustness is the ability to take some reasonable countermeasure and correction, and a good design should always try to foresee troubles.

I have a colleague that recalls to others how he's good at testing user interfaces, cause when he tries something new he always finds some click/push/move action that triggers an unexpected behavior. Leave your product in some unexperienced hands and begin testing real robustness -- sometimes even mechanical: had some customers who managed real world examples where supposedly "touch" controls where daily hammered with a screwdriver, as an "ordinary" way to push it.

Serious About Security?

I wrote in the last Muse that people really don't care about secure firmware. If they were they'd be willing to pay for it, in dollars and in longer development schedules.

Eric Krieg replied:

I lost a job where I made their product get on the internet-ethernet - I was thought to have taken too much time to get it working. But part of what I did was make it automatically not crash when "script kiddies" and other general internet worms would hit some of the units that were not behind a firewall - I had also built in a lot of flexibility to handle being behind different kinds of routers, hitting different time servers, making up for crystals that aren't accurate, supporting different versions of web browsers. They not only weren't willing to pay for security - they kicked my ass out for putting it in and don't even realize now they have less remote headaches because of what they canned me for doing. For another company, I offered to put in protection against Chinese manufacturers surreptitiously running off extra product that they sell gray market against your own (another worthy column topic) - again, I got "let's not worry about that now". Your point about customers willing to put in 0 months for security is well taken. I think part of it is related to my quote "many customers don't understand the full journey from "demonstration grade" to "shipping high volume with out being swamped with embarrassing service calls". - I see a huge distance from "proof of concept" to ready for prime time.

Olaf Pfeiffer wrote:

I can confirm that among our customers (mainly deeply embedded devices) at first there is no budget for security. However, in combination with bootloaders and updates security suddenly gets more attention. Majority of our customers want to be able to update the firmware in their deeply embedded products, just in case something goes really wrong with their firmware. And now, security becomes an issue - as the FW contains IP, it needs to be secured. And once a mechanism is in place for security, the additional effort to have the application use security features is less, at it already is part of the system. But this is a very slow process...

I really like Tom Archer's thoughtful reply:

What you have described is ubiquitous where costs are hidden, deferred or un-accountable.  In this there is no difference between security, underfunded pension costs, productivity in "open" offices, deferred maintenance, unethical behavior…it doesn't matter.

In his recently published book about decision making, "Pre-Suasion," Robert Cialdini is perplexed by unethical executive behavior of the kind recently exposed at Wells Fargo and Volkswagen.  Cialdini's only explanation, speculative and at least partially supported by research, is that executives can't conceive of getting caught.

My 2 cents, that's true but it is slightly more accurate to think of it in terms of never being held accountable.  "Getting caught" implies a moral issue, but "not being held accountable" covers both moral failures and incompetence.

As much as cynicism is justified, it's also my experience that a huge number of people make the right decisions day in and day out, sometimes in secret.  As a consultant, I've worked in over 300 industrial plants on 4 continents and have perhaps thousands of war stories.  Sometimes it's a battle, but engineers, plant managers, floor supervisors, hourly people, even executives regularly do the right thing but it is simply unheralded and you'll never read about it because the consequences of doing the right thing are only apparent in contrast.  The headline is "Engineers fired at Volkswagen" not "Engineers at Mercedes Benz, Honda, Ford and Hyundai didn't cheat."  It is also true that I've seen people fired, or who have resigned, because they insisted on doing the right thing or refused to do the wrong. 

Noble prize winner Daniel Kahneman, in his book "Thinking Fast and Slow" describes a perception phenomenon, "what you see is all there is." If you haven't experienced a security breach, there is a high probability you may not be able to cognitively comprehend that, nor the scope of its consequences. As security and its consequences, are better understood by a broader range of executives, perhaps you will see a greater commitment.  However, it is also fair to recognize that "what you see is all there is" is an act of willful incompetence, of intellectual lethargy.  Kahneman also argues that too is pervasive. 
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 intent 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.

A guy is standing on the corner of the street smoking one cigarette after another. A lady walking by notices him and says "Hey, don't you know that those things can kill you? I mean, didn't you see the giant warning on the box?!"

"That's OK" says the guy, puffing casually "I'm a computer programmer"

"So? What's that got to do with anything?"

"We don't care about warnings. We only care about errors."

Advertise With Us

Advertise in The Embedded Muse! Over 27,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.