Building an Embedded System, Part 1: Choosing a Microcontroller

For some time now I have been entertaining the idea of building an embedded system from scratch. The application I built this system around is a self-balancing robot. The idea is simple and is inspired by the modern day Segway, there is essentially an IMU (inertial measurement unit) on board of the robot that measures an angle of tilt, if any deviation is measured from the upright position then the necessary torque action is applied by the motors to counteract. However, the application of the proposed feedback control system is mathematically intensive, and I go in great detail about that in a different post here if the reader is interested.

In this article and ones to follow I will solely discuss the hardware/software application. The first step is choosing a microcontroller that satisfies the specific requirements of the application. Those requirements will include I/O, processing speed, and sufficient memory (RAM and flash). I found it extremely useful to draw a hardware block diagram which provides a great overview of the system.

In my application as shown above, I needed multiple GPIOs that can perform special functions such as an I2C, UART and SPI, I also needed 10 GPIOs that controlled LEDs, buttons and sent control signals. Understanding these preliminary system hardware interface requirements really helped me get a clearer picture of what kind of microcontroller I needed.

Software Architecture

The next step would be assessing the software architecture requirements. The processing power needed is heavily determined by the software. The complexity and nature of the algorithms determine whether you choose an 8MHz 8051 microcontroller or a 1.4 GHz GPU such as the Jetson Nano. Some clarifying questions I asked myself were:

·        Do any of my algorithms involve floating point mathematics?

·        Do I have any high frequency control loops?

·        If there are sensors, how mathematically intensive are the filtering algorithms if any are used?

Questions such as the ones listed above are critical in narrowing down your choices. Some other system constraints will need to be estimated such as how long/often your loop needs to run, this helped me determine the frequency requirements of my microcontroller.

Data Architecture

After answering all the questions proposed above and with the help of data from step 1, I was ready to ponder on the architecture of my microcontroller. The data width is important and also application dependent. There are some tradeoffs that are made when choosing an architecture, some questions that helped me narrow it down were:

·        Can my application get away with an 8-bit MCU?

·        Would a 16 bit or 32-bit Arm core be a better solution?

·        Would an 8 bit be a problem in the future if I were to add certain features?

The tradeoffs between choosing an 8-bit microcontroller as opposed to a 16-bit or anything larger is that an MCU with a wider data bus enjoys faster operations and usually contains more features giving it that higher performance edge. It is also typically more power efficient. Code size is significantly reduced the wider the data bus architecture is, which greatly impacts the cycles needed to perform tasks. In a 32-bit ecosystem, more data can be handled at once which reduces the amount of cycles, as opposed to an 8-bit microcontroller. The downside of choosing a 32-bit MCU is that an 8-bit costs less (recently 32-bit MCU prices have been very inexpensive). However, the main downside to a 32-bit MCU can be the layers of abstraction that put a barrier between you and the silicon. On an 8-bit there is less complexity due to lesser features, and where “bit-banging” is more prevalent (using software to implement hardware features). There is more of an educational experience when using an 8-bit MCU, note however that in today’s market with increasingly complex technology, 32-bit development skills are a must.

Memory

In this step I felt I was ready to ask some questions pertaining to memory requirements. Flash and RAM are crucial components of a microcontroller. It would be unfortunate to run out of program memory or variable space, it is very easy to build around a microcontroller only to find out at the end of the design that you either ran out of memory or you don’t have enough to add features in the future. Its fairly easy for an engineer to estimate program/variable memory requirements and it is better to give yourself more space and then change to a different version in the microcontroller family later on as you see fit. In my application i wanted to challenge myself, so I decided to restrict my program to a few kilobytes.

Power Consumption

Power consumption plays a huge part in selecting a microcontroller. The more processing power and features an MCU has, the more power it will generally consume. Depending on how you will power your system, your decision may vary. Most embedded systems are powered by batteries and that is why power consumption is essential. A lot of microcontrollers have amazing battery saving features such as putting certain peripherals in sleep mode when they aren’t being used which makes them really power efficient. But overall, you have to analyze your system for the components that will consume the most power such as motors (in my case).

For my application I chose the Atmega328p, it is an 8-bit AVR microcontroller that has a maximum operating frequency of 20MHz. It also contains 32KB of flash memory and 2KB of SRAM which is perfect for my needs. It contains 23 GPIO pins some of which have the special functions I require such SPI, I2C and UART. It also contains 3 timers, 2 of which are 8-bit timers and a single 16-bit timer. Its operating voltage is 1.8 – 5.5 volts which is a great range in case I would like to save some power by operating it at a lower voltage.

In this article I discussed the first steps I took to build an embedded system, in particular choosing a microcontroller. I elaborated on how the selection of an MCU is dependent on multiple crucial factors such as hardware interface requirements, software architecture requirements, data width architecture, pinpointing memory needs and power consumption. In future articles I will discuss the rest of my approach to building this embedded system. Thank you for reading and I hope this was helpful.