A brief introduction to microcontrollers

A microcontroller is a general-purpose ISA-based machine developed to satisfy market needs: such a device includes one or more logic cores (embedded microprocessors) and a wide list of peripherals integrated on a single die. The idea is to have a fully functional PC motherboard condensed into a very compact device capable of executing fast calculations while consuming a minimal amount of energy. The business generated from low-power device development and production is a trending market and a new frontier of scientific research. These microcontrollers are designed to interface with other complex devices, acquire analogue/digital/frequential signals, control power components and so on: the possibilities are almost infinite. Microcontrollers do have some limitations: depending on the application to be developed, the right device has to be selected, considering that each uC family is optimized to fulfil a particular subset of tasks; for instance, some uCs are specifically developed for consumer electronics, others for the automotive industry, while some are strongly oriented towards data processing and parallel computation...in other words, to each his own.

Usually hardware implementation is pretty easy since they come as 'black boxes' which require just a bunch of components around (often only a few passives). Software complexity, instead, depends on the type of required application; driving LEDs is the so-called 'Hello World' program which is always given by the manufacturer as a starting point but other very demanding applications can be developed: we can drive a motor (from a very simple BLDC to a whole high-voltage power inverter), add connectivity to our product (CAN, SPI, Ethernet, Serial, I2C, WiFi and so on), control drones, pumps, relays and many other actuators, reaching very high accuracies too.

On the other hand, a microcontroller cannot perform tasks in a superfast way: if you need very high computational speed or you have to perform always the same operation indefinitely (or both), a microcontroller could not be the best solution: in that case, go for an FPGA, a DSP or an ASIC.

A microcontroller internally has at least one logic core, a clock distribution network, one or more GPIO managers (General Purpose Input Output controller) organized by port, a power supply manager which controls the power distribution network, an interrupt manager, a volatile memory and a permanent memory. A uC could contain no peripherals but today you will never find a device with zero peripherals inside since such a product would be totally out of the market; however, in that case, the communication should be completely managed at the software level, by exploiting some bit banging techniques (very interesting but inefficient and limiting).

The internal architecture and in particular the core architecture of a microcontroller family is often proprietary so it is difficult to know how it is implemented in a detailed way. Despite so, one can deduce it starting from the available documentation (in the datasheet there is always a principle scheme of the device, and the internal interconnections between the various subunits); moreover, for some widely used architectures, official websites are plenty of additional documentation: in any case, nobody will ever provide you with the HDL description of the core or the physical layout for obvious reasons, and, even if some didactic or research-oriented works are available for free, in this case, you should buy an efficient simulator (there are some free HDL simulators with many limitations i.e. you can't use IP or encrypted blocks) or an EDA tool which costs a lot.

So, to clarify, a microcontroller architecture (shorthand for 'core architecture') is a set of core features, related specifically to the core processor of the microcontroller itself: data access scheme (load-store, register-memory), memory management scheme (von Neumann, Harvard, mixed, dataflow ... architecture), data bus length (4, 8, 16 ... bits), ALU implementation (adder structure, integer multiplier topology, type of logical shifter ...), presence and eventually type of floating point unit, data parallelism (scalar, pipelined, vectorial, superscalar, simultaneous multithreading ...) type of ISA (RISC, CISC, VLIW ...), register file structure and so on: each architecture has its pros and cons.

Some architecture examples are shown below (remember that in many cases, especially for ARM, the same architecture can have different implementations and variants so, in the table, only the most common versions are shown):

Another important concept is the 'family' one: in the previous paragraph we talked about the architecture which is strictly related to RTL design choices and distant from the layout design of the uC; a microcontroller family, instead, groups all those microcontrollers using similar architectures and similar set of rules in the physical implementation: in both cases, a new family can only be developed accordingly to new improvements and/or discoveries in the RTL design field and to new technologies improving the physical design.

If after the first analysis, you concluded that your application can be developed with a uC, then you have to find the right one. Note that today, in some fields, you can't pick randomly the device: there are some important technical aspects to be considered when choosing the hardware but some of the most important come from safety, reliability or standard compliance requirements; you will choose one uC rather than an equivalent one only based on the said properties, even if they are technically similar.

Following the selection of the uC, the development environment must be set up: it consists of a text editor, a software toolchain (compiler and linker), a programmer and a debugger (the last two often come in a single packaged solution). Also in this case, not all the compilers are equivalent: even if they all do the job, some of them include additional features (like MISRA C compliance, additional code speedup, memory usage optimization). The more they are paid, the better they are.

Finally, when the project becomes very complex, it is possible to use configurators (STCube, MCUXpresso, TASKING PinMapper, SYSCONFIG) for the low-level firmware and model-based software (Simulink, Stateflow) for the high-level applicative. The first ones help the designer to set the microcontroller environment (pins direction, driving mode and pull management, peripherals settings, clock distribution network setup, device mode setup and so on); the second ones instead help the high-level software engineer or the control engineer to easily develop the system without the need of writing the code line by line: in many cases, such software provides embedded coders which extract C code directly from a model.