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:

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.



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.


Intro to Microcontrollers series

This article is part of a larger series. You can find the rest of the articles below:




  • vijayakumar.s 2019-04-03

    Can you explain how to retrieve MCU program.

    • ehabawni 2019-05-29

      it depends upon the used MCU. lets take PIC microcontroller for example, using the PICKit 3 programmer debugger and MPLAB X or the standalone PICKIT 3 Programmer application, you can read the HEX file stored in the microcontroller and even the EEPROM data (only if the Program is not protected ). every other manufactures have their own way to retrieve the code from the MCU memory

  • adx 2019-04-22

    I’d add one more point: Go to the absolute maximums section of the electrical specifications, and check whether they could be exceeded. The device will almost certainly survive momentary transgression of these arbitrarily yes/no thresholds, but when this happens all bets are off, especially in a production design. This requires a bit of thought and experience (for example to know what will happen when connecting 5V signals to 3V3 pins) but is worth the effort, because it usually means something has been overlooked and devices will start failing in the field in the fraction of a %. Get this right and the failure rate will be in the parts per million, as the manufacturer intended.