From 0 to STM32

The building blocks of IoT

Nowadays, we are surrounded by smart objects capable to do incredible things. These objects, known as Smart Things, are now able to communicate over different wired and wireless communication channels. The obvious consequence is that these objects are able to get and to push data through the Internet: this phenomenon, this network of Smart Things, is commonly known as the Internet of Things or IoT.
The spreading of the IoT is substantially due to two main con-causes:

• the evolution of Microcontrollers which are increasing their performances while their price is decreasing;
• the diffusion of open source which today is providing us high-quality compilers, debuggers, and embedded libraries completely for free.

What is a Microcontroller?

A Microcontroller unit or (MCU) is a complete computer system integrated in a single small chip.

This definition can confuse an inexperienced user who is imagining a computer like a big metal chassis connected to a screen, a mouse and a keyboard. Actually, the base concept of a computer is the ensemble of a processor or CPU connected to one or more memories which can be also interfaced to different I/O peripherals through a communication bus.

An MCU perfectly matches this concept but its peripherals are quite different from keyboards, VGA displays, mouses and so on. Rather, they are simple I/O ports, timers, Analog to Digital converters, or standard communication peripherals like the Universal Asynchronous Receiver Transmitter or UART which is the peripheral used to implement the famous RS232 (see Fig.1).

All these things (and much more) are embedded together in a single chip and this is the reason why often professional refers to MCUs as Embedded Systems.

The difference between CPU and MCU

In the past years, the semiconductor industry has evolved so much that today we have a wide spectrum of electronic devices and a lot of variants. Hence, it is uneasy to define unambiguous groups of computational devices. For example, in the beginning, the Processing Unit was often an ensemble of chips interconnected each other: the whole ensemble of chips and interconnections was often indicated as Central Processing Unit (CPU). With the evolution of technology, they started to create small CPU which had the peculiarity to be all integrated into a small chip so they were called Microprocessor Unit (MPU).

Nowadays, is quite difficult to distinguish between MPU and CPU: we indistinctly call them CPU or Microprocessor or Application Core. Anyway, we can assert that there is still a big difference between an MCU (microcontroller) and a CPU (application core).

The first difference is in the concept behind the two units:

• An application core (CPU) is a chip designed to compute a large amount of operation (usually complex) but it does not embedded memories (except small caches) nor buses and peripherals.
• A microcontroller (MCU) is a chip designed to be a standalone device easy to be integrated in small things even if it has reduced performances in comparison to an application core. It usually embeds one or more RAM memories, one or more flash memories and a series of peripherals like timers, communication dedicated peripherals, converters and so on.

From this perspective, we can assert that:

a MCU has a CPU inside joint to a volatile memory (RAM), a non-volatile memory (NVM) which usually is a Flash Memory and some peripherals.

The second difference is related to the previous statement: since they are designed for different purposes, the performances are quite different.

• A CPU usually has a clock frequency in the order of Giga-Hertz, is interfaced to an external RAM of Giga-Bytes and external SSD or HDD of hundreds of Giga-Bytes. In some cases, it also integrates a GPU (Graphics Processing Unit) or dedicated computational units. Sometimes it integrates a RAM controller, but nothing else. Controllers like SATA, Ethernet usually are external to the chip.
• An MCU instead has clock frequency in the order of dozens or hundreds of Mega-Hertz, embeds a RAM which rarely reaches 100 kB and an NVM which rarely reaches 1 MB. It embeds peripherals and interfaces and in case of high-end MCU often integrates also the Ethernet controller.

a MCU usually does not exhibit extreme performances in term of computational power or RAM/storage capability. On the other hand, a CPU has a larger power consumption and is hard to be enclosed in small sized PCBs.

The ARM Cortex architecture

ARM?

If this is not the first time you are reading about embedded systems, you have for sure heard about ARM or ARM Cortex. There is often a little bit of confusion about this point so we are going to spend a few words about that.

