Follow @jack_ganssle
Go here to sign up for The Embedded Muse.
TEM Logo The Embedded Muse
Issue Number 335, September 18, 2017
Copyright 2017 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

Did you know it IS possible to create accurate schedules? Or that most projects consume 50% of the development time in debug and test, and that it's not hard to slash that number drastically? Or that we know how to manage the quantitative relationship between complexity and bugs? Learn this and far more at my Better Firmware Faster class, presented at your facility. See http://www.ganssle.com/onsite.htm for more details.

I'm now on Twitter.

Quotes and Thoughts

"I have a foreboding of an America in my children's or grandchildren's time -- when the United States is a service and information economy; when nearly all the key manufacturing industries have slipped away to other countries; when awesome technological powers are in the hands of a very few, and no one representing the public interest can even grasp the issues; when the people have lost the ability to set their own agendas or knowledgeably question those in authority; when, clutching our crystals and nervously consulting our horoscopes, our critical faculties decline, unable to distinguish between what feels good and what's true, we slide, almost without noticing, back into superstition and darkness. The dumb down of America is most evident in the slow decay of substantive content in the enormously influential media, the 30-second sound bites (now down to 10 seconds or less), lowest common denominator programming, credulous presentations on pseudoscience and superstition, but especially a kind of celebration of ignorance.'' Carl Sagan, "The Demon-Haunted World: Science as a Candle in the Dark", 1995

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.

Micheal Salem and others report that the DMMCheck (a calibration standard for DMMs), which I mentioned in the last issue, is no longer available. VoltageStandard has other offerings, though it appears none so versatile as the DMMCheck.

In the I Should Have Anticipated This department, Amazon now offers FPGA servers on their AWS offerings. That is pretty cool. Thanks to Steve Leibson's blog for pointing this out.

Are you a Mac user? I use a Mac laptop while traveling, and a Windows machine in the office. In my opinion, the Mac's Finder program (file manager) is lousy. Some years ago I started using Pathfinder instead. This decent utility costs $40. Lately I've tried Commander One. The free version is a dual-pane file manager, which is quite handy. It includes .zip compression/extraction, regex searches, and a host of other features. The Pro version ($30) adds an FTP client, access to cloud services like Amazon S3 and Dropbox, the ability to mount iOS devices, and more.

Last issue's comment on tube testers brought several responses. Remington Furman sent a link to a new, high tech, microprocessor-driven version. Way cool!

Considering the recent Equifax debacle, Paul Carpenter's timely notes about the new EU General Data Protection Regulations which come into effect in May, 2018 are a worthwhile read. It's unclear to me if non-EU companies selling into that market will be liable under the new law.

But security will be hopeless until executives are held accountable. There simply isn't incentive for them today to take the difficult and expensive actions needed to lock down our data. But in the USA it's hard to penetrate the corporate shield, so don't hold your breath. Bruce Schneier has a good take on Equifax's appalling inattention to securing our data.

Freebies and Discounts

Cmicrotek is again offering a free uCP20 current monitor to a lucky Muse reader. This device is used to monitor current consumption of very low-powered microprocessor-based devices.

Enter via this link.

Book Review - Embedded Systems Fundamentals

In June I had business in Rayleigh, NC. Having just received a copy of Embedded Systems Fundamentals with ARM Cortex-M based Microcontrollers, and noting that the author teaches at NCSU, I decided to drop in and say hello. Alex Dean is a cool guy doing some fun things with his students. Back in the Paleozoic Era, when I was an EE student, we weren't even allowed to solder for fear someone might burn themselves (how else does one learn which end of a soldering iron to pick up?). Alex's students do a lot of hands-on embedded work.

Alex's book is a gem. It's in full color; nearly every page has color, including colored code as you'd see in an IDE. It advertises itself as a textbook, but this is not like any dreary old equation-laden textbook I know. It's an intro to the world of embedded systems, both hardware and software. Based around NXP's (née Freescale) FRDM-KL25Z development board ($15 from Digi-Key), this Cortex-M0+ board is a great starter kit. He uses the Keil uVision toolchain, which is free for programs that don't exceed 32 KB. One of the reasons I like this board is that the mbed group supports it, which means one can skip the whole IDE thing. But in the real world we use IDEs, so Alex made the right choice in using uVision.

