A Guide To PIC Microcontroller Documentation/Print version

From Wikibooks, open books for an open world
Jump to navigation Jump to search

A Guide to PIC Microcontroller Documentation Datasheets for semiconductor products can be baffling even for the most experienced engineers and programmers, but those written for microcontroller or digital signal processing products are even more so. One of the challenges of writing a datasheet for such products is that, due to their programmable nature, diversity and flexibility, it is difficult to successfully separate out the raw data about the product and its peripherals from programming them and ultimately developing functioning applications based upon them.

Even those with several years experience on one family of products from one silicon manufacturer may have difficulty finding the information they are accustomed to in the documentation of an alternative silicon supplier. This is due to each manufacturer writing their documents in differing ways and even using varying terminology or acronyms for the same terms.

This guide aims to explain what type of information is split over which documents for the Microchip PIC family of microcontrollers and digital signal controllers from Microchip Technology which should help those making their first tentative steps with this broad range of controller products.

Who is this written for?

This guide is written primarily for professional embedded developers who are moving to the Microchip range of controller products for the first time and need guidance on where to find the information they need to make informed decisions on the products' capabilities or how to program and use them.

It is also ideal for those in higher education (both learning and teaching) to gain an insight into how technical information on complex silicon products is written and which details are to be found where. For those who take a personal interest in these products, but do not necessarily work in the embedded system profession, enlightenment may also be found as to why certain information is documented as it is and where.

How this book is constructed

This book is split into three sections; the first is recommended reading for all those reading this book for the first time and ensures that basic knowledge required to understand the rest of the book is clarified; the second section examines the documentation available for the different products on a controller family and sub-family basis, ideal for those making a start with a particular Microchip PIC device; the third and final section is a terms-based guide to documentation allowing those with previous knowledge (either with these products or those from an alternative supplier) to get quickly to the information they need, based upon the knowledge they already have.

The sections and their contents are:

Recommended prior knowledge

This book assumes the reader has a grounding in electronics, microcontroller architecture and programming, embedded systems or a combination of all three. Terminology common to these areas will be used without further definition or explanation.


Authors and contributors

Notes for contributors



Please add {{alphabetical}} only to book title pages.

A Guide to PIC Microcontroller Documentation

Methodology behind PIC® controller documentation

Microcontrollers and digital signal processors (DSPs) are challenging products to document. On the one hand, the semiconductor vendor has to describe the functionality of the device's processing core, the functionality and possible settings of peripherals and the electrical and packaging specifications of the device. This description needs to concentrate on the raw functionality of the device's circuitry and the registers which they form. For example, a UART (Universal Asynchronous Receiver Transmitter) peripheral's functionality, as described in a datasheet, focuses upon, among other things, setting up the related transmit and receive pins of the device for use as a serial interface, how to calculate the required baudrate settings and how to enable parity support.

On the other hand, raw details on functionality and setup alone cannot inform a developer how to use that peripheral, processor or other feature in an actual application. Using our UART example again we know that a UART can be used in a variety of serial interfacing standards such as RS-232 and RS-485 amongst others. In addition that standard may have standardised software layer with which it is commonly used (for example ANSI escape sequences used with VT100), and a common circuit layout external to the controller to implement the required signalling (for example a MAX-232 family transceiver used with RS-232).

A further challenge documenting controller products is due to their infinite flexibility, as programmable products, and the fact that the software can be written in a variety of different programming languages using a broad range of software tools from different vendors of which some, or perhaps none, come from the silicon vendor themselves.

Lastly there is the issue of the software programs and hardware tools used for creating and debugging the firmware for the controller and the programming tools used for small production runs or mass-production.

As a result, datasheets alone typically contain around 100 pages, often running to several hundred pages, and in the interest of keeping the size of the datasheet manageable, much common and implementation or application specific data is located in various other documents with names such as "Family Reference Manual", "Application Note" or "Programming Specification".

A Guide To PIC Microcontroller Documentation <-- Return to start of book
Next Section --> Linking Documentation To Controller Family

Detailed analysis of controller family documentation

In this section we will be taking an in depth look at the main documentation for one controller out of each PIC microcontroller family. In each case the key documents will be listed and then the datasheet will be analysed chapter by chapter to highlight the information that is provided, and how related information can be found in the cases where the documentation is rather sparse.

In each case we will select a device that is the largest in its class in terms of performance, memory and number of peripherals. All other devices in that family will contain a sub-section of the information contained in the analysed device. There is a lot of similarity between families, and therefore there will be lots of repetition between chapters here, but since each engineer only focusses on one family or device at one time this method of documenting the datasheets here should prove to be most beneficial to the reader.

Base-line device documentation

Mid-range device documentation

Enhanced mid-range documentation

High-end device documentation

16-bit MCU device documentation

16-bit DSC device documentation

32-bit device documentation

Further reading

Please enter your name here as an author if you have made a significant contribution to this text, or as a contributor for smaller contributions. And thanks very much for your support!



Contents: Top - 0–9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z


  • DSP - Digital Signal Processor - processor designed to efficiently process discrete signal data (e.g. audio, video). Key processor instruction on a DSP is the MAC instruction (multiply and accumulate) which allows a single piece of data to be multiplied by a single coefficient value and added to the value currently in the processors accumulator, all in a single processing cycle.
  • DSC - Digital Signal Controller - acronym used by Microchip Technology to define their dsPIC family of products which contain a microprocessing core and a DSP. The alternative definition is used to highlight the products embedded control properties (fixed latency times for jumps into interrupt routines, fixed instruction processing time) regardless of which instruction the processor is currently processing, which is typically not the case for pure DSP architectures.


  • Workaround - typically a software solution to a hardware problem in a controller product. Usually involves reordering code to avoid a hardware problem, or changing a setting under certain situations.