Do the difficult things while they are easy and do the great things while they are small. A journey of a thousand miles must begin with a single step.
—Lao Tzu
I spoke at the Portland thingTuesday meeting this week about some of the limitations of currently popular small form factors like Arduino, rfDuino, TI LaunchPad, and others. My personal opinion is that one of the biggest limitations of these small form factors is the lack of an automatic configuration standard.
In other words, when you plug a shield into an Arduino Leonardo for example, the Arduino has no idea of what shield is present, or how to talk to it. I contrast this with something like PCI, or USB, where a device descriptor table can be interrogated to determine things like the manufacturer and product names. In my talk, I asserted that this was one of the reasons that made USB and PCI/PCI-E so successful; this ability is one of the things that makes them easy to use.
So I started looking around at some of the existing standards out there in order to see if there wasn't already something available that could be used for this purpose. Some of the descriptor formats that I looked at were :
- USB : Universal Serial Bus
- PCI : Peripheral Component Interconnect
- TEDS : Transducer Electronic Data Sheet
- IPMI FRU : Intelligent Peripheral Management Interface - Field Replaceable Unit
- Device Tree : Linux Device Tree Hardware Description
IPMI on the other hand, a standard developed by Intel, HP, NEC, and Dell has been widely adopted by computer server manufacturers, and utilizes plain text fields to store design metadata like Manufacturer Name, Serial Number, Asset Tag, UUID, MAC ID, and more. The FMC (FPGA Module Carrier) standard from VITA adds additional fields to describe power supply requirements. I also liked the idea of just being able to put something like "Joe's Garage" as a Manufacturers Name, and not have to deal with some association to dole out a specific registration number. However, IPMI doesn't really have the detailed Sensor and Transducer fields and parameters of something like the TEDS (Transducer Electronic Data Sheet) standard.
I spent quite a bit of time reviewing the TEDS IEEE standard, which is insanely complex enough to require it's own compiler to implement. TEDS was also designed about a decade ago, and so many of the tradeoffs that were made in that standard, such as reduced memory footprint and reduced packet/data sizes, are not as big a cost and performance issue as they were ten years ago. Additionally, the default TEDS interface (which they refer to as an MMI) is based on the proprietary Dallas/Maxim 1-Wire bus, which is heavily patented (though expired perhaps?) and not really the kind of "open standard" that I want to base our solution upon. Besides most microprocessor systems implement the Dallas/Maxim 1-Wire bus using bit banging on general purpose I/O pins (GPIO), and that is really sloooow in performance. IMHO, the TEDS standard is just too complex and convoluted for the maker community to adopt "en masse", although it does have some pretty impressive capabilities.
One of the standards now being adopted on ARM based Linux platforms like the Beaglebone and Raspberry Pi is the the Device Tree format. This is a very comprehensive standard for describing the basic topology of bus connections on embedded platforms, and includes support for buses like ISA, PCI, SCSI, and others. The Device Tree format also requires the use of a compiler to turn a Device Tree Specification file into a compact binary "blob" of data, that bootloaders such as the Grand Universal BootLoader, or GRUB, can parse to find the bootable devices within a embedded system. Since the embedded systems that utilize this standard typically have Megabytes (Or Gigabytes) of memory available for decoding the binary "blob" of data that descibes the device tree, it may not be suitable for much smaller embedded systems like the Arduino, that typically have only Kilobytes of memory available. While it was primarily developed for describing bootable interfaces, it has been extended to support many kinds of new devices, including sensors.
I started thinking about other, more compact ways, that could be used to implement automatic discovery and configuration of sensors and other peripherals, using a simple metadata repository that could be included on small form factor boards like shields and breakout boards. This is already done using the IPMI FRU standard on most high-end FPGA mezzanine boards, and using the Device Tree format on the new Beaglebone Black platform. By just including a low cost (~$.10) I2C EEPROM on each shield or breakout board to contain a device descriptor, these small form factor boards can now be automatically discovered and configured. It would be a very small additional cost, that would greatly increase the ease of use. (not to mention reducing those customer support calls...)
Unfortunately, none of the standards that I have looked at have ALL of the capabilities that I'd like to see (yet), and I don't think that I've overlooked any other options. Please give me a shout if you know of one that I may have missed...
I'm pretty familiar with the IPMI FRU standard, and it does have some Sensor support capabilities, which they refer to as a "Sensor Data Repository", or SDR. One advantage of going with this FRU metadata format is that there are already parsers available for Linux. If IPMI is installed on your Linux machine, you can just use the ipmi-sensors command to display all the sensors running on your machine. This would work really well with Raspberry Pi Plates for example, as this Linux utility could be ported to the RaspPi pretty easily.
In my next article, I'll outline some of the tradeoffs and implications of current methods for automatic discovery and configuration of peripherals and sensors.