Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Embedded Systems

Getting Experienced


Ed is an EE and author in Poughkeepssie, NY. Contact him at [email protected] with "Dr Dobb's" in the subject to avoid spam filters.


One of the hidden themes in last year's Embedded Systems Conference was that experience matters. Whether it's avoiding an error you've made before or recovering quickly from a new problem, knowing your field in depth helps you get the job done. Whether that's a marketable skill depends on circumstances beyond your control, but at least you get some satisfaction from knowing what you're doing.

This month, I'll collect some data points to show how this works out in practice.

Missing One Little Point

The fundamental illusion of all desktop and server application development methods goes something like this: Resources are free, unlimited, and readily available. Should your code run out of something, don't worry, more is on the way. Over the decades, we've seen some truly bizarre hardware designs intended to maintain that illusion.

For example, within the lifetime of those yet living, a "personal computer" with 640 KB of memory should have been, as Bill Gates evidently didn't say, enough for anyone. Intel's 8086 architecture grafted 20 physical address bits on a 16-bit datapath, inspiring all manner of bizarre memory expansion techniques culminating in the Lotus-Intel-Microsoft Expanded Memory Specification for paged access to megabytes of agonizingly expensive RAM.

The jump to 32 address bits sufficed for a mere decade, whereupon Intel's Physical Address Extension (another four bits!) gave paged access to 64 GB of physical memory. The jump to 64-bit microcontrollers, with current implementations limited to addresses of a mere 40 or 48 bits, should last longer.

On the other hand, we're chewing through two address bits per year and 2020 isn't all that far away.

Embedded development differs slightly: You don't have enough of at least one resource and you won't get any more in time to finish the job. In the bad old days you ran out of memory or datapath, nowadays there's not enough connectivity or power (which is identical to CPU speed). Sometimes, you have enough of everything, but it doesn't work quite the way you expected or has limits that your tools simply don't notice.

Some years ago, a friend called for some advice on a power-line data logger he'd built to track down utility-power glitches. It wrote a running record of voltage disturbances into a nonvolatile EEPROM, but after a week or two the memory failed. In fact, several different memory chips had failed the same way.

The EEPROM datasheet specified an endurance of 100,000 write cycles, which seemed like enough for years of recording at the expected rate. Alas, it transpired his toolchain had inadvertently put a few "hot" variables, ones updated every few seconds, into the EEPROM's address space. The arithmetic is easy:

605 × 103 sec/week=

168 hour/week × 3600 sec/hour

Perhaps surprisingly, a variable written every six seconds chews through the EEPROM's entire rated lifetime in a week. The remainder of the EEPROM might still be usable, but those addresses were hammered dead, dead, dead. Once we found the problem the fix was trivial, but it still required manual intervention.

Contemporary flash memory includes wear-leveling routines in the on-chip controller that automagically shift repeated writes at the same address to different physical cells. That's particularly helpful for applications designed without regard for memory that expires after some number of uses.

The FAT filesystem used in essentially all USB flash drives comes to mind. All file additions, deletions, or size changes also update the File Allocation Tables at fixed locations near the start of the disk image. In the absence of wear leveling, those disk sectors can fail very quickly on an active drive.

Small embedded systems often include flash memory rather than a hard disk, trading reduced storage capacity for increased mechanical durability. Although the memory can be connected directly to the CPU for use with a flash-friendly filesystem, the trend seems to be toward hardwired disk emulation through standard PC-oid interfaces.

In fact, you might well be able to plug in a stock IDE hard drive during development and replace it with a flash drive sporting an IDE interface for deployment, all without changing a single line of code. What's not to like?

Several ESC presenters described a common interaction between off-the-shelf hardware, standard operating systems, and developers assigned to their first embedded project. It seems that system event logs, so familiar in desktop and server environments and so vital during development, sometimes find their way into the finished product. That might be handy for debugging, but tends to fill up small flash drives while wearing out the underlying memory cells.

Oops.

The trick, of course, involves turning off the log-to-disk daemon or service before releasing the project. Should you forget, you'll certainly get a reminder!


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.