You may redistribute this newsletter for non-commercial purposes. For commercial use contact jack@ganssle.com.

• Editor's Notes
• Quotes and Thoughts
• Tools and Tips
• A Major Birthday
• AdaCore Tech Days
• A No BLE Code, No App Code, Smartphone Interface
• This Week's Cool Product
• Jobs!
• Joke for the Week
• Advertise with us
• About The Embedded Muse

After over 40 years in this field I've learned that "shortcuts make for long delays" (an aphorism attributed to J.R.R Tolkien). The data is stark: doing software right means fewer bugs and earlier deliveries. Adopt best practices and your code will be better and cheaper. This is the entire thesis of the quality movement, which revolutionized manufacturing but has somehow largely missed software engineering. Studies have even shown that safety-critical code need be no more expensive than the usual stuff if the right processes are followed.

This is what my one-day Better Firmware Faster seminar is all about: giving your team the tools they need to operate at a measurably world-class level, 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.

Normally the Muse comes out the first and third Monday of each month, but due to the holidays this will be the only December issue.

Embedded Systems Conference San Jose - I'll be there December 6 and 7, giving a few talks, checking out the expo hall, and hopefully meeting Muse readers. More info here.

Discounted Better Firmware Faster on-site seminars in Europe: I'll be at the Embedded World show in Nuremberg February 27 to March 1. Being already in Europe, I will be offering on-site versions of this class in Europe for a reduced price shortly before and after the show. If interested, drop me an email.

"We could, for instance, begin with cleaning up our language by no longer calling a bug a bug but by calling it an error. It is much more honest because it squarely puts the blame where it belongs, viz. with the programmer who made the error. The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation. The nice thing of this simple change of vocabulary is that it has such a profound effect: while, before, a program with only one bug used to be 'almost correct', afterwards a program with an error is just 'wrong' (because in error)." E. W. Dijkstra, On the Cruelty of Really Teaching Computing Science

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

Paul Carpenter sent this link to a review of $1 MCUs. Interesting.

Do zombies have a role in software test? James Grenning has an approach he calls ZOMBIES. Check it out here.

Ralf Holly has some useful posts about using pointers in C. There's actually an entire book about pointers - I reviewed it here.

Toby Mole wrote:

70 years ago this month scientists at Bell Labs invented the first practical transistor.

It's hard to say when the electronics age started, but William Sturgeon's 1825 development of the electromagnet laid the seeds that led to Joseph Henry's crude telegraph in 1830, which was the first electrical system used to communicate over long distances (a mile). Just 14 years later Samuel Morse wondered what God had wrought over a 40 mile link he strung between Washington DC and Baltimore.

Considering the primitive nature of telegraphy at the time, it's astonishing just how quickly the demand grew. By 1851 Western Union was in business, and in the same decade Cyrus Field had connected the Old and New Worlds via a fragile cable that failed a mere three weeks after the first message was sent. But later attempts succeeded. Instantaneous transatlantic communication quickly lost its novelty.

Though Alexander Graham Bell's 1875 invention of the telephone is universally lauded today, it was a less than practical device till Thomas Edison came up with the carbon microphone two years later. The speaker's voice modulated a pack of carbon granules, changing the circuit's resistance and thus sending a signal to the receiver.

A number of inventors soon came up with the idea of wireless transmission, codified by Guglielmo Marconi's 1896 patent and subsequent demonstrations. Like the telephone and telegraph, early radios used neither CPUs, transistors, nor vacuum tubes. Marconi, drawing on the work of others, particularly Nikola Tesla, used a high voltage and spark gap to induce electromagnetic waves into a coil and an antenna. The signals, impossibly noisy by today's standards, radiated all over the spectrum... but they worked. In fact, Titanic's famous SOS was broadcast using a 5 KW spark gap set manufactured by the Marconi Wireless Telegraph Company.

The circuits were electrical, not electronic.