ARM, which originally stood for Acorn RISC Machine, was the name of an architecture of a RISC (Reduced Instruction Set Computer) machine. The architecture is a “set of rules and methods that describes the functionality, organization, and implementation of computer systems”, while a computer chip is the physical implementation of an architecture. And so was the Acorn RISC Machine: a computer architecture. The ARM itself was so interesting in term of design and power consumption that people behind this idea started to implement more architectures and ARM became a brand.

Nowadays, ARM designs architectures which are largely used in most of the product we are using daily.

ARM itself does not produce chips. It designs architectures selling the license to use its Intellectual Properties. Many semiconductor companies buy this licence to produce their own chips.

The STM32 from STMicroelectronics is an example of a chip which is based on an ARM architecture but produced by a semiconductor company which is ST. ST is not the only one to do this: also Qualcomm, Apple, Texas Instrument, Microchip, Infineon and a lot of other companies uses the ARM architectures.

Cortex: M, A, and R

There are mainly three interesting architectures from ARM which are commonly used and well know:

1. ARM Cortex-M
2. ARM Cortex-A
3. ARM Cortex-R

Cortex-M

This architecture is designed to have the smallest and lowest power Cortex processor. This kind of processors are optimized for deterministic and real-time embedded processing: so, in this case, M stands for Microcontroller.

We are talking about 32-bit MCUs with a clock frequency in a range of 24-400 megahertz, embedded flash up to a couple of megabytes and embedded SRAM up to hundreds of kilobytes. Cortex-M is the name of a family of architectures which includes M0, M0+, M3, M4, M7 and now also M23 and M33.

The ARM Cortex-M architecture is suitable for all these applications which require to deal with hardware and oriented to low-power.

Cortex-A

This architecture is designed to reach the highest performance levels. This kind of processor is optimized for application: so, in this case, A stands for Application.

We are talking about 64/32-bit application core with a clock frequency of gigahertz, which does not embed a flash memory nor a RAM. Cortex-A is the name of a family of architectures which includes A5, A7, A32, A35, A8, A9, A53, A55, A15, A17, A57, A72, A73, and A75.

The Cortex-A series processors have been developed to run some architecture extensions like TrustZone, big.LITTLE and Floating Point Architecture.

Cortex-R

This architecture is designed for hard real-time applications. This kind of processors offer high-performance computing solutions for embedded systems where reliability, high availability, fault tolerance and/or deterministic real-time responses are needed: in this case R strands for Real-time

Usually, a Cortex-R is an MCU where two cores execute the same code and an external unit checks step by step the coherency between the two chips. This mode is known as Lockstep.

Cortex-R is the name of a family of architectures which includes R4, R5, R7, R8, and R52.

Introducing the STM32

STM32 is a wide family of ARM Cortex-M based 32-bit microcontrollers by STMicroelectronics. The STM32 are grouped into subfamilies and each subfamily is based on a specific Cortex-M architecture and has its own set of peripherals. With hundreds of different MCUs, the STM32 family is continuously expanding, but the question is: why so much different MCUs?

The answer is quite simple: each MCUs has different sizes in term of flash and RAM memories, clock frequency, pin number, and chip package. Even more, each chip has different peripherals and in different quantity. This strategy offers the chance to choose an MCU which is very close to the user needs.

Subfamilies

STM32 MCUs have a name made of letters and numbers in form of STM32XNMMOO whereas X is a letter and NMM are three number and OO are two letters. As example, we have STM32F303VC, STM32L476ZG, STM32F401RE, STM32F407VG and so on. The subfamilies are identified by X and N, so in our examples subfamilies are F3, L4, F4 and (again) F4.

The first big distinction can be done is related to the X letter. Currently, we have three lines: the F-line, the L-line, and the H-line.

• The F-line is the first series of STM32 MCUs. Currently it groups six subfamilies STM32F0, STM32F1, STM32F2, STM32F3, STM32F4 and STM32F7.
• The L-line is the low power series of STM32 MCUs. Currently, it groups three subfamilies STM32L0, STM32L1, and STM32L4.
• The H-line has been freshly introduced and is a very high performances series of 32-bit MCUs. Currently, it includes only the STM32H7 subfamily.

