You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com. To subscribe or unsubscribe go here or drop Jack an email.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• Freebies and Discounts
• On RAM Tests
• Binary Editing
• The ShortSniffer
• Failure of the Week
• Jobs!
• Joke for the Week
• About The Embedded Muse

Tip for sending me email: My email filters are super aggressive and I no longer look at the spam mailbox. If you include the phrase "embedded muse" in the subject line your email will wend its weighty way to me.

For a successful technology, reality must take precedence over public relations, for nature cannot be fooled. Richard Feynman

Please submit clever ideas or thoughts about tools, techniques and resources you love or hate. Here are the tool reviews submitted in the past.

Mark Peterson sent a link to the old GE SCR Manual, and to a zillion other old publications.

John Hartman also sent a link to many old pubs.

Tim Kreyche noted that Windows does support some audio goodies:

Tired of cookies? I happen to like them a lot, especially chocolate chip. But for keeping them off your computer, Roy Tellason wrote:

Larry Marks passed along this link to a webinar titled "Creating Bug-Free Software", which will promote Rust, Ada/SPARK, and analysis tools as a way to generate high-quality code.

A ShortSniffer! This unit will find short circuits. There's more on it later in this Muse.

Enter via this link.

Bugseng has a static analysis tool that sounds interesting. They are willing to do a free static analysis of up to five open-source projects. Read more about it here.

This email arrived in January:

Well, implementing a substandard algorithm does not make the writer a moron! I'd place not a little of the blame on his arrogant colleague who missed an opportunity to be a mentor.

It is true, though, that this test just does not work - yet this algorithm, or one like it, is still very common.

The classic test is "walking ones", which guarantees correct operation no matter how the memory may have failed. It's pretty easy to implement but is so slow it's often impractical. No one wants a multi-minute wait for a system to power on.

Alas, some developers create speedy tests that are ineffective. The most common is to write a pattern of alternating ones to all of memory, verify the writes work, and then repeat the test with the ones complement. In pseudo-code:

Loop through memory:
   write 0xaaaa to each location
Loop through memory:
   read memory and test that each location is 0xaaaa
Loop through memory:
   write 0x5555 to each location
Loop through memory:
   Read memory and test that each location is 0x5555

This test will return a "memory is OK" flag even if the address bus has a problem. Suppose all of the address wires to the RAM array are grounded; the test will write and read to a single location and will "pass."

In some cases it will pass if there's no RAM. Depending on the bus structure, the capacitance of the wires can hold the 0xaaaa/0x5555 on the data bus returning the write data back to the read cycles.

There are many alternative ways to ensure RAM is functioning properly. I've written about this extensively here. Some of those approaches are very effective and even faster than the bogus 0xaaaa/0x5555 algorithm.

But when it comes to any sort of diagnostics, it is important to clearly define your goals. Why run the test? What will the result be? Who will be the unlucky recipient of the bad news in the event an error is found, and what do you expect that person to do?

Will a RAM problem kill someone? If so, a very comprehensive test, run regularly, is mandatory.

Is such a failure merely a nuisance? For instance, if it keeps a cell phone from booting, if there's nothing the customer can do about the failure anyway, then perhaps there's no reason for doing a test. As a consumer I couldn't care less why the phone stopped working. if it's dead I'll take it in for repair or replacement.

Is production test - or even engineering test - the real motivation for writing diagnostic code? If so, then define exactly what problems you're looking for and write code that will find those sorts of troubles.

Remember that today's hardware is often very highly integrated. In the case of a microcontroller with on-board RAM the chances of a memory failure that doesn't also kill the CPU is small. Again, if the system is a critical life support application it may indeed make sense to run a test as even a minuscule probability of a fault may spell disaster. But many other systems will not benefit from this test.

Do note that C code needs RAM to run. In general the tests will produce useful results only if done in the assembly startup code, before any returns or pops execute.

Need to examine or edit your binary? Andrzej Telszewski sent this:

Need to sniff your shorts?

Perhaps I should rephrase that.

Given that you know there's a short circuit on a PCB, how do you find it? Especially if it's on wires with lots of nodes, like a bus.

Enter the ShortSniffer, a very clever, and fun, tool that injects a small audio signal into the shorted connection. You move a sensitive probe over the board and listen to an audio signal in headphones. There's a picture in the "Freebies and Discounts" section above, as the vendor sent us one to give away this month.

The cool thing is that the audio is in stereo. As the probe moves around the board the sound moves between your ears, guiding you in which direction to move the probe. The tag line is "Follow the sound to the short."

The maker claims it can locate a short, even buried in a multi-layer board, to within one mm. Drill a hole and break the connection.

Multiple probes are supported depending on the sensitivity required.

The ShortSniffer web site includes lots of examples, videos showing the device in action. Here's one. Listen to the audio with your headphones on and you'll get the full experience using an audio signal moving between the left and right channels to find the short. It's a pretty cool video.

Prices range from $290 to $380. Definitely worth checking out.

Have you submitted a Failure of the Week? I'm getting a ton of these and yours was added to the queue.

Eric Haag found this nifty regulator that might run for a microsecond from a small battery:

From a (very fit!) Ben Vespone:

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.

These jokes are archived here.

Captchas are getting harder!

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.