Telephone signals, though, degraded quickly over distance while radio remained crude and of limited range. The world desperately needed devices that could control the flow of the newly-discovered electron. About this time Ambrose Fleming realized that the strange flow of electricity in a vacuum Edison had stumbled upon could rectify an alternating current, which has the happy benefit of detecting radio waves. He invented the first simple vacuum tube diode. But it didn't find much commercial success due to high costs and the current needed by the filament.

In the first decade of the new century Lee de Forest inserted a grid in the tube between the anode and cathode. With this new control element a circuit could amplify, oscillate and switch. Those are the basic operations of any bit of electronics. With the tube, engineers learned they could create radios of fantastic sensitivity, send voices over tens of thousands of miles of cable, and switch ones and zeroes in microseconds. During the four years of World War I Western Electric alone produced a half million tubes for the US Army. By 1918 over a million a year were being made in the US, more than fifty times the pre-war numbers.

Electronics was born.

Electronics is defined as "the science dealing with the development and application of devices and systems involving the flow of electrons in a vacuum, in gaseous media, and in semiconductors," and the word came into being nearly at the same time the tube was created. But that's a lousy definition. I think the difference between electrical and electronic circuits is that the latter uses "active" elements, components that rectify, switch or amplify. The very first active devices may have been cats whisker crystals, a bit of springy wire touching a raw hunk of galena that works as a primitive diode. I can't find much about their origins, but it seems these crystals first appeared shortly before Fleming did his pioneering vacuum tube research. It's rather ironic that this, the first active element, which predated the tube, was a semiconductor, but that nearly another half century was required to "discover" semiconductors.

Radios originally sported just a few tubes but soon high-end units used dozens. In the late 60s I had a military-surplus 1940-era RBC radio receiver that had 19 tubes. Reputedly it cost $2400 in 1940 (over $42k today).

Increasing capability lead then, as it still does today, to ever-escalating cries for more features, speed and functionality. The invention of radar in World War II created heavier demands for active electronics. Some sets used hundreds of tubes. Perhaps the crowning achievement of vacuum tube technology was the ENIAC in 1946, which employed some 18,000. The machine failed every two days. Clearly, the advent of digital technology had pushed tubes to their very limits. A new sort of active element was needed, something that produced less waste heat, used vastly fewer watts, and was reliable.

Serendipitously, the very next year Walter Brattain and John Bardeen, working at Bell Labs, invented the transistor. The scientists had actually constructed a point-contact transistor, a difficult-to-manufacture device that is no longer used. (Other, earlier, inventors had filed patents for FET-like devices, though those were not based on silicon or germanium).

Point contact versions did go into production. Some early parts had a hole in the case; one would insert a tool to adjust the pressure of the wire on the germanium. Here's a sample:

Around 1950 (sources vary) Raytheon produced their CK703, the first commercially-available device. At $18 each ($188 in today's inflated dollars) these simply weren't competitive with vacuum tubes, which typically cost around $0.75 each at the time. Though point-contact transistors were tantalizingly close to an ideal active element, something better was needed.

Bardeen and Brattain did not include Shockley's name on the patent application. Shockley, who was as irascible as he was brilliant, in a huff went off and invented the junction transistor. One wonders what wonder he would have invented had been really slighted.

The modern transistor was born. But it didn't immediately revolutionize the electronics industry, which continued its love affair with tubes. It wasn't till 1956 that Japan's ETL Mark 3, probably the first transistorized computer, appeared, but it used 130 point-contact transistors and wasn't a practical, salable unit. The following year IBM started selling their 608 machine, which used 3000 germanium transistors. It was the first commercial transistorized computer. The 608 used 90% less power than a comparable machine built using tubes. With a 100 KHz clock, 9 instructions, and 11 msec average multiplication time for two 9 digit BCD numbers, it had 40 words of core memory and weighed 2400 pounds.

The telephone industry's demand for amplifiers accelerated the development of vacuum tubes, and it unsurprisingly snapped up semiconductor technology. As early as 1952 Bell Telephone installed the first transistorized central office equipment in New Jersey - again, using point contract transistors.

Alexander Graham Bell founded Ma Bell. He started as a teacher of the deaf and spent much of his career in service to the hearing-impaired. So not surprisingly the Bell Corporation waived all transistor patent royalties for the very first transistorized consumer product - a hearing aid, around 1953.

Old-timers probably remember Raytheon's CK-722, one of the first commercial junction transistors. It was available in 1953 for about $7 each, a lot of money in those days. I remember buying bags of random transistors from Radio Shack in the 60s which often had CK-722's, probably factory seconds. I have no memory of the cost, but as this was all allowance money it couldn't have been more than a buck or two for a bag of parts.

By late 1955 the same part cost $0.99. Moore's Law didn't exist, but the inexorable collapse of the prices of electronic components had started, entirely enabled by the new semiconductor technology.

Regency Electronics did produce the first commercial transistor radio (eponymously called the TR-1) as early as 1954. (Here's a movie of TR-1s being assembled.) TI, looking for a market for their new transistors, had approached a number of domestic radio manufacturers but was turned down by all but Regency. A contemporary TI press release about the TR-1 calls the components "n-p-n grown junction, germanium triodes." A triode was - and is - a three element vacuum tube.

By the early 60s consumers were infatuated with miniature radios (half of the ten million units sold in 1959 were transistorized). Marketers, then as now anxious to differentiate their products, started using transistor counts to sell product. Though at least one vendor managed to build a radio with just two transistors, and rarely were more than 8 actually used, often as many as 16 were soldered on the board - most, of course, unconnected. But headlines shouting "16 transistor radio" surely must have persuaded many to opt for one of those, rather than for one with fewer parts.

Now, of course, FETs are the basis of the digital revolution. The speed problems were solved, and their extremely low power requirements made it possible to pack millions on to a single IC.

So, happy birthday to the active element that we engineers have based our careers on!

AdaCore supports the Ada language, and they invited me to their annual Tech Days last month. The company updated us on developments in the language and the tools.

I've been an Ada fan for a long time. A lot of developers aren't. Some remember the bad old days when the compilers were slow and buggy. Others feel the language is so old it is ossified, when in fact it gets regular updates, the last in 2012. In fact, the committee is working on the next version, which will (hopefully) include a "parallel" token to instruct the compiler to generate code for many cores. There was some speculation that might also support partitioning a problem into GPUs.

Ada is a strongly-typed language with a carefully-specified syntax. Code written in the language tends to have fewer bugs than that in C - and it's usually delivered faster since those long bug-hunting sessions C encourages generally don't happen.

They told us that embedded systems are responsible for about half of all Ada deployments at the moment, and there's a slow but noticeable shift to it, especially in the automotive, medical and industrial automation markets, where bugs are deadly or expensive.

GPS, AdaCore's IDE, now supports Python scripting. One can interactively enter Python code, or read it from a file. Scripts can invoke API calls that expose GPS's internals, making it easy to automate many routine tasks. Windows can be created and new buttons defined. The debugger is available, too, so the scripts can read data from the embedded system and act on that. As an example, in just a few hundred lines of Python they implemented 8 quality checkers that mimic lint.

SPARK, now a part of Ada, offers even higher quality software, as the developer instruments the code with structures that automatically detect bugs. That, too, has been enhanced. AdaCore has a "stepping stone" approach to moving to SPARK; you don't have to go whole hog and jump right in. Instead, they have a three-step approach where for minimal efforts one can start getting the benefits of the language, then getting more, and finally making a complete commitment to it. There's a nice .pdf about this here.

DO-178C (called ED-12C in Europe) is the standard used for commercial avionics. At the highest levels it's quite demanding... but then, as far as we know, no commercial aircraft has been lost due to a software malfunction. The company now has a nice book detailing about how Ada can make getting DO-178C certification easier.

Finally, I often hear that Ada can't be used in microcontrollers. Oh, yeah? This video shows a line-following robot, programmed in Ada, on an 8 bit AVR part:

If you'd like to learn more about Ada, check out their AdaCore University: u.adacore.com.

Imagecraft has long been known for their reasonably-priced compilers and other tools. Developers tell me their support is outstanding.

The company also has educational resources, such as the excellent book C for Everyone which I reviewed here.

Recently they've come out with a new product called the Smart.IO. I found it a little difficult to get a sense of the product from its web page, but Imagecraft kindly sent me a kit. I've been playing with it and find it amazing.

The Smart.IO is a small (15x25 mm) board that you incorporate in your embedded system in order to give your system a link to a smartphone. It consists of the board itself, a library you link into your firmware, and a smartphone app (iPhone and Android are both supported).

Smart.IO board

Suppose you're building a smart wall plug that charges a battery. Like so many embedded systems, it would likely have modes that can be selected and maybe data to display. Adding switches and a control panel will drive costs and the form factor up - why not control it from a smartphone instead?

But who wants to write smartphone apps? Or the Bluetooth code required?

Enter the Smart.IO. Incorporate the board (or the IP into your schematic), link in the library, and (most importantly) don't write an app. Oh, and don't write the BLE code either. The latter is part of the library, and the former - the smartphone app - is created inside the wall plug's firmware.

I didn't grok this at first as it's paradigm-changing. And at second glance I figured that meant writing a ton of code. I was wrong.

The following is an app for the wall plug. The seven dots at the bottom represent one of seven screens written for this wall plug; one swipes left or right to go from one page to the other.

Other than a small amount of canned setup code, this is all that it takes to create this screen (and remember, this is in the firmware in the wall plug, not on the smartphone):

   SmartIO_PageTitle(p0, "Charging Status");
   SmartIO_MakeLabel(0, 0, "Input");
   u0 = SmartIO_Make3PosButton(0, 4, 1, 0);
   SmartIO_AddText(u0, "Slow/Normal/Fast");
   SmartIO_MakeSpacerSlice(3);
   u1 = SmartIO_MakeHGauge(0, 0, 40);
   SmartIO_AddText(u1, "Current input level");
   SmartIO_MakeSpacerSlice(1);
   SmartIO_MakeLabel(1, 0, "Battery level  ");
   u2 = SmartIO_MakeBatteryLevel(0, 1, 80);
   SmartIO_ClearText(u2);
   SmartIO_MakeSpacerSlice(4);
   SmartIO_AutoBalance(p0);

Your customer does have to download the Smart.IO app from Google or Apple, but that is generic. It's a blank screen, and knows nothing about your product. When the app is invoked it looks for BLE signals from Smart.IO-enabled devices, asks the user to select one, and then the code shown above, which is in your firmware, creates the screen.

I found the connectivity to be painless - it just works.

This example doesn't begin the plumb the scope of resources provided in the library. The manual documents these, but here are some of the functions available using calls as shown above:

• Sliders
• Calendar selector
• Weekday selector
• Checkboxes
• Text entry

API calls to display things include:

• Text
• Progress bar or circle
• Horizontal and vertical gauges
• Battery level
• LEDs
• Popups

... and a whole lot more.

An Arduino-like shield is available for a ST evaluation board (using a Cortex-M processor) for development purposes, and (as I did) for playing around with the technology.

The Smart.IO board is priced at $22.95 in singles. They tell me substantial discounts apply for quantity purchases.

Have you ever heard of an electrolytic tilt sensor? I hadn't. Turns out they've been around since the 1940s and are still in use. This video (from a vendor of these products) describes how they work and where they make sense. Simple things, really, but clever.

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.

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.

Note: These jokes are archived at www.ganssle.com/jokes.htm.

From Steve Land:

I'd tell you a UDP joke, but I'm not sure you'd get it.

Advertise in The Embedded Muse! Over 27,000 embedded developers get this twice-monthly publication. .

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.