Every STM32 offers a large set of peripherals and all of them offer a complete configurable clock tree with internal PLLs, a multiple channel DMA, Timers, Serial-wire debug, ADC, USART, SPI, I2C, and RTC. What makes the difference between each microcontroller is the quantity and the characteristics of these peripherals. For example, an STM32L4 which is oriented to low-power has a special low power timer as well as the MSI which is a multi-speed internal PLL having low power consumption. STM32F3 instead has a special timer which offers up to six channels and its negate: this kind of timer is oriented to full bridge control. More, STM32F373 is equipped with a 16-bit ADC Sigma Delta while usually, STM32 offers a 12-bit ADC.

Another difference is the availability of specific peripherals, for example, certain STM32 has a larger number of independent timers or USART. So, choosing the right STM32 is something which definitely depends on the application.

Of course, each sub-family offers also different performances in term of clock speed, RAM and flash sizes. Even more, each sub-family usually has some specific peripherals which make it unique. The next tables are meant to be a non-exhaustive summary of the main differences between sub-families.

STM32Fx series

The F-line offers a wide spectrum of solutions in term of performances and peripherals.

STM32Lx series

The L-line is much more oriented to low-power: every STM32Lx has the Dynamic Voltage Scaling feature, special low power clock sources, Advanced RTC.

These MCUs can operate in different modes and this influences the current consumption.

Current consumption reference values for STM32L0 are:

• Dynamic run mode: down to 87 μA/MHz
• Ultra-low-power mode + full RAM + low power timer: 440 nA (16 wakeup lines)
• Ultra-low-power mode + backup register: 250 nA (3 wakeup pins)
• Wake-up time: 3.5 µs

Current consumption reference values for STM32L1 are:

• Ultra-low-power mode: 280 nA with backup registers (3 wakeup pins)
• Ultra-low-power mode + RTC: 900 nA with backup registers (3 wakeup pins)
• Low-power run mode: down to 9 μA
• Dynamic run mode: down to 177 μA/MHz

Current consumption reference values for STM32L4 are:

• Ultra-low-power mode: 8 nA with backup registers without real-time clock (5 wakeup pins)
• Ultra-low-power mode + RTC: 200 nA with backup registers (5 wakeup pins)
• Ultra-low-power mode + 16 Kbytes of RAM: 200 nA
• Ultra-low-power mode + 16 Kbytes of RAM + RTC: 450 nA
• Dynamic run mode: down to 36 μA/MHz
• Wake-up time: 5 μs

STM32Hx series

This sub-family is the newcomer series of high performances microcontroller. As far as known, this subfamily is an ARM Cortex-M7 MCU having a clock frequency up to 400MHz. All the STM32H are equipped with USB 2.0 OTG FS/HS, SDMMC, USART, SPI, I2C, HDMI-CEC, Comparator, Op-AMP, I2S, SAI, 12-bit DAC, SPDIF-RX, LCD TFT controller, Chrom-ART, Crypto option, TRNG, DFSDM, 16/32-bit timers and 14-bit ADC up to 2 Msps.

Personal notes, comparisons, misconceptions

Looking at previous tables it should be clear the range of clock frequencies, RAM and flash sizes we are talking about. During my trip in the embedded world, I often heard about the comparison between STM32 and Arduino or Arduino and Raspberry and so on. This paragraph aims to answer some frequently asked questions and to point out misconceptions.

STM32 or Arduino, which is better?

This question does not make any sense. This question sounds like “Intel i7 or HP Compaq, which is better?” STM32 is a microcontroller, Arduino is a series of open source development boards and, like remark, the Arduino STAR Otto is equipped with the STM32F469.

