MCU datasheets sometimes present an overwhelming abundance of facts, figures, and specs. This practical, step-by-step guide will help you to identify and extract the information that you need.
Previous articles in the Introduction to Microcontrollers series:
- What Is a Microcontroller?
- How to Choose the Right Microcontroller for Your Application
As microcontrollers become increasingly sophisticated and powerful, their datasheets become longer and more complex. This is not surprising, and I certainly don’t want to criticize the manufacturers for attempting to provide detailed and comprehensive information about their parts. The fact is, though, that these lengthy and sometimes intimidating datasheets do present some problems.
Datasheet Difficulties
First of all, they can be an obstacle for students and engineers who don’t have experience with microcontroller development. For basic applications that rely on example code and library functions, it may be possible to get the job done without even looking at the datasheet. In most cases, though, it is essential to consult and even study a microcontroller’s datasheet, and for those who are not yet familiar with MCU implementation and firmware development, it can be difficult to approach a document that has ten or even a hundred times more information than what is needed for the project at hand. This article is written primarily for readers who fall in this category.
However, even seasoned MCU developers might experience a bit of “datasheet stress” when transitioning to a more sophisticated device or to a new manufacturer. I hope that this article will also be somewhat helpful for folks who fall in this second category.
Some Spec Sheet Specs
I want to briefly convey the scope of the problem by describing the documentation attached to a few microcontrollers from manufacturers that I recommended in my article on choosing MCUs.
- The MSP430FR5994 “ultra-low-power MCU” from Texas Instruments
- Datasheet: 171 pages
- User Guide: 1021 pages
- Errata: 15 pages
- The EFM8UB20F32G 8-bit USB microcontroller from Silicon Labs
- Datasheet: 57 pages
- Reference Manual: 308 pages
- Errata: 6 pages
- The STM32G0x0 “value line” 32-bit Arm Cortex-M0 microcontroller from STMicroelectronics
- Product Specification: 96 pages
- Reference Manual: 913 pages
- Programming Manual: 110 pages
- Errata: 11 pages
Step 1: Assess the Nature of the Documents
Despite the (oversimplified) title of this article, many microcontrollers do not have “a datasheet.” Various types of information may be distributed among multiple documents, and you need to briefly examine these documents in order to determine which ones have the specifications, descriptions, and recommendations that you really need during a particular phase of the development process.
As an example, the EFM8 devices from Silicon Labs have both a datasheet and a reference manual. The datasheet has a list of features, electrical specifications, some basic hardware-implementation examples, pin definitions, and footprint dimensions.
Connection diagrams such as this one are provided in the EFM8 datasheet.
Thus, I would use the datasheet when I’m investigating the device, checking a few performance specifications (current consumption, oscillator precision, ADC nonlinearity, etc.), creating the CAD component, and designing the schematic.
The reference manual, on the other hand, has detailed information about internal memory, interrupts, clock sources, the processor core, and all the peripherals.
Detailed descriptions of peripheral functionality (such as this diagram for an I2C transaction) are provided only in the EFM8 reference manual, not the datasheet.
The peripheral sections have register descriptions that provide all the information that I need to configure and implement a peripheral’s functionality. Thus, the reference manual is relevant primarily to firmware development, though it certainly does include information that must be incorporated into the schematic.
Step 2: Ignore the Core
Though I stubbornly insist upon the value of assembly language, I recognize that in general it is no longer a practical approach to firmware development, and I have no doubt that almost every person who reads this article will write MCU code in C/C . This means that the compiler will automatically manage numerous details related to the internal functionality of your microcontroller, and consequently you can safely ignore the vast majority of these details (at least initially).
For example, the MSP430FR59xx user guide dedicates about 40 pages to the CPU. In many applications, all of this information will be unnecessary.
Fortunately, this sort of information (from the MSP430FR59xx user guide) is typically important only for the compiler, not for the person who is writing the code.
The bottom line here is to think about all of the processor-related details that you do not need to worry about when you’re writing code in C/C , and then try to identify the corresponding sections of the datasheet so that you can skip them.
Step 3: Don’t Scrutinize the Electrical Specifications
Semiconductor manufacturers typically do an excellent job of thoroughly characterizing their devices. However, in my real-life engineering work—from my first day on the job to this present moment—I have found that only a small proportion of a device’s electrical specifications are relevant to a given project.
Thus, don’t be intimidated by a long datasheet section filled with specification tables, footnotes, plots, and timing diagrams. If there are a few specs that are particularly critical for your application, by all means check them, but also remember that empirical data gathered using your system under your operational parameters will be more valuable than the numbers in the datasheet.
Recap
We’ve seen that the documentation for modern microcontrollers can be voluminous to the point of becoming an obstacle, certainly for those who are new to this field, and perhaps even for experienced engineers. This article presents my first three suggestions for coping with documentation overload, and we’ll continue this discussion in the next article.