The book starts with using switches to control LEDs, an old topic. But it shows how one calculates the LED resistor, explains what legal logic levels are and what they mean (including staying away from the no-man's land in between a one and a zero), and then covers the hassle of setting up the M0+'s GPIO registers.

I'm not too keen on his use of the word "task" in Chapter 3, as he defines that to be "a subroutine that performs a specific activity". To me, "task" has a very specific meaning in terms of multitasking, but this is a minor nit. He does refine tasking by taking these subroutines and then tying them together, first by a simple polling loop, then cooperative multitasking, and then using interrupts to invoke them. Finite state machines are well-covered; a nod to RTOSes completes this chapter.

The M0+'s architecture is well-described, with special emphasis on the interrupt system. Assembly language gets its due, and the book shows the sort of assembly generated by typical C statements. Some argue that assembly is so-five-minutes-ago. I disagree, and think that an understanding of what is going on at the low level is important in much embedded work.

Analog interfacing (including hardware details), PWM, WDTs and even DMA are covered. Several types of serial comm get detailed treatment.

One thing that makes this a strong work is that the practical details are treated in a way that is analogous to how we work. For instance, the I2C section shows packet formats and the open drain configuration used. The code is given and is well described. There are no proofs left to the student.

Seasoned developers know all this stuff, as the book is targeted to engineering students. However, if you're not familiar with the Cortex-M architecture, this is a good intro.

Anyone wanting to learn about embedded development will be well-served by the book.

More on Filesystems

Responding to last issues discussion about a poor filesystem on a camera's SD card, Charles Manning wrote:

Your piece on file systems was well written for someone who, presumably, has not had to dig too deeply into this subject. I wrote, and continue to support and develop, the Yaffs file system (www.yaffs.net).

You are correct to point out that journalling is often a good way to go. Yaffs is a log structured file system which is basically a journal file system taken to the extreme - there is only the journal.

Log structured file systems are particularly well suited to flash because they only require serial writing. There is no need to modify existing blocks of data like there is for, say, FAT. That gives a performance advantage as well as reducing wear etc.

It is very important to fit the file system to the task at hand. If you are developing a Linux-based system (where there are literally dozens of file system options) it is often a good idea to split up the storage into separate partitions. eg. read-only for code and all the data needed to boot a system, log structured or journalled for critical data and maybe ext3 with no journalling for "disposable" data. That way a corruption in the "disposable" data does not brick the system.

It you are interested in a bit of further reading:

https://yaffs.net/sites/yaffs.net/files/Considerations-in-choosing-a-flash-file-system.pdf

https://yaffs.net/documents/how-yaffs-works

Doug Gibbs had a comment about filesystem corruption in SD cards:

The thing to remember is the SD card, or eMMC card has a processor and firmware inside. The system level is not managing the NAND inside the SD card. This firmware is doing wear leveling, bad block management, and probably journalling writes to the NAND. Because NAND can fail, and has to be written in blocks a the firmware usually marks a written block as old, and writes data to a new clear location.

SSD will keep the location of a file-system block in the physical NAND in a large table. Unlike an "old" (I doubt new drives keep a 1:1 mapping) disk drive where blocks mapped to locations on the disk, the file-system block location is not associated with a physical sector/block on the NAND devices.

The difference between an "enterprise" class drive and a "consumer" drive is capacitors that will allow the drive to write any cached data and the mapping tables to NAND on power loss.

Because there is firmware involved, and that can be done really well, or really poorly, your results vary. For an SD card that costs 40 cents per Giga Byte, there is not a lot of extra horsepower inside for handling battery fail conditions. My point is, even with the best file system, things can go pear shaped.

Thor Johnson gave some advice about using SD cards in photography:

I always take the pictures from the SD card, then format them on the PC: https://www.sdcard.org/downloads/formatter_4/eula_windows/

Cleaning the card this way does 2 things:

1. Really cleans the card - no "spare bits left around" (see below)

2. Resets everything to 0xFF - Flash can program to zero much faster than a erase/rewrite block. So my cards are always operating at top (write) speed in the camera (only way to Trim a sd card is to format it), which is key for video.

Note that this is the formatter from the SD Card Standards Organization -- "formatting the disc" using Windows (or Mac) won't cut it. This is the same "format" that your camera does (but faster and not using the camera's battery).

The other good thing about #1 is that if you have a problem (and it's not a "card not recognized"), you can use things like PhotoRec/TestDisk (http://www.cgsecurity.org/wiki/TestDisk_Download) to get the data out byte by byte (using the age old sector-editor methods of "find bytes that look like an image", "find me a JPEG header", or "find some odd data in a sea of 0xFF's").

