Legacy AVR-based boards and why they are incompatible with CRSF for Arduino

[ZZ-Cat]

Okay here we go...

I get asked every now and again by a handful of you now about adding older AVR-based boards despite there being numerous warnings and notices telling you that it isn't possible.
A wee while ago, I had a post here talking about investigating why AVR based boards aren't compatible with CRSF for Arduino, and today I have done that case study.

Set-up

• Branch: AVR-Incompatibility-Case-Study
• Board: Arduino UNO R3
• Configuration: Default configuration that comes with CFA_Config.hpp as this is the same configuration that my QC uses.
• Firmware: platformio/main.cpp
• Version: v2025.10.26 (2025-10-26 — Rolling release update)

Environment

CRSF for Arduino was containerised using Docker, as this is my primary development environment for CFA. The only changes that were made was what was required to get CFA to compile for the Uno R3 target. Nothing else was changed.

The command issued was:

 pio check -e defect_detector_clangtidy --fail-on-defect=low --fail-on-defect=medium --fail-on-defect=high && pio check -e defect_detector_cppcheck --fail-on-defect=low --fail-on-defect=medium --fail-on-defect=high && pio run -e development

...which is the same command issued in my QC continuous integration scripts.

Results

Using the command above, this gave the following output:

Checking defect_detector_clangtidy > clangtidy (board: uno; platform: atmelavr@5.1.0; framework: arduino)
-------------------------------------------------------------------------------------------------------------------------------------------------------
No defects found
============================================================= [PASSED] Took 0.03 seconds =============================================================

Environment                Tool       Status    Duration
-------------------------  ---------  --------  ------------
defect_detector_clangtidy  clangtidy  PASSED    00:00:00.033
============================================================= 1 succeeded in 00:00:00.033 =============================================================
Checking defect_detector_cppcheck > cppcheck (board: uno; platform: atmelavr@5.1.0; framework: arduino)
-------------------------------------------------------------------------------------------------------------------------------------------------------
No defects found
============================================================= [PASSED] Took 0.70 seconds =============================================================

Environment               Tool      Status    Duration
------------------------  --------  --------  ------------
defect_detector_cppcheck  cppcheck  PASSED    00:00:00.696
============================================================= 1 succeeded in 00:00:00.696 =============================================================
Processing development (board: uno; platform: atmelavr@5.1.0; framework: arduino)
-------------------------------------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
CONFIGURATION: https://docs.platformio.org/page/boards/atmelavr/uno.html
PLATFORM: Atmel AVR (5.1.0) > Arduino Uno
HARDWARE: ATMEGA328P 16MHz, 2KB RAM, 31.50KB Flash
DEBUG: Current (avr-stub) External (avr-stub, simavr)
PACKAGES: 
 - framework-arduino-avr @ 5.2.0 
 - toolchain-atmelavr @ 1.70300.191015 (7.3.0)
LDF: Library Dependency Finder -> https://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 8 compatible libraries
Scanning dependencies...
Dependency Graph
|-- SerialReceiver
|-- hal
Building in debug mode
Checking size /workspaces/CRSFforArduino/.pio/build/development/firmware.elf
Advanced Memory Usage is available via "PlatformIO Home > Project Inspect"
Warning! The data size (3464 bytes) is greater than maximum allowed (2048 bytes)
RAM:   [==========]  169.1% (used 3464 bytes from 2048 bytes)
Flash: [====      ]  37.4% (used 12048 bytes from 32256 bytes)
============================================================= [SUCCESS] Took 0.69 seconds =============================================================

Environment    Status    Duration
-------------  --------  ------------
development    SUCCESS   00:00:00.687
============================================================= 1 succeeded in 00:00:00.687 =============================================================

What this means

The RAM CRSF for Arduino allocated in the above Konsole output is 3464 bytes (approximately 3.38 KiB), which is nearly double that of the maximum 2 KiB RAM that the Arduino Uno R3's on-board chip has.

Why?

CRSF for Arduino uses dynamic memory allocation in order to function as intended. Therefore CFA eats RAM!
CFA neads at least 4 KB of RAM available in your chosen development board.

RAM is not the only limiting factor

The chips in older development boards are clocked at 16 MHz. This is not fast enough to achieve the minimum baud rate required by CRSF for Arduino. Sure, you may be able to lower the baud rate, but doing so would make the library incredibly slow, and you may not be able to take advantage of higher packet rates that ExpressLRS has on offer. Thus, defeating the purpose of CFA.

Older development boards operate on 5V, which is significantly higher than all ExpressLRS and TBS Crossfire and TBS Tracer receivers, as they all require 3.3V logic levels on the Tx and Rx lines.
You may get away with using a level-shifter, but in a physically constrained environment (such as a drone) this becomes dead weight (especially when you live somewhere that restricts you to 250 grams or less). Even if you do try to run one of these boards on 3.3V, you will need to physically down-clock it to 8 MHz, which further hurts performance.

Takeaway

Development boards that have less than 4 KiB of RAM are all incompatible with CFA.
This includes, but is not limited to, the following identified boards:

Vendor	Board	Core Clock (in MHz)	Chip	RAM (in KiB)	Voltage (in V)
Adafruit	Feather 328P	8	ATMega328P	2.0	3.3
Adafruit	Feather 32U4 and derivatives	8	ATMega32U4	2.5	3.3
Adafruit	ItsyBitsy 32U4	8 or 16	ATMega32U4	2.5	3.3 or 5
Adafruit	Metro 328	16	ATMega328P	2.0	5
Adafruit	Metro Mini 328 v2	16	ATMega328	2.0	5
Arduino	Leonardo	16	ATMega32U4	2.5	5
Arduino	Mega2560	16	ATMega2560	4.0	5
Arduino	Micro	16	ATMega32U4	2.5	5
Arduino	Nano	16	ATMega328	2.0	5
Arduino	Pro Mini	8 or 16	ATMega328P	2.0	3.3 or 5
Arduino	Uno R3	16	ATMega328P	2.0	5

This is why I stress to you that all microcontrollers in the AVR architecture are not compatible with CRSF for Arduino.

Better options exist.

Limitations

I only tested CRSF for Arduino v2025.10.26 for the purposes of this case study.
This particular version uses dynamic memory allocation where the entire library is loaded into RAM.
All development boards mentioned here have significantly larger flash memory — some being 32 KiB or higher. No ExpressLRS, TBS Crossfire or TBS Tracer receiver was connected to my Arduino Uno R3 at all as I was not expecting CFA to compile at all, even after my "Add support for *add development board's name here*" workflow. I made no attempt to flash my Uno R3 with CFA as there was no safety mechanism that would otherwise prevent the board from bricking itself due to CFA causing an infinite out-of-memory crash immediately on startup.

This also tells me there is a need to explore the possibility of static allocation versus dynamic allocation, in addition to re-factoring how dynamic memory is handled.

Until new information comes to light telling me legacy AVR-based boards could be compatible with CFA in the future, they are for all intents and purposes incompatible all for varying reasons such as the core clock not being fast enough, operating voltage is non-compliant with the official CRSF Specifications, not enough RAM.