Obstacles are those frightful things you see when you take your eyes off your goal.

—Henry Ford

There are a number of different metadata formats for containing low-level configuration information, some of them are in plain ASCII text, and others are in various encoded binary formats. The encoded binary formats, or Binary Level OBjects, are commonly referred to as "BLOBs". In this article, I will discuss how some of those formats are being used in existing products.

Let's start with the DeviceTree format, which is often utilized in describing the hardware of higher end platforms to the Linux Kernal. The DeviceTree definition starts with a DeviceTree Specification File also known as a .dts file. The DeviceTree Specification File is a human readable definiton of everything about the embedded platform, including CPU type, amount of memory, internal buses (AHB/APB/etc.), and all the relevent interfaces, like USB, UART, PCI, SPI/MMC, Ethernet MAC, GPIO pins, Pin Multiplexing, and more. It is a very complete specification of the underlying hardware platform. The DeviceTree Specification File is then run through the DeviceTree Compiler which produces the DeviceTree Binary Object (i.e. The Blob) which is also known as the ".dtb" file. The DeviceTree Binary Object (i.e. The Blob of the "Flattened Device Tree") is typically read in as part of the operating system booting procedure, and used to determine what device drivers are loaded into the operating system. I'll go into how this process works in much more detail in a later article, but that's the basic idea of a compiled Device Tree.

So how does this process relate to the IPMI FRU : (Intelligent Peripheral Management Interface - Field Replaceable Unit) data structure definition for add-on boards, and the TEDS (Transducer Electronic Data Sheet) data structure definition for attached Sensor devices? The following diagram depicts their relationship :

So, to put this all together in a more simple explaination :

• During the Main Board boot-up sequence, the Device Tree BLOB is parsed to determine all of the hardware interfaces contained on the Main Board.
• After the initial Main Board boot-up sequence, the IPMI FRU is parsed to determine the make and model of the attached Expansion Board, which identifies the attached Sensors.
• Then the TEDS BLOBs are each parsed to determine the parameters of the attached Sensors.
• Finally, the Operating System (Linux/Android) has all the information necessary to read and interpret the attached Sensors.

That is a very quick overview of what is a highly complex process for automatic discovery and configuration, based on currently used standards. The upshot of all of this is that at least three (3) separate and distinct parsers (namely DeviceTree, IPMI FRU, and TEDS, respectively) are required to put all of this together. For an embedded Linux system, such as a Xilinx Zynq based system, or an ARM A8/A9 class system, we are talking about a fairly large amount of code to implement each of the different parsers required to extract the necessary information. Do we really need three (3) or different ways (or more...) to encode similar data like this? Isn't there a more uniform way to accomplish this?

As one of my engineering buddies used to say, "Standards are great, and there are so many incompatible ones to choose from!" Clearly this kind of approach is going to be more difficult on resource constrained small systems, such as the Arduino, rfDuino, and TI LaunchPad. So, what can we do to improve the current state of the art here?

In our next segment, we'll discuss several of the evolving standards for Sensor Parameters that are being used in Sensor Hub and Sensor Fusion implementations, and what that means for developing an all encompassing method of automatic discovery and configuration on small form factor embedded platforms.

And finally, for your viewing pleasure, the original trailer for the 1958 feature "The Blob", starring a very young Steve McQueen. I still remember the first time I saw this movie, in a Drive-In Theater with my parents and family, in a Studebaker Wagonaire.

 

Wikipedia attributes the programming reference of "BLOBs"as a backronym to Terry McKiever, a marketing person for Apollo; who felt that it needed to be an acronym and invented the "Basic Large Object", which became widely used as "Binary Large Object". Since what I'm trying to implement are very small objects, I prefer the acronym, "Binary Level OBject".