Which microcontroller fits your cockpit project?

Start with the function, not the clock speed

First decide whether the module sends inputs to the simulator, shows telemetry, or does both. A button box needs switch handling and a supported input path. A radio OLED also needs real data, a message format, presentation rules and behaviour when the connection fails. A faster chip cannot provide a missing simulator interface.

Count buttons, encoders with their push switches, analogue axes, LEDs and displays separately. Reserve pins for I²C, SPI, USB and troubleshooting. Decide whether you want configurable firmware or your own sketch. The board selection basics explain these initial distinctions; this comparison goes further.

Classic Arduino boards and the R4 generation

UNO R3 and the classic Nano are useful for a first manageable build, with many examples written for their AVR architecture. Mega provides many more connections and four hardware UARTs, but still runs at 16 MHz. Leonardo and Micro have USB inside the ATmega32U4, making them interesting for custom USB-HID sketches.

D means digital connections and A analogue inputs. These are not independent sets of every possible function: the twelve analogue inputs on Leonardo/Micro are included in their 20 I/O. I²C, SPI and PWM share pins; classic Nano A6/A7 are analogue inputs only. Flash holds the program, SRAM its working data. Bootloaders and libraries consume some capacity.

UNO R4 Minima, UNO R4 WiFi and Nano R4 use RA4M1 rather than ATmega328P. Their memory and 48 MHz clock provide more room for displays, but AVR-specific code is not automatically compatible. An additional ESP32-S3 handles wireless tasks on UNO R4 WiFi; that does not turn the whole board into a conventional ESP32 development board. Nano Every is specified up to 20 MHz; the actual sketch clock also depends on the board package. Check libraries and build settings.

Nano names describe more than one architecture

The following Nano boards use 3.3 V logic. A connector that fits mechanically does not prove electrical interchangeability. Nano 33 IoT combines SAMD21 with a radio module, while BLE variants use nRF52840. Sense versions add sensors that an ordinary button box may not need.

Many offer familiar D0–D13 and A0–A7 positions, but ADC routing, internal pin use and USB support differ. On Nano RP2040 Connect, for example, not every analogue input goes directly to RP2040. Arduino currently marks this model End of Life. Existing boards remain usable, but check replacement availability before designing a new series around it.

Nano ESP32 specifically has 16 MB flash, 512 KB internal SRAM and 8 MB PSRAM. Additional PSRAM is not an equally fast substitute for every internal buffer. Nano Matter targets Thread/Matter networks, which do not automatically benefit a wired joystick. Similar dimensions do not mean shared firmware.

Where Zero, MKR, Due, GIGA and Portenta fit

Zero and many MKR boards, including MKR WiFi 1010, use SAMD21: 48 MHz, 256 KB flash, 32 KB SRAM and 3.3 V logic. Zero includes a debugger; MKR variants mainly differ in connectivity and available connections. Buy the interface you actually need rather than unused cellular or sensor features.

Due uses SAM3X8E at 84 MHz, with 512 KB flash, 96 KB SRAM, 54 digital and twelve analogue inputs. Its Mega-like shape does not change its 3.3 V logic. GIGA R1 WiFi offers STM32H747 cores at 480/240 MHz, 2 MB internal flash and 1 MB internal SRAM, plus 16 MB external flash and 8 MB SDRAM. Its 76 GPIO and display connectors suit larger instrument units, although pin functions still overlap.

Portenta H7 is intended for more demanding compact systems with appropriate carrier boards. More processing power also brings connector, power and software work. UNO WiFi Rev2 combines ATmega4809 with a radio module and differs from R3/R4. Nicla families specialise in sensing or vision, and Opta targets industrial control. UNO Q and VENTUNO Q combine Linux computing with microcontroller tasks. For four LEDs and an OLED they add unnecessary complexity; they become relevant when sensing, imaging or supervisory computing is an explicit requirement. This is a cockpit-focused selection, not a catalogue of every historical Arduino product.

Separate Blue Pill, Black Pill and Nucleo

Blue Pill and Black Pill are board names, not firmware compatibility guarantees. Read the complete chip marking and board revision. STM32F103C8 officially has 64 KB flash; reports of additional usable memory are not a sound basis for your parts list.

On Nucleo, USB capability in the target chip does not mean every USB socket connects directly to it. ST-LINK handles debugging and programming. Check the schematic, user USB connection and any external circuitry required. F4 suits custom controller firmware, G4 demanding analogue acquisition and timing tasks, and H7 larger data/display projects. Usable pins depend on the PCB, package and multiplexing.

FreeJoy supports its documented STM32F103 platform. An F411 Black Pill is not an interchangeable replacement. Some STM32 digital pins tolerate 5 V under specific conditions; that is not permission to apply it to analogue inputs or the entire board.

ESP32 versions differ where it matters

All the ESP32 boards considered here need appropriate 3.3 V signals. Flash capacity, PSRAM and exposed GPIO depend on the actual module. The table describes chips; order using the complete module designation, not just “ESP32”.