If you deleted files, there could be a mismashed jumble of data on the card, but if you start with a fresh format every time, I've found recovery to be pretty reliable (except for one A-Trend that "the USB device had a power surge and is not recognized") (usually 2 damaged photos, but the rest come back).

Also - if you have *any* problem with the card (too slow, counter resets, etc), move to a new card (and if you're changing batteries, change cards) - that way you limit possible corruption creep. I usually change (not swap - never go back to a partially filled card) cards every hour or so anyway.

PS. Those little Mentos tubes (http://amzn.to/2gNqFCt) work a slick treat for carrying SD cards -- I have a Green one for "blanks", a Red one for "used", and a Blue one for "Special" (my EyeFi cards go in that one) - and the ribs hold them into the elastic straps on my gear bag without me worrying about them falling out. I also take a picture of my business card as the first shot on the card - I have recovered an SD card by mail before (lost the camera, but a random guy sent me the SD card in the mail)...

And Steve Paik found an "easy" (given two years of spare time) way to extract pictures from a damaged SD card.

This Week's Cool Product

GW Instek (sold in the USA by Saelig) has a new line of oscilloscopes, called the MDO-2000E. Nothing remarkable there, except that these include a real spectrum analyzer (SA).

The price got my attention. Depending on bandwidth and number of channels they range from about $900 (two channel 70 MHz scope/500 MHz SA) to $1900 (four channel 200 MHz scope, 500 MHz SA). Now, Tektronix has a similar line of products which I reviewed in 2011. Tek's offerings have better specs than the new instruments from GW Instek, but you'll have to pony up a lot more greenbacks.

All digital scopes today have an FFT function to translate the scope display to that of an SA. (An SA plots amplitude vs frequency, rather than voltage vs time as on a scope). But the FFT is a very poor substitute.

An SA's front end is much like that of a superhet radio. An oscillator sweeps between two frequencies (set by the user) and heterodynes the input against the swept oscillator. The output of the heterodyning is filtered; you set a desired resolution bandwidth (RBW), which is just the width of a filter. With a narrow RBW only a small part of the signal is amplified so the broadband noise is rejected. Great sensitivity and signal resolution can be obtained.

The new MDO-2000E series may or may not work this way. The datasheet has a lot of words about the internals, but I find the description baffling. RBW is controllable so it's likely the units do heterodyne the input signal.

A scope just isn't very sensitive. Once you get down to a few mV noise overwhelms the signal. An SA, though, is designed to handle very low level signals. My Advantest has a DANL (displayed average noise level) of -132 dBm, which is about a tenth of a femtowatt. DANL is roughly the sensitivity of the SA. (To convert dBm to Watts: W=10(dBm-30)/10.)

But that's an expensive instrument. The new MDO-2000E devices have a claimed DANL of -90 dBm, or about a picowatt.

I've never seen a scope whose FFT function lets you set the RBW (or another filter, called the video bandwidth). That's a huge downside for serious RF work. (Note: I see nothing in the MDO-2000E's datasheet about controlling video bandwidth; it may or may not be user-controllable).

Here's an example. The input to my SA is just a two-foot long piece of wire acting as an antenna. The marker (the red dot) is at 100.7 MHz, the carrier of a local FM radio station. In the red box (it's hard to see) the marker's amplitude is displayed: -67 dBm (a fraction of a nanowatt). The display covers 90 to 110 MHz.

In this example I've narrowed the swept range to 1 MHz and centered the sweep on 100.7 MHz. The RBW is 3 KHz so a lot of detail is available.

(Alas, my SA is rather long in the tooth so I had to take photos rather than obtain nice screen shots).

The new MDO-2000E series SAs have a 500 MHz bandwidth, so won't be useful for most wireless protocols. However, at these prices a ham radio operator could be quite tempted!

Spectrum Analyzers are a lot of fun. When cell phones first came out we were working with a very-expensive government-supplied Tektronix SA, which had a built-in demodulator. We'd tune to the mobile bands and demod a signal when it popped up. Without exception, all of conversations started out along the lines of "Hey - I'm calling from my car!"

Note: This section is about something I personally find cool, interesting or important and want to pass along to readers. It is not influenced by vendors.

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.

You might be an engineer if:

  • If you are currently gathering the components to build your own nuclear reactor
  • If you own one or more white short-sleeve dress shirts (that sure is dated!)
  • If you have never backed-up your hard drive
  • If you are aware that computers are actually only good for playing games, but are afraid to say it out loud
  • If you truly believe aliens are living among us
  • If you have ever saved the power cord from a broken appliance
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.