Follow @jack_ganssle
Go here to sign up for The Embedded Muse.
TEM Logo The Embedded Muse
Issue Number 306, June 6, 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

We know where bugs come from in the life-cycle. But do you know the differences between chaotic organizations and those developing in a careful - and efficient - manner? In my one-day Better Firmware Faster seminar I use engineering metrics to show how a group can achieve world-class status, producing code with far fewer bugs in less time. It's fast-paced, fun, and uniquely covers the issues faced by embedded developers. Information here shows how your team can benefit by having this seminar presented at your facility.

I have a new video out - it's a review of Siglent's new SDG 2042X arbitrary waveform generator.

I'm now on Twitter.

Quotes and Thoughts

"A programmer who uses assertions while testing and turns them off during production is like a sailor who wears a life vest while drilling on shore and takes it off at sea" - Tony Hoare

(I think that in the world of constrained resources typical of many embedded systems this quote is more aspirational than realizable, but it does make one think).

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.

Charles Manning has a semaphore idea:

As for tricks of the trade: Like Ralph Holly, I like exploiting macros....

One problem that is quite common is debugging a locking issue. A semaphore or such gets locked and unlocked from various places and somewhere along the line the code hangs because the semaphore was not unlocked.

Lets say locking goes through two functions: lock(ptr_to_semaphore) and unlock(ptr_to_semaphore).

Redefine the functions with:

__lock(semaphore_t *sem_ptr, const char *fname, int line_no)
   {
   lock the semaphore here
   sem_holder_fname = fname;
   sem__holder_line_no = line_no;
   ...
   }
#define lock(s)  __lock(s, __FILE__, __LINE__)
               

and similarly for unlock.

Fire up the trusty debugger and wait for the condition to occur. Have a look at sem_holder_fname and sem_holder_line_no and you will see the file name and line number where the offending lock was taken.

Freebies and Discounts

Chris Hills and friends have made an old book "Software Projects: Evolutionary vs. Big Bang Delivery," by Felix Redmill, available as a free .PDF. Long before agile was born, most of the ideas underlying agile development had been packaged by Mr. Redmill and Tom Gilb, and this book is a good look at their thinking. Get it here.

Thanks to the generosity of Imagecraft, this month we're giving away one of their Wifi2go starter kits. This includes the board shown, an ST-LINK/V2 and a set of development tools. Enter via this link.

Generating Unique Error Codes

There's never enough time to attend more than a handful of talks at an Embedded Systems Conference. Probably the most interesting that I sat in on at this year's Boston show was Architecting First-Failure Data Capture (FFDC) for Microcontroller Software, presented by Germán Rivera. In a whirlwind 45 minute talk Mr. Rivera gave a number of really useful ideas for capturing error events. I've been a fan of Design by Contract for years, which is sort of a super-sized version of the assert() macro. DbC is built into the current version of Ada, and much of the session focused on using asserts in a disciplined fashion to approximate DbC in C.

One interesting notion is to use a feature of GCC (and perhaps some other compilers) to automatically generate unique error codes. The idea is to call a function that will return a code that can be printed or logged to identify exactly where the error occurred. A sample he presented is:

 typedef uintptr_t error_t;
 error_t generate_unique_error_code(void)
 {
   uintptr_t caller_addr = (__builtin_return_address(0) & ~0x1) – 4;
   return (error_t)caller_addr;
 }

__builtin_return_address(), provided by GCC, returns the address of generate_unique_error_code()'s caller (it unwinds the stack and with an argument of 0 returns the return address).

This example is tailored to ARM Cortex processors; the "& ~0x1" is for thumb 2 instructions; the "-4" corrects for the size of the BL instruction.

When an error is reported use the GNU utility addr2line to convert the logged address to a file name and line number.

Pretty cool! Do any other compilers provide functionality like GCC's __builtin_return_address()?

On Tubes and Valves

I get a fair amount of correspondence from readers interested in the history of electronics. In my opinion "electronics" is most closely associated with active elements: transistors, diodes, vacuum tubes, and the like.

This year marks the 110th anniversary of the tube. It's appropriately called a "valve" by our English cousins, since tubes control flow of a substance, in this case electrons.

The tube pretty much started the electronics revolution. It made computers possible. So here's a little background on an almost (but not quite) obsolete bit of tech that launched the electronics and computer revolutions.

Many early pioneers contributed to the tube's birth, but Lee de Forest is generally credited with the first triode. The history is sordid and sad. De Forest never really understood how it worked. Edwin Armstrong did, and the litigious de Forest was humiliated in one of his many court battles when Armstrong correctly described its operation. Armstrong was truly an electronics pioneer, but was involved in nearly continual patent battles. He eventually committed suicide.