An original ESP32 connected through a USB-to-serial chip is not thereby a native USB joystick. S2/S3 provide configurable USB OTG, but HID still needs suitable firmware, board support and the correct connector. C3/C6 Serial/JTAG is a fixed USB function, not a freely configurable HID device controller. S3 combines useful memory, USB and wireless capabilities for mixed display projects.

A networked cockpit module must handle startup, Wi-Fi loss and stale data. Wireless connectivity does not replace a stable power supply. Some GPIO are reserved for boot configuration or flash; original ESP32 GPIO34–39 are input-only and have no internal pull-ups. Work from the actual board pinout.

OLED: when UNO is enough and ESP32 helps

A complete monochrome 128×64 framebuffer needs 128 × 64 ÷ 8 = 1024 bytes, already half of UNO R3's 2 KB SRAM. Variables, serial receive buffers, libraries and the stack also need space. Text-oriented or paged display libraries can reduce the buffer requirement.

Four LEDs and a few slowly changing values can fit UNO R3 perfectly well. The AI-assisted LED and OLED guide gives you a bounded first project. Several displays, larger fonts, menus, data processing or networking make ESP32-S3 or Nano ESP32 more attractive. One OLED alone is not a reason to replace a working board.

More MHz do not automatically speed up I²C. At 400 kHz, transferring 1024 bytes takes roughly 23 ms for data and acknowledgement bits alone, before other protocol and software overhead. Several displays share that time. Check refresh rates, address conflicts and possible SPI alternatives in the display guide.

USB device, joystick and simulator integration are separate checks

USB-C initially describes a connector. A COM port provides a serial data path. A HID joystick reports buttons and axes using an appropriate report descriptor. Keyboard HID and joystick HID are different functions; a supported keyboard library does not prove joystick-library compatibility.

On the original UNO R3, a separate ATmega16U2 provides the USB bridge. An ordinary ATmega328P sketch does not change that bridge's USB class. Replacing bridge firmware is a separate development task. Documented HID boards are often clearer for beginners. Native USB inputs also do not automatically receive telemetry. Follow the USB input guide through to simulator bindings.

UNO R4 WiFi normally routes USB through the ESP32-S3 bridge. The board can switch USB to RA4M1; HID support depends on the appropriate board package and library. Minima and WiFi therefore do not have an identical USB path.

Plan pins, axes and power realistically

An encoder usually needs two signal lines and possibly a third for its push switch. A matrix saves pins but needs suitable firmware and a plan to avoid unwanted multi-key detection. I/O expanders add connections while changing bus load and sampling time. Count usable simultaneous functions, not just solder pads.

A higher ADC bit count does not guarantee a steadier axis. Sensor quality, reference voltage, wiring, sampling and filtering determine actual results. Strong smoothing may delay response. Observe a stationary value and slow movement before comparing resolution. LEDs need current limiting, and larger loads need suitable drivers. A GPIO is not a supply for backlighting or motors. Use the power planning guide, including correct voltage for I²C pull-ups.

A concrete pin budget: eight individual buttons, three encoders with push switches and one I²C OLED require 8 + 3 × 3 + 2 = 19 signal lines without a matrix, plus power and ground. Mark them on the WeAct pinout or the ESP32-S3-DevKitC-1 v1.1 pinout. This DevKit has 44 header positions with 36 GPIO labels, not 36 unrestricted connections. GPIO19/20 serve USB when used, GPIO38 serves the RGB LED, and certain Octal memory modules reserve GPIO35–37 internally. Also allow for boot pins and debugging. For Blue Pill, follow its exact board revision and firmware pin plan.

Three projects to guide your decision

1. First learning panel: four LEDs, a small OLED, USB serial and sample data. An existing UNO R3 is a sensible choice. Upgrade when memory or pins actually become limiting.
2. Button box with axes: choose the documented FreeJoy platform or a board with suitable custom HID firmware. Check buttons, encoders, calibration and mapping in the operating system first.
3. Networked instrument unit: multiple values, menus and graphics headroom. Compare ESP32-S3/Nano ESP32 with suitable STM32 or GIGA hardware. Define the data source and display bus before purchasing.

Your first trial should prove one button, axis or displayed value. Record board revision, firmware, library version, pins and expected behaviour after restart or data loss. Successful compilation does not prove correct wiring or simulator response. Keep a working version before adding the next function so you can narrow down a failure.

Get help with a build others can understand

Cockpit Suite brings supported simulators and devices into a common software environment. Check the compatibility overview for the functions your setup can use. Prepared combinations simplify setup; a custom board still needs an appropriate documented data path.

You do not have to make every choice alone. Share your goal, board photo, pin plan and last working trial in the forum. We also help with 3D-printed enclosures, CNC router work and laser projects using LightBurn. We aim to answer the same day where possible; late questions may take longer. Cockpit Suite is a young project with available software. Practical experience from the European community and beyond helps us develop clearer, useful solutions together.

Plan your next step