Trying to decode this very frequently asked question, usually, people which is dealing with Arduino uses Arduino Uno or Arduino Mega because it is very easy to find ready to use libraries for these development board. Arduino UNO has on board an ATmega328P which is an 8-bit AVR MCU from Microchip (previous Atmel) with clock speed up to 20 MHz, 32kB of flash and 2kB of RAM. Well, in term of performances, of course, is better to choose an STM32 which offer higher MIPS (millions of instructions per second), a larger set of peripherals and VLSI chips. On the other hand, a beginner without any knowledge of electronics usually prefers to use Arduino which is easy to use thanks to black box paradigm: the Arduino APIs usually tend to hide problems to the user in exchange of a lack of performance and\or versatility.

My personal opinion is that this is a good way to help hobbyists or young people to approach embedded systems but is not a good solution for an engineer or a professional in general which should tackle and solve the problems.

Another consideration which must be done is that performances are not the most important thing. In certain applications a small microcontroller is good enough to do what you have to do: in these cases maybe we should consider the time required to develop a product or the price of the MCU itself or even the power consumption of the whole system. For example, if the application is a small sensor node which has to get environmental information once per day and which is powered by a small battery, a low-power MCU must be considered.

STM32 or Raspberry Pi?

Again, this question does not make any sense. STM32 is a microcontroller, Raspberry Pi is a series of application development boards. Even more, Raspberry Pi boards have a different target: application! The Raspberry Pi 3 equips a Broadcom BCM2837 which is a Quad Core 1.2GHz 64-bit ARM Cortex-A53. It is unusual to compare a Cortex-A with a Cortex-M as well as is unusual compare an 8-bit with a 32-bit microcontroller.

A Cortex-A usually runs Linux or other complex OSes not particularly oriented to real-time applications but usually oriented to drive LCD and perform a large amount of operation required by graphics or data filtering. A Cortex-M usually runs an RTOS (Real-Time Operating System) and is oriented to deal with hardware and to create real-time solutions.

Concluding the choice depends on the final application. Just a note, we have often mentioned the term “real-time”: we will point out what this means in the following tutorial.

There is plenty of ARM Cortex-M based MCUs: why STM32?

I started to use microcontrollers in 2013 and I wasn’t what you would commonly name a geek. I started with STM32F3 and after some initial difficulty and a couple of months, I was able to use it in daily applications. After a year I was so enthusiast of this new tool that I started to produce video and tutorial on this argument. But I am a curious guy, so I started to explore also alternatives: I had the chance to use Arduino Uno, Arduino Mega, Arduino Due, Freescale MK20 and MK64, Infineon XMC1100, Texas TIVA C TM4123G, STMicroelectronics SPC560D, almost every STM32 (except for STM32H7, but is matter of time) and some other non-MCU programmable devices.

Well, I have to say (my personal opinion here), the documentation of STM32 is the most accurate I have ever seen. I also love the internal peripherals which STM32 offers: the interesting thing is that peripherals usually do not change in the whole sub-family and that certain sub-families have the same kind of peripheral. To better explain this let me do an example: there are two versions of the SPI. The STM32F1, STM32F2, STM32F4, STM32L0 and STM32L1  have the first version STM32F0, STM32F3, STM32F7 and STM32F7 have the second version. In other brands, the vendor has redesigned the peripherals on each MCU. The design of STM32 peripherals reduces the development time, especially in case we need to port our application to another micro.

Conversely, I am not a great fan of STM32 software development tools so I empathize who prefers an easier to use solution. We will discuss software development tools later in this article, so let us suspend this point for a while.

STM32 Development tools

To help developers to get started with STM32, STMicroelectronics has started to produce and sell some development kits. When I started to develop with STM32, there were five or four development kits: times change and today there is a multitude of development boards.

The highlights of this hardware are:

• Development board are extremely cheap (usually 10$ or 20$, in case of complex boards with displays or similar up to 70$);
• Each board has an embed on-chip debugger;
• There are a lot of official and non-official resources (PLAY Embedded is an example of non-official resource);
• The STM32 community is growing thanks to these development boards.

Official development kits