Radio was the first serious application for tubes; the first regularly-scheduled commercial broadcasts started in 1919. There were few listeners, but with the growth of broadcasters demand soared. RCA sold the earliest consumer superheterodyne radio in 1924; 148,000 flew off the shelves in the very first year. RCA's Radiola AR-812 sold for $286, which is about $4000 in today's dollars.

Can you imagine paying $4k for a radio?

(If you're not familiar with how a superhet radio works, the Wikipedia entry is pretty good. It's the basis of most radios today and a brilliant bit of engineering).

De Forest's "Audion" (his name) was what we call a triode today. It's a three-element device, much like a transistor, whose schematic symbol is:

It's a very simple device. Voltage on the filament (most often 6.3 or 12.6 volts AC) heats up the cathode and causes electrons to boil off. And that filament did get hot -- tubes have a unique glow when operating. The electrons are attracted to the positive plate, but have to pass through a wire mesh grid. If the grid's voltage is somewhat negative, the electrons are repelled from it, so some never make it to the plate. A small grid voltage therefore can control a much larger cathode-to-plate potential. Bottom line: it's an amplifier. And it can be used as a switch, which, of course, was the usual application in digital circuits.

Here's a nice illustration of a tube's structure from RCA's RC-30 Receiving Tube Manual (available here):

Sometimes tubes were even more colorful than just the gleaming filament. When many watts were involved a blue glow was emitted, which danced with the applied signal.

The tetrode came about not many years later. In this tube an additional grid, called the screen grid, was placed between the grid and the plate. The screen reduced the gird-plate capacitance, but enterprising engineers also found ways to exploit it to create, for instance, the "ultra-linear" amplifier. However, electrons bouncing off the plate hit the screen grid causing instability and oscillation. So yet another grid (the suppressor) was added between the screen and plate, forming the pentode.

I have seen schematics that indicate some tubes had even more grids. Thankfully the transistor came along before electrons had to traverse a veritable minefield of them.

An incredible variety of tubes were available, from the tiny thimble-sized Nuvistor to gigantic transmitting tubes.

A vacuum tube could do pretty much anything a transistor can. An example: this is a circuit of a inverter used in IBM's 701 computer:

The parallel to a transistor version is striking.

Here's a logic module from the IBM 701:

There are eight tubes, each of which contains two triodes. So this monster is the equivalent of 16 transistors. Compare that to the 128GB thumb drive I bought for $40 not long ago, which sports probably a third of a trillion transistors. Also note the huge resistors - there's no SMT here!

I've not been able to find out how many tubes were in a typical 700-series machine, but there must have been thousands. Consider this: an IBM 701, with a total main memory of 2K words, cost $12,000 per month to rent. That's over $100k today! As I write this Best Buy has a new desktop PC with 4 GB RAM and 16 GB of flash for $219.95. The IBM 700 came out the year I was born - that's a staggering amount of change in a single lifetime.

Despite transistors' obvious superiority over tubes, the latter lingered on for a long time. CRTs were the most obvious example of this. I bought a ham transceiver in 1978 that used two tetrodes in the 100 watt final amplifier stage as high-power RF transistors were simply too expensive. Old-timers will remember these 6146B tubes which were hugely popular in ham circles, though they were most-often found in TV sets.

It appears that modern high-power transmitters in commercial radio stations are now transistorized, but not long ago most used enormous tubes in the high-power circuits. Typical was the 5671 triode, which weighed 228 pounds! The filament, at 11 volts, needed 285 amps. Plate voltage was 15,000 at a max of 6 amps. There are some great pictures of this monster here.

You still use tubes - the cavity magnetron that powers your microwave oven is one. Klystron tubes were invented in 1937 and were the first decent way to generate high-power high-frequency signals. This octogenarian technology is still in use today in a variety of RF applications. They're common on communications spacecraft, too. So the very highest of high tech relies on technology that dates back to the birth of electronics.

A smart phone has well over 100 billion transistors. If we built one using tubes the phone would be about the size of 170 Vertical Assembly Buildings (the largest single-story building in the world). That would certainly discourage texting while driving. Weight? 2500 Nimitz-class aircraft carriers. And what a power hog! Figure over a terawatt, requiring all of the output of 500 of Olkiluoto power plants (the largest nuclear plant in the world). A tube-powered phone would run a cool $50 trillion, almost the GDP of the entire world.

And that's before AT&T's monthly data plan charges.

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.

Phil Ouellette sent this ironic ad he found:

Advertise With Us

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