Go here to sign up for The Embedded Muse.
TEM Logo The Embedded Muse
 Issue Number 311, August 15, 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 jack@ganssle.com.

Contents
Editor's Notes

Better Firmware Faster classes in Denmark and Minneapolis

I'm holding public versions of this seminar in two cities in Denmark - Roskilde (near Copenhagen) and Aarhus October 24 and 26. More details here. The last time I did public versions of this class in Denmark (in 2008) the rooms were full, so sign up early! (There's a discount for early registrants).

I'm also holding a public version of the class in partnership with Microchip Technology in Minneapolis October 17. More info is here. (There's a discount for early registrants).

Or, I can present the seminar to your team at your facility.
Quotes and Thoughts

Harold Kraus sent in this quote from Jessica Keyes: "Automating a money-losing process allows you to lose more money faster and with greater accuracy."
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.

Gary Kildall of Digital Research and CP/M fame wrote a manuscript about his life that has long been available only to his immediate family. His children have recently made portions of it available to the public. You can get it from here.

I'm a fan of the Ada language, and AdaCore is sponsoring a Make With Ada contest. There's more info here. The top prize is 5000 Euros. Full disclosure - I'm one of the judges. It could be a lot of fun to build something with a Cortex-M MCU.

As noted later in this Muse, I had to replace my desktop computer recently and am now running Windows 10. So far, no real complaints. As part of setting up this machine I loaded one of my favorite free mini-applications, 8GadgetPack, which, it turns out, is new and improved from the last time I loaded it. This is a free collection of dozens of little bitty apps. You select the ones you want and then they live on the right-hand side of your screen. Here are the ones I use:

s

The function of each of these is mostly obvious. The second one down is a clipboard expander. Every time you copy something (including pictures, movies, etc.) to the clipboard it also goes to this app. Then use the mouse's scroll bar to select a particular clip, click once on it, and now that clip is the active one that will get pasted when you select "paste" or hit control-V. Very handy.

Carl Peterson wrote:

When I first became a technician back in the 70's our engineering department (Beckman Instruments) gave us a Huntron Tracker to help troubleshoot our circuit board issues. I liked the probes on the device so much I bought some for myself. The tips are very pointed and sharp allowing you to pierce wire insulation without any damage other than a tiny pin hole. You can loosen the collar and push the tip out about four inches without worry as the side of the probe you've pushed out is non-conductive.

