Advertisement

Beware of the Datasheet Gap

By Keith Odland, Silicon Laboratories Inc.

I have noticed over the past several years a very disturbing trend in the area of microcontroller documentation. I call it, the “datasheet gap”. It is an insidious problem that wastes more cumulative embedded designer cycles than writing your own TCP/IP stack.

Keith Odland, Silicon Laboratories Inc.

By Keith Odland, Silicon Laboratories Inc.

Beware of the Datasheet Gap

I have noticed over the past several years a very disturbing trend in the area of microcontroller documentation. I call it, the “datasheet gap”. It is an insidious problem that wastes more cumulative embedded designer cycles than writing your own TCP/IP stack. Simply put, it is the balance of useful information between what is displayed on the first page of a datasheet and that contained in the numerous pages, tables, graphs, and footnotes within the datasheet.

As engineers, we know the devil is in the details. We are conditioned this way. When sizing a power supply, we must think about maximum values, not typical ones. In determining computational requirements, we must consider worst case interrupt traffic to select the most appropriate processor. In either case, the information needed to make a design decision is usually painstakingly captured in the body of the document. In contrast, the front page of the datasheet has become an advertising label, promoting the capabilities of a particular device in sometimes potentially misleading ways.

The result is that many times device selection is dictated by comparing the “front page specifications” of several suppliers and selecting the one that is the lowest cost. But, alas, here is the beginning of the problem.

Let’s follow this scenario a bit further using an example of an embedded controller design that interfaces to several sensors. Assume you need an 8-bit MCU with 32K of Flash program memory, at least 20 I/O, three timers, UART, SPI, and a 10-bit ADC. It would also be nice if the MCU has an internal oscillator. Reviewing the front page of two different supplier’s datasheets you have identified two devices with the same memory, similar I/O, a similar suite of peripherals, 10-bit analog-to-digital converter (ADC) and even an internal oscillator. Supplier A is less expensive than Supplier B so the selection is easy. You choose Supplier A.

As you dive into your project the details that emerge from the depths of the datasheet begin to shape your design in ways you had not originally anticipated. These almost always add cost – not reduce it. Examples that come to mind are:

• Maximum device speeds (i.e. higher CPU throughput) might be guaranteed only at higher supply voltages resulting in additional level translation circuitry or multiple power supplies.

• Internal oscillator accuracy may vary widely across operational voltage and temperature resulting in the need for more stable external timing components.

•Maximum frequency generated by the internal oscillator may be well below the advertised maximum operational frequency of the CPU resulting in reduced performance or the need for external timing components.

•A/D converters (ADC) may have sources of noise and variation that make its usable performance much less than its advertised performance (e.g. 10-bit ADC ±4 LSB is an 8-bit ADC). This could result in the need for additional signal conditioning circuitry.

• Digital sub-systems may have to be disabled during data conversion (e.g. placing the CPU in STOP mode during an ADC conversion) in order to guarantee noise performance of ADC. This can result in greatly reduced system bandwidth.

All of the above mentioned discrepancies are incremental and solvable problems – but not without a cost. The cost may be the additional components needed to address the problem in hardware, or additional development time to address it in software. Worse yet, the cost could be an inferior product not accepted by your customers.

Beware of the datasheet gap.

Keith Odland is a product manager focused on Silicon Laboratories’ MCU products. Prior to joining Silicon Laboratories, Odland served as a technical solutions manager for Future Electronics Corporation where he developed and deployed marketing and business development programs for 8/16-bit microcontrollers. He also co-founded Technology Kitchen Corporation where he developed a specialty instrument for the general aviation industry, which was adopted by an established aircraft instrumentation manufacturer. Odland has also served in various engineering management roles at Dell Computer Corporation and Eaton Corporation. Odland holds a bachelors degree in electrical engineering from The University of Texas at Austin.

 

Advertisement

Leave a Reply