This section goes through the first part of the selection process -choosing a suitable architecture/family for the MCU, and a vendor capable of delivering it.

Just like any engineering process, the process starts with listing our functional & non-functional requirements, constraints and assigning priorities to them. In our case, this was relatively quick.

From the above, it was clear that either ARM Cortex M or RISC-Vwould be an ideal choice. x86 would be too bulky, while other architectures were too cryptic (from our point of view and research).

Both the above architectures were based on RISC principles (Reduced Instruction Set Computing), which is opposed to CISC (Complex Instruction Set Computing) principles commonly found in high-performance consumer devices (such as laptops, phones, tablets etc.). At our level, both ARM Cortex M and RISC-V provided similar capabilities, and it was difficult to choose between the two.

Finally we settled on ARM Cortex M due to its superior stability, support, maturity of tools etc. RISC-V was too volatile to bet on, and the vendors such as Espressif who did have some stability and reputation were out of the equation. However, we will still consider RISC-V for future designs.

The next step was to choose a vendor. This was a fairly quick step as we had a clear idea of what we wanted, and most vendors make it easy to filter through their MCUs based on one's requirements. We settled on STMicroelectronics (coloquially known as ST and STM32) due to their support, availability and our familiarity with their SDK.

NXP, Nordic and Renesas were all considered as vendors but discarded for the following reasons -

• Renesas was not friendly for small-medium developers/companies, and had a disappointing SDK. They not support all the features of the processor as given in the datasheet, or have proper support for Clang or GCC, the latter of which we intend to use.
  The only reason for considering it in the first place was its usage in the Arduino UNO R4, but we quickly discovered that it was not a good fit for us.
• Nordic was a strong contender, but we simply did not want to entangle with the Zephyr Project, which was part of their default SDK. Our past experience with Zephyr for projects was poor, and the overhead of Zephyr binaries did not do anything to help their case.
  Perhaps in the future, we will consider Zephyr but it was not something we wanted to deal with now.
• NXP was the most promising contender to ST. They had not strong demerits, but we had greater familiarity with ST, and felt like the STM32Cube framework was a tad easier to work with. We will consider using NXP in our future designs to prevent dependance on a single vendor.

Yet another reason to go with ST was due to Ardupilot Support. This becomes an even more important point in the next section when we choose an MCU. Ardupilot has almost exclusive support for STM32 MCUs, and our experience from their forums , they were generally averse to other vendors. We didn't intend for Ardupilot support to be a hard constraint, but it was still a factor to consider and a good-to-have capability.

Having chosen STMicroelectronics as our vendor, the next was to choose a suitable MCU for our needs. Fortunately, ST provides the STM32CubeMX software for this as part of their STM32 Cube framework.

This was a simple process - using the filters to communicate our requirements to the tool and selecting the best option from the given results -

Apart from the requirements listed in the previous section, we added the following filters -

• The chip must be active, i.e. not discontinued/NRND (not recommended for new designs).
• ≥ 1M Flash, since this was the minimum requirement for Ardupilot[1] (if we ever decide to port it) and was a good amount to ensure expandability in the future.
• ≥ 128K RAM, as this was the lowest amount that was atleast 10% of the storage, which was required to make the Flash productive.

The list was now a manageable size and we could manually look through the remaining options to find the best. We found the STM32F417VG series (single-core ARM Cortex M4) seemed to be a good compromise between cost, performance, IO and size.

Before this, we had considered the STM32F411CE, as it was already available on the inexpensive STM32 Blackpill boards sold by WeACT studio and we had prior experience with it. This was quickly dismissed because of its insufficent IO capability. We had also considered using the ARM Cortex M7, but realized it might be unnecessarily performant (and consequently, power-hungry) for a compact controller like ours.

The STM32F417 possesses the following features in terms of performance -

• ARM Cortex M4 core clocked at upto 168 MHz
• Hardware 32-bit FPU (Floating Point Unit)
• Dedicated Cryptographic Unit (for hashing, AES, etc.)
• Random number generator
• Dedicated CRC (Cyclic Redundancy Checker) Unit
• NVIC, DMA and other peripherals

And the following in terms of IO -

• ×2 CAN ports (×1 used)
• ×3 I2C ports (×2 used)
• ×3 SPI ports (×3 used)
• ×6 UART ports (×5 used)
• ×2 USB ports (×1 used)
• ×1 SDIO port (×1 used)
• ×1 Ethernet (not used)
• ×1 FSMC (not used yet)
• ×1 FSMC (not used yet)
• ×38 ADC channels (×8 used)
• ×2 DAC channels (×1 used)

This section walks through the process of designing an evaluation board for the STM32F417VGT6, which is the next step after selecting the MCU. It would have been slightly faster (and affordable) to buy a pre-existing evaluation board, but since one was not easily available (and we would have to design our own board anyway), we decided to design it ourselves and get it manufactuerd.

The final board, (major components labelled), looks as follows -

The evaluation board was designed to be reusable beyond the scope of this project alone, but still not be too generalized. Keeping this in mind, let us look at the key features of the board, and how they enable us to use the features of the MCU -

• Dedicated CP2102 USB-UART Bridge (from Silicon Labs) for Serial Communication.
• ×2 USB-C ports with USB 2.0 full speed and surge protection.
• SWD debugging port with ESD protection and surge protection.
• Dedicated Boot and Reset buttons.
• Built-in micro SD Card slot.
• Dedicated 24 MHz crystal (for High-Speed Oscillator).
• Power selection jumpers for USB 1, USB 2, and external (regulated & unregulated) power

Starting with the USB-C, this was chosen to keep the board future-proof. As of writing this blog (Q1 2025), Micro-USB, USB-A, and other USB ports are on their way out. USB-C aims to combine the features and benefits of all the standards whilst also providing superior reliability, power delivery and most importantly - reversibility.

The CP2102 chip was added to act as a simple and reliable method of communication with the flight controller. The MCU already has a USB port which could function as a virtual com port (VCP), but the firmware and operation was fairly complex with a lot of moving parts. This made it a bad fit for a reliable communication stream that is required for debugging, critical messaging etc. It could still be used to flash firmware or perform other tasks, but all forms of critical communication was better assigned to a hardware UART port, where the number of moving parts (and therefore risk of failure) was lower.

The remaining features are self-explanatory when considering the capabilities of the MCU and final flight controller, making them necessary for thorough evaluation of the MCU.

The STM32F417VGT7 has emerged as a suitable choice for our nano flight controller, offering an acceptable compromise between performance, IO, size and cost. With this selection finalized, the next step involves designing evaluation boards for the sensors and writing the firmware.

The next step is to procure the various sensor breakouts and write the drivers to run them, along with testing everything using the F4 evaluation board shown in this post.

Through this blog, we hope to build credibility with our community by transparently sharing our design and engineering process. If you have any thoughts or suggestions, you can share them with us at aerowint.com/contact, or write to our founders directly at aditya@aerowint.com or milind@aerowint.com.

[1] https://ardupilot.org/dev/docs/porting.html