This was great when we were probing inside large (this was the 1970's) multi-volt 30+ amp power supplies as well as crowded multiple transistor logic circuits (we had RTL & DTL chip boards in addition to these discrete logic boards).
Freebies and Discounts

This month's giveaway is a 200 KHz oscilloscope in kit form, without the 9 V power supply. Again - you have to solder this together. This is a real entry-level unit but looks like fun.

Enter via this link.
A Backup Strategy

If my computers were stolen or lost in a fire the insurance company would make me whole. But if my data disappeared I'm out of business. Or out of memories if those thousands of pictures and other digital memorabilia disappeared.

Yet hard drives fail. Ransomware can encrypt your files; a new, nastier version pretends to encrypt but actually deletes everything. Fires happen as does theft. Accidental deletions are common. How do you back up your files?

We have a small network here with new content being generated on only a few computers. But we have a fortress-like approach to backups which has been very effective. Here's our approach.

One computer is the designated "master." It controls all of the backups. It's a Windows machine running the $30 utility SecondCopy, which automatically starts every morning at 3.

One of the program's advanced options is to start external programs before and/or after SecondCopy does its work. In our case it starts a batch file that XCOPYs changed/new files from the other computers on the network to the master machine. XCOPY's /y, /d and /s options are used. The results are appended to a log file for troubleshooting.

All of that data, the original and backups, is on the master computer which could be lost via fire or other calamity. So there are two USB external drives. One lives in a secure offisite location. Every Friday Outlook's task manager tells me to swap the two drives. If we had a fire we could lose a week's data, which for us isn't that much. We are building a new barn, and when that's done I plan to investigate using a disk antenna (the barn is 200 feet away) to wi-fi a backup computer there every night. Or I may lay some Cat 5 cable in the electric trench we will be digging.

Every Friday, prior to swapping disks, I check the log file on the backup disks to ensure everything worked as intended.

Autorecovery files in applications like Word are set to go to the second internal hard drive, so if the c: drive fails while editing a document changes to that document won't be lost.

But what about ransomware? I don't know if it typically attacks all at once or can lie dormant before doing its dastardly deed. So when SecondCopy finishes it starts another batch file that changes the attributes of the backup directories on the USB drive to hidden and system. Those directories essentially disappear. Sure, attacking code could undo the attribute changes, but since the names of those backup directories are known only to us, this affords at least some level of protection. The batch file that runs before the backup changes the attributes back just for the duration of the SecondCopy's work.

Many tout the cloud as a backup solution, and it can be effective. But there are perils. At least one provider lost most of their customers' data due to an attack. I don't want my personal info, even though the important stuff is encrypted, out in some mysterious cloud where you don't know where it is. Do deletions actually delete all copies? Who knows what agency might be sifting through it? Some of the privacy statements are horrifying - they're little more than notices that the providers will vacuum up everything. There was a good article in EETimes about cloud-based storage.

We need a healthy digital paranoia to preserve the bits.
The Internet of Evil Things

Teakettles, cameras, door locks, road signs, nuclear power plants - these and many more have been hacked and are listed in the Internet of Evil Things Hall of Shame here. Thanks to PhaedruS SystemS's newsletter for pointing this out.
Monitoring Code

In response to Andrew Kollosche's idea for an activity meter in the last issue, Keith Lockstone wrote:

When I started work in 1965 at Elliott Automation (UK), I worked on their 4100 series mainframes.  Their scheme for CPU/program monitoring was audio - the control desk had a speaker built in. Every conditional branch instruction caused a pulse and the pulse stream was effectively divided down to produce an audio note.  The sounds easily showed when the software was in an infinite loop and also the progress of fixed tasks such as sorts etc could be heard.  It's a pity this technique is not better known as you can monitor your software from another room.

One day I programmed a test machine to output its memory in Morse and left it running - it was about 5 minutes before I had to close it down due to complaints from nearby engineers!

Along those lines, back in the dark ages we embedded Data General Nova minicomputers into systems. Debugging tools were primitive so we'd tune a shortwave radio to pick up the computer's EMI. The tones told us a lot about what the programs was doing.

Mark Moulding sent in this:

The use of a VOM is a clever idea - with a (very) little tweaking, it could easily be used as a general "system load" meter. I think most designers (of our generation, anyway) tend to hang an LED on a spare port pin for debugging purposes - it costs nothing in production, since the component can just be left out.

Often, especially on very small systems, I find that some sort of input device is handy, too. I usually implement this by providing a pushbutton between the LED's port pin and ground (assuming that the LED anode is at Vcc, and pulled down by the port). This way I can implement a whole diagnostic dialog using just one pin.

The idea is certainly not original - I actually got it from the Engine Control Unit of my 1991 Mercedes, which had a pin that could be grounded to flash out diagnostic codes on a single LED. An available shop tool was an instrument that plugged into the same jack, counted the pulses, and printed out the results on a small integral printer, but you could achieve the same results with nothing more than a clip lead and a reference list. (Back when it was still practical to work on one's own vehicle...)

Vic Plichota had a fun idea:

I kid you not, I once used an MCU's on-chip DAC to output a voltage representing the stack depth to an analog voltmeter. Very silly indeed, but it did provide an in-situ probe (i.e. without an external debug host), that showed how and where -- and under exactly what circumstances -- our GUI ran into a problem. Good for grins and giggles all around, too!

A perusal of the source code showed that sure enough, there was a loophole in the state-tables that preserved the previous context instead of flushing it; all very reasonable-looking at design time (I mean, why would the user ever want to do THAT?), but of course no battle plan ever survives actual contact with "the enemy"...

This is Paul Carpenter's approach:

I find the tunable way [to monitor code] is software to drive the port pin but use a software counter.

When your system is idle some functions are checked some are quickly bypassed, even with some functions (pseudo 'tasks') being time delayed operation, there is a range of idle times that is narrow. When system gets busier this time changes.

So don't count the idle time, count how many times functions are called and either at specific time or when reaches a count value toggle the LED.
Choosing how you decode this or amount of time off to on (different count
thresholds) you change it to be slow flash or fast flash for idle or busy and stuck on or off something has run away or taking way too long.

This way you can tune your thresholds so the human eye can see the different rates easily. So EVERY time you call a function either in superloop or even a simple time time delayed co-operative scheduler increment the counter.

At top of superloop compare count with current threshold desired to determine action, usually start LED on, then either a time delay or smaller count to determine when to turn LED off.

Debugging aids become possible as if you have a list of functions and something strange is happening, after specific functions you could always add LARGER numbers to see the effect so instead of 1 add 10 or 100 or 1000 depending on what your count thresholds are.

Alternatively add different values for processed this pass or quickly skipped, e.g. processed a command or no commands from serial port.

The extra software load is negligible, and I do hope you keep some form of stats table even in a superloop for which task have done anything this pass and if possible longest time for each function.

I regularly use time delayed co-operative scheduling down at 2 ms or smaller outer loop granularity, but save arrays which can be output copied etc, with micro-seconds for last execution time, longest task ID with its time for execution and flags on if executed this pass. This is very small on data storage required as well.

Having some hardware timer even if not at micro second accuracy running and reading that around task execution times makes life so much easier, as the handling and working out idle times, execution times, and scheduling overhead becomes easier.

I have even done this method for stats on Arduino Uno and Mega, remember the Uno has only 1kB of RAM and the overhead was something like 40 bytes for 8 tasks. Whilst using a 'task' status to determine whether to start, stop, state of execution, or error status (stopped) for each task. This was extra requirement beyond the scheduling minimum.

The important point is you can easily get at a lot of simple data from your software at a fairly high level to actually help you and your debugging, whilst also adding another marketing LED.

There are a lot of commercial tools available for monitoring the code. I've used Micrium's uC/Probe and like it a lot. Percepio's TraceAlyzer is getting a lot of buzz lately, and Express Logic's TraceX looks great, too.
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.

Two strings walk into a bar and sit down. The bartender says, "So what'll it be?"

The first string says, "I think I'll have a beer quag fulk boorg jdk^CjfdLk jk3s d#f67howe%^U r89nvy owmc63^Dz x.xvcu"

"Please excuse my friend," the second string says, "He isn't null-terminated."
Advertise With Us

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