[SOLVED]Trick for reading any microcontroller datasheet

Thread Starter


Joined Apr 5, 2021
If you are a beginner, you will be given a 1000 to 2000 page microcontroller datasheet to read fist time that will make you feel uncomfortable. I have been through the same experience.

Of course it can be said that read the datasheet until you understand it completely but I would appreciate for any advice

I need some tips and tricks so that I don't waste too much time reading this!

Warm regards


Joined Jul 18, 2013
Generally at first you don't need to cover all the material, just enough to get started and the module or section you might be using at first.
Is this for a project or a instructors material ?


Joined Apr 2, 2020
I would first focus on how to create some type of "blink" or "hello world" minimum operation with a GPIO - confirm you can get it programmed with something and understand the chip language. Then add in a peripheral with each iteration of understanding (timer, pwm, ADC, etc).


Joined Aug 7, 2020
Before you even do that, find out how many usable inputs and outputs it really has. Pins can generally be used for several different peripherals, but is there a combination that gets you all the peripherals you need connected to the outside world?

For instance, the LPC5502 claims to have 9 ADC inputs, but two of them are allocated to the same pins as the SWDIO and SWCLK that you need to program it. So it only has 7 usable ADCs.

And, in the current circumstances, before you decide to use a certain device, make sure that someone has some in stock!

Thread Starter


Joined Apr 5, 2021
Here are some of my sequences which I think would common to all microcontrollers.

Tips #1 I think the first thing to pay attention is the port pin configuration. Like how a PORT Pin is made an input or output pin.

Tips #2 it is important to understand the clock setting configuration

Tips #3 After this, thinking about how to make the LED blink

Tips #4 Blink LED with timer interrupt


Joined Mar 30, 2015
Here are some of my sequences which I think would common to all microcontrollers.
The thing that's usually most important to me is the drive capability of the outputs and the maximum amount of current that can be forced in to an output. Both are usually buried past the middle of the document. That is, if you can even find the latter.


Joined Aug 7, 2020
What would be a challenge for even an experienced datasheet-reader would be to determine the maximum current consumption, for the chosen speed and active peripherals!


Joined Jun 30, 2021
In many situations I would say reading and understanding a datasheet 'in full' is important, but when it comes to microcontrollers and 32/64bit processors, this is not a realistic goal. I would recommend the following order:

1. Choose a device and package. If you are using a solderless breadboard you can usually get a DIP type for prototyping and go to an SMT later when you want to build a final circuit. Or you can choose an evaluation board. One negative I found about evaluation boards at least for microchip: They tend to be flaky if you use the onboard free programmer/debugger which seems to cause more annoyance when trying to learn than it is worth. I have found it better to have a board that connects using a descent programmer. For the PIC I have found the PicKit4 very reliable and stable.

2. Read the electrical spec for each pin of the chosen device. A lot of times the datasheet will have a 'minimum' required connections' for each pin. Be sure to apply power and external components exactly as the datasheet specifies. The datasheet will talk about each pin, its abilities and how it should be connected.

3. Read the section that discusses the oscillator(s) for the part. How they are setup and what your choices are for clocking the part. A lot of times manufacturers will provide internal clock sources so you don't have to have an external one, but these internal clock sources tend to not be very accurate. You will want a good understanding of how the clock system for the part works, what the options are. Many have built in PLL's that allow you to convert a lower speed clock and multiply it to a higher speed clock. Often the peripherals can run on their own clock or the system clock.

4. If you choose to use an external clock source, on a breadboard I would recommend a canned LVTTL oscillator over a crystal. If you do want to try to use a crystal be sure to follow all the recommendations of the datasheet and especially the datasheet for the crystal. Do not attempt to deviate from the recommendations.

5. Certain pins on the device will be available for programming/debugging using one of the manufacturers programming/debugging tools. Read this very carefully and provide the programmer/debugger the required connections as recommended by the manufacturers datasheet. I would recommend using an appropriate programmer/debugger provided by the manufacturer.

After all of this you can then write your first blink an LED app.

For the PIC32 there is a datasheet for the main part that goes over all the peripherals but not in detail. Then there are 'sections' that you can download for each special peripheral module. Not sure but I have a feeling other manufacturers probably do the same thing but maybe not.

You may want to learn a specific microcontroller and stick with that type for a while. There are plenty of manufacturers to choose from. Learning 'all' of them is not realistic.


Joined Aug 7, 2020
2. Read the electrical spec for each pin of the chosen device.
I'd just like to add.
Also read the spec for the power supply pins. For example, if each pin will deliver 5mA, but the Vss pin limit is 100mA, then you can only connect 20 LEDs!
Don't leave pins floating. Many microcontrollers' GPIO defaults to a setting with the pull-ups enabled. If so you don't need to connect them, but if they default to high-impedance inputs, connect them to a power supply via a resistor. Use a resistor rather than connecting them directly, in case you accidentally program them as outputs.

Crystals have never given me any trouble - I've never thought it worth the expense of an external oscillator. I just give them 15pF or 22pF load capacitance and they have always worked. Am I just lucky?

Don't write your software to re-allocate the programming pins to some other function. You might never get them back to being programming pins!


Joined Jun 30, 2021
+2 on crystals. Sometimes require an easy load calculation and short traces so you’re not adding any extra LC.
That is why I did not recommend them for solderless breadboard prototypes. There are exceptions. I used a 32.768Khz crystal for the microcontroller on board real time clock. The manufacturer recommended a series resistor of 330K from the drive pin of the microcontroller, a 10Meg resistor in parallel with the crystal and two 22pF caps to ground on both sides of the crystal. It only worked properly when connected per the datasheet. On the breadboard I tried to keep things as close and short as possible but I have a feeling you may run into more trouble with solderless breadboard when using say an 8Mhz crystal. But I could be wrong on that, I never actually tried it.


Joined Jun 29, 2019
I suggest also reading silicon erreata documents before laying out your design. Last year i had unpleasant surprise when i readed from errata sheet one of dspic33 that on-chip comparators "may work or may not (probably not)". The PCB was already laid out but not ordered yet, luckily.

Deleted member 115935

Joined Dec 31, 1969
Reading any data sheet,
start at the front, which has a general discussion
ignore the register maps, ignore most of the electrical characteristics, apart form may be max voltages and the package size.
then check how you program it, JTAG , ISP or what .

If your a hardware engineer, you now will look at differnt things compared to a software engineer,
As a rough example, he hardware engineer will not worry to much about what compiler you need to us, a software engineer will not worry to much about how much current the thing takes.


Joined Sep 22, 2020
It might sound lazy, but I always try to find a working "blinking light" sample code.

You'll quickly get a feel for I/O, a working oscillator configuration, and a quick way to check your hardware.

You will see what minimum headers you need, config, ect...

From there you can try different peripherals from a point that you know is working, focusing on one section at a time.

The first peripheral that I recommend is UART, because it is pure gold when debugging