How to Read a Microcontroller Datasheet: Exploring the Hardware

This article provides some tips on making efficient use of the peripheral sections in your microcontroller’s datasheet (or reference manual, or user guide).

In the previous article, I pointed out some of the difficulties associated with microcontroller documentation and then discussed the first three steps in my recommended procedure for avoiding datasheet burnout. Those first three steps apply to MCU documentation in general, and in this article we will focus on information related to the peripherals.
 

Previous articles in the Introduction to Microcontrollers series:

• What Is a Microcontroller? An Introduction to the Central Component in Countless Electronic Devices
• How to Choose the Right Microcontroller for Your Application
• How to Read a Microcontroller Datasheet: Introduction and First Steps

Step 4: Ignore the Peripherals That You Do Not Need

The peripheral modules within a microcontroller are largely independent of one another. Make sure that you understand this point, because it’s an important concept in the context of MCU-based system design. The following diagram emphasizes this point.

The elements of the processor are closely interconnected, but the peripherals are depicted as separate blocks that have an independent connection to the processor. This accurately reflects real microcontroller operation: if a given peripheral is not needed, it is placed in an inactive state and can be ignored.

However, microcontrollers are not designed to prevent interaction between separate peripheral modules, because in some cases this interaction is desirable, and that’s why I said that the peripheral modules are “largely independent.” For example, a periodic signal generated by a timer module might be used to establish the baud rate for a UART module or initiate conversions performed by an ADC module.

Nevertheless, the general principle is sound: unused peripherals will not affect the overall functionality of the device, and consequently you do not need to read the sections of the datasheet that explain all the details of these unused peripherals. This step alone can eliminate a large portion of the documentation burden, because many applications require only a small fraction of the generous peripheral functionality provided by modern microcontrollers.

Step 5: Investigate Your Configuration Software

Hardware configuration can be one of the most demanding and tiresome aspects of microcontroller development. Performing extensive register-level configuration of peripheral modules requires attention to detail, careful scrutiny of the datasheet, and lots of awkward bit manipulation.

Fortunately, people realized that this was not a good use of an engineer’s time, and manufacturers decided to create software tools that greatly simplify the task of hardware configuration. For example, Microchip provides MPLAB Code Configurator, which allows the designer to generate peripheral-configuration code using a graphical interface. The Config2 application from Silicon Labs (see screenshot below) does the same thing.

If you approach a datasheet with the assumption that you will need to manually configure all of the MCU’s hardware, you may find that a growing sense of desperation is making it impossible for you to concentrate. Believe me, hardware-configuration tools can greatly reduce the amount of datasheet material that you need to absorb.

The difficulty here is identifying the unnecessary information. Unfortunately, I’ve never come across a datasheet that has a section entitled “Things That You Actually Need to Know If You Plan to Use the Configuration Tool.” I recommend that you review the documentation for the configuration software before you dive into the datasheet, and when you are reading a section that covers a given peripheral, ignore the configuration-specific details until after you have gained some experience with the software.

Texas Instruments provides an entire software tool just for its MSP430 capacitive-touch-sense functionality. The graphical interface allows you to both configure and optimize cap-sense buttons, wheels, sliders, and proximity sensors.

The bottom line is that you shouldn’t waste your life poring over datasheet minutiae that have already been incorporated into free, user-friendly software.

Step 6: Investigate Your API

Hardware-configuration tools come with a major limitation: they cannot be used during program execution. Configuration software is something that you use to create code; it cannot modify a microcontroller’s operation in real time.

Fortunately, a large portion of the required hardware configuration typically takes place only once, namely, during the initial sequence of instructions that are executed after a reset. But there certainly are times when you want to make precise modifications during program execution, perhaps in response to an external event. This is where the application programming interface (API) comes into play.

“API” may not be the best terminology here, but I’m not familiar with any other words or abbreviations that are more appropriate. What I’m referring to is the collection of programming “shortcuts” provided by a manufacturer. Atmel calls this the Advanced Software Framework (you can read more about the ASF in this article), and I think that Silicon Labs uses the term Software Development Kit (SDK). In any case, the name is far less important than the content—i.e., library functions, example code, macros, preprocessor definitions, and anything else that helps the programmer to directly interact with the device’s hardware without becoming an expert in complex configuration settings.

The Advanced Software Framework has individual modules corresponding to the microcontroller’s peripherals.

I think that it’s important to be familiar with your microcontroller’s hardware, and I’m not recommending a “flyover” approach in which you rely completely on library functions, prepackaged drivers, sample code, and graphical configuration tools. This is a recipe for trouble, in my opinion, and it diminishes the benefits of using a processing device that provides efficient, direct access to the low-level hardware.

Thus, the goal is to find the proper balance. You need to study your microcontroller’s hardware and understand various aspects of its internal functionality, but when it comes to highly specific details, you don’t want to waste time reinventing the wheel. Your device’s datasheet probably contains a lot of information that has already been incorporated into the API, and much of this information can be skimmed or even ignored.

Conclusion

The title of this article is “How to Read a Microcontroller Datasheet,” though perhaps a more appropriate title would be “How to Not Read a Microcontroller Datasheet.” The fact is, documentation overload is a serious problem with modern microcontrollers, and an essential technique for quickly absorbing the important information is learning to avoid the unnecessary information.

If you have any tips for making the most of microcontroller datasheets, feel free to share your thoughts in the comments section below.