This seems to be the month for celebrating the history of embedded systems.

Twenty-five year old compiler vendor IAR, which just launched a nicely redesigned website, has published an interesting history of the company and its founder, Anders Rundgren.

And next week I’ll be out at the Embedded Systems Conference, which is celebrating twenty consecutive years of bringing the community together with a backward-facing keynote led by Jack Ganssle.

Last fall, Netrino was asked by a prospective client to assist with the design of a product to be controlled by a smartphone. At first, the requirement was stated as a Bluetooth connection between the smartphone and the product. Later, however, Bluetooth was deemed by the client too complex a connection for their customers to manage. Thus the connection requirement was changed to a USB link via physical cable.

Unfortunately, and quite to our client’s surprise, this was easier stated as a requirement than implemented. USB is not a bi-directional protocol. According to the standard, each USB endpoint is either a “host” or a “device”. A PC running Windows is an obvious USB host. Printers and mice are obvious USB devices. But what about a smartphone, particularly a smartphone running Windows Mobile? Should a smartphone be a USB host or a device? The answer turns out to reveal a design oversight the original USB specification.

For historical reasons, USB was stuck with this host vs. device design issue and smartphones were all treated as USB devices only. (Smartphones make sense as devices when considered in relation to the host PCs they sync with.) So what would happen if you wanted to use a smartphone like our client as a USB host, with a device like a printer attached directly?

As we would learn in our research, this shortcoming of the original USB standard was recognized over a decade ago and a new standard called USB On-The-Go (OTG) was defined to allow products like smartphones to change roles from USB host to USB device on the fly. Unfortunately, this requires dedicated hardware at the USB interface–as well as different cabling.

For one reason or another, USB OTG technology never made its way into smartphones. There is certainly historical evidence of chip supplier attempts to integrate OTG. But perhaps the emergence of Bluetooth as an alternate host or device technology in that product space about the same time led to OTG being excluded from or disabled at the smartphone design level.

Unfortunately, that left our client between a rock and a hard place. Control via USB would be possible only with a USB host implementation in their product and a custom interface between that and the smartphone. The didn’t want to use Bluetooth and couldn’t use USB.

How have you solved this problem?

Many people take the position that electronic voting is less trustworthy than paper-based balloting. Without dismissing their concerns, I think we should also consider some of the positives that electronic voting may bring. Having moved this fall, I had the unlikely experience of using a shiny new touch screen electronic voting machine during the primary, then going back to a paper ballot during the general election. Traveling backward in technology like this gave me lots to think about.

Some of the really nice things about the touch-screen system are the ease with which a voter can change his mind or correct a mistake, and the virtual certainty that you’ve cast all the votes you are allowed and that they’ve been properly read. Misvotes, undervotes, and overvotes are all possible with optical scanners and other paper-based systems, since the ballot readers don’t give the voter any feedback. However, electronic touchscreen voting eliminates these issues.