Generally, who wants to create a fine embedded product creates its own board equipping it with one or more MCUs, external peripherals, and all the required circuitry. These custom board usually are designed to be enclosed in a nice to look container. This process often requires some intermediate steps:

1. Create a series of requirement starting from the initial idea;
2. Design the hardware starting from these requirements;
3. Create a schematic drawing a printed circuit board (PCB) and produce a small number of prototypes;
4. Start to develop a firmware for the onboard MCU
5. Perform some tests to ensure that the hardware design matches the final requirement;
6. If the product does not match requirements or we the firmware development has shown a design leak go back to point 2; if requirements and idea must be changed go back to point 1. Repeat the loop until the product reaches the expected quality

This loop, known as product engineering, requires a non-negligible amount of time and money. The aim of the development kits we are going to introduce is to reduce the time of prototyping. This can be achieved providing versatile hardware which is very similar to the final version of the product: in this way, it is possible to develop firmware before to have a prototype and (maybe) discover design leaks before to start the PCB production.

STM32 board can be distinguished in two main groups: STM32 Discovery kit and STM32 Nucleo. STM32 are also used in other evaluation kits known as ST Evaluation Board: we will not discuss them in this article.

STM32 Discovery Kit

The STM32 Discovery kits are development boards usually green-colored which are designed to cover a specific application field thus are equipped with additional devices like MEMS, Displays, special connectors and so on. For example, STM32F3 Discovery is a development board which has an onboard an STM32F303 plus LGD320 which is a 3-axis gyroscope and LIS303DLHC which is a 3-axis magnetometer and 3-axis accelerometer. STM32F7 Discovery has a Display, Ethernet plug, camera expander, microphones, joystick ad SD card reader.

There are dozen of discovery kit and all of them are also equipped with an ST-Link on-chip debugger which is very useful while developing our code.

STM32 Nucleo

STM32 Nucleo is a development board series based on the concept of abstraction in a way we are going to explain. There are three main lines of STM32 Nucleo:

1. STM32 Nucleo-32 which is equipped with the Arduino Nano connector;
2. STM32 Nucleo-64 which is equipped with the Arduino Uno Rev-3 connector plus a proprietary connector named ST Morpho;
3. STM32 Nucleo-144 which is equipped with the Arduino Uno Rev-3 connector plus a proprietary connector named ST Zio.

The numbers (32, 64 and 144) represent the number of PIN of the onboard MCU. The interesting part is that every Nucleo is PIN compatible with other Nucleo boards belonging to the same line. So, for example, STM32 Nucleo-64 F401RE is pin compatible with STM32 Nucleo-64 F303RE, STM32 Nucleo-64 L476RG and so on. The same is for Nucleo-32 and Nucleo-144. This is possible because all the MCU equipped on STM32 Nucleo boards are PIN compatible with each other and actually the PCB of every Nucleo board is actually the same regardless of the equipped MCU: minimal differences are resolved using some PCB solder bridges.

Every Nucleo (even Nucleo-32) are equipped with Embed ST-Link V2-1 and are ARM mbed Enabled. The price of these boards is around 10$ for Nucleo-32 and Nucleo-64 and around 20$ for Nucleo-144.

STM32 Nucleo can be also expanded stacking an STM32 Nucleo Expansion Board (also known as x-Nucleo) on it. These boards are external PCBs based on the Arduino Uno Rev3 connector and equipped with external devices like MEMS, Bluetooth Low Energy, Wi-Fi, and so on.

Documentation

We live in the era of user-friendly electronic stuff: we can set up and use an electronic device without reading any instruction manual. Newbie often thinks that programming embedded system is equally simple.

The biggest error you can do dealing with embedded system is to take information for granted. Deal with embedded systems is matter of logic: doing a wrong assertion you will invalidate the whole line of reasoning and, as final result, things will not work or will work in an unexpected manner.

There are many sources of information but the most important is the official documentation of the MCU. These documents are usually organized per argument and report all the information required to deal with hardware: it is always a good idea to keep an eye on them before and while we are developing.

Dealing with STM32 requires two (plus one) documents: the Reference Manual, the Datasheet and, if we are using an official development kit, the User Manual. These documents usually could be very large. We have not to read them all, but we will learn how to search it to get needed information.

Please, think about the environment before printing them.

The Reference Manual

This document, also abbreviated as RM, contains all the information about the core and the peripherals of our MCU. This includes information about registers and how they are mapped in memory, information about how to enable a certain peripheral and how to configure it, but also about where the code must be copied and how to start up the machine.

In the beginning, there was only one reference manual for each subfamily. So, there were the STM32F0 RM, STM32F1 RM, STM32F2 RM and so on. Evolving, the STM32 sub-families started to branch creating a difference of features inside the same sub-family: for example, while the original STM32F407 has a clock frequency up to 180 MHz, the newer STM32F401 has a clock frequency up to 84 MHz. This means different clock trees and thus different RMs. It is still true that usually, RM refers to a large group of MCUs belonging to the same sub-family.

To find the right RM for your MCU go on the ST website and write in the search box your MCU part number. For example, STM32 Nucleo-64 F401RE is equipped with STM32F401RE, so we have to search for STM32F401RE. In the search results, we will see a box containing the part number we have just looked for and the description of the item. Clicking on it we will reach the product page which contains information about that product and also a lot of technical documents: the RM is on the list.

Summarising:

The Reference Manual is a big document (hundreds or thousands of pages) describing the core and the peripherals of a MCU. If you need to find out how memory or register are organised or how a peripheral works this is the right document.

The RM is usually related to a sub-family of MCUs or to a large sub-set of it: you should expect that this document is shared between more MCUs.

The datasheet

The datasheet, also abbreviated as DS, contains all the electrical and mechanical information of the MCU like absolute maximal ratings, soldering information, available packages, flash and RAM sizes, core frequencies and pin map.

The datasheet is much more specific than RM and actually, there is one for each MCU. Anyway, even if an MCU is provided in different packages or with different Flash/RAM sizes, it is completely described by a single DS. For example, STM32F401RE and STM32F401CE are similar except for package: the first one is an LQFP 64, the second a UFQFPN 48 but they are described by the same DS. Actually, the same datasheet also fits the STM32F401xD which has different memory sizes.

The way to find the right DS is actually the same used for RM. Search for your MCU and on the product page, there will be an icon which says “Download Datasheet” (it is on top just below the name of the product). This document is shorter than RM but again I ask you to avoid printing it: this would be useless because these kinds of documents are often reviewed (you can see the revision number on the bottom of the page of ST documents).

Summarising:

The Datasheet is a shorter document (in comparison to RM) reporting all mechanical and electrical information about a specific MCU. If you need to find out how to solder a STM32 or how many Ampere/Volts is able to provide a IO pin this is the right document.

The DS is usually a document related to a specific MCU.

The user manual

The last document we need is the user manual, often abbreviated as UM. This document is related to the development board. ST offers a UM for every development board which contains information about the PCB (included the schematic) and additional information about onboard components.

If we need to search for it we need to look for the board: for example, if we are using STM32F3 discovery we have to search “STM32 Discovery” instead of “STM32F3” since the last search will return results about the MCU instead of the development kit. On the product page, in the technical documents, there could be more than a UM: download the one describing the hardware and not the “Getting Started with…”

Summarising:

The User Manual is an option document containing information about the PCB of a development board. If you need to understand how a LED or a button of your board is connected to the MCU this is the right document.

The UM is a document strictly related to a specific development board.

Drivers

STM32 development boards come with an embed on-chip debugger we are going to use in next articles while developing. To use it we need to install related drivers. Drivers come as standalone or attached to a very useful tool named STM32 ST-Link Utility. Go to the product page and download this software. This will require a registration to st.com.

Once you have installed it, connecting your development board and assuming you are using Windows, in the device manager you will see a new entry under USB Serial Bus Devices which is STLink Dongle.

If this does not happen, re-install the program forcing administration rights or comment on this article: maybe we can help you.

The steps required by this task are:

1. Search on Google “ST-Link Utility”;
2. Select the result from st.com;
3. Select get the software, accept the EULA and do the login/register to MyST;
4. Download and install software;
5. Connect your development board;
6. Open device manager to check if drivers have been installed correctly.

To make things clearer let’s take a look at the next short video.

Development with STM32

There are many tools and embedded libraries to develop with STM32. The official solution by ST is the STM32Cube. Another popular solution is ARM mbed for those development kit which is ARM mbed Enabled. There are other open source alternatives to develop with STM32 including ChibiOS which is clearly what we are going to use.

STM32Cube

This is an embedded library developed by ST to reduce the “ease developers’ life reducing development effort”. It contains demos, an HAL, libraries, middle-ware and ready to use demos.

Let me list some PROs and CONs. Please consider that some of them are based on my personal experience and are much more an opinion than a fact: take care of this before to read.

Pros

• Open source and free to use;
• It supports every specific feature of the hardware;
• It comes with a graphical configurator named STM32CubeMX which is very helpful to configure the MCU.
• It includes also support for external devices like displays, MEMS and so on;
• The code is actively maintained;
• There is a very large community which use it.
• Is the official embedded library: if you want to take part in the STM32 official community and require help, you should use it

Cons

• Each subfamily has a different STM32Cube library: this means would not be easy to change STM32 sub-family. Even more, each package is large hundreds of MBytes;
• ST does not provide a ready to use IDE but suggests some third party IDEs most of which are open source;
• The HAL is not enough versatile and doesn’t hide details not relevant for the user, for example to startup the machine there is a lot of lines of code in main;
• The style is not consistent and there are many code pattern for each function.

ARM mbed

This is an integrated on-line toolchain which allows you to easily get started with all that board which is marked as ARM mbed Enabled and this is true for most of the STM32 development board.

Pros

• Open source and free to use;
• Extremely easy to use and has an on-line IDE;
• There is code also for most of the STM32 Expansion Boards;
• The same code can be compiled for different MCUs.

Cons

• You have to compile your code in a browser while you are connected to the internet;
• The online IDE sometimes is slow and this depends also on user connectivity;
• Code is not always maintained;
• Cannot use debug features;
• The style is very inconsistent;
• Hides to much details and this often lead the user to mistake ease of use for mastery.

ChibiOS

This is a third party open source and free to use solution which comes with a ready to use IDE for Windows and a lot of demos. In my spare time, I am involved in the development of ChibiOS (STM32 part) since I love the idea behind this project and the care for details. But I will not fool you: even if we are trying to remove them, there are cons here too.

Pros

• Open source and free to use: it also includes a free commercial license;
• Comes with a very efficient RTOS a HAL and a ready to use IDE.
• Code is nimble and elegant;
• Almost every STM32 is supported, there is also community support for non-STM32 MCUs
• The same code can be compiled for different MCUs.
• The code is actively maintained;
• There is a large community which uses it.

Cons

• The ready to use IDE is not so user-friendly;
• There isn’t support for each x-Nucleo;
• Not every specific feature of the MCU is supported;
• Free support is completely voluntary;
• The documentation is oriented to professional and not particularly oriented to beginners.

Conclusive notes

In the next articles we will provide code examples for both STM32 Nucleo-64 F401RE and STM32 Discovery F3 Revision C. The idea is to provide code examples for two different MCUs in order to point out all the difference in term of code and help reader to understand how to write code which is easy to port between two different MCUs.

Both the boards are equipped with STLink V2-1 (this information is on the enclosure and in the UM). So, before to proceed to the next article, it is required:

• to download the documentation related to the development board and MCU you are going to use;
• install the STM32 ST-Link Utility and verify that drivers have been installed correctly.

Previous and next

This article is part of a series of articles which are meant to be tutorials. I have composed them to be read in sequence. Here the next article of this series:

• Developing on STM32: introducing ChibiStudio (Next)