ESC firmware is one of those layers that is easy to ignore until it matters.

The flight controller asks for motor output. The ESC decides how that request becomes current through three motor phases. When that goes wrong, the result is not a bad web request. It is a desync, a hot motor, a failed startup, or a craft that does something expensive.

BLHeli is a long-running firmware family for sensorless brushless electronic speed controllers.

It is also a useful case study in what “open firmware” can mean over time. The older BLHeli and BLHeli_S code is open source under GPL-3.0. BLHeli_32 is documented in the repo, but its firmware source is closed.

What is BLHeli?

BLHeli is firmware for brushless ESC boards.

The repository is organized around three generations:

  • BLHeli: the original 8-bit firmware, written in assembly for Atmel and Silicon Labs MCUs.
  • BLHeli_S: the later SiLabs 8-bit firmware for smoother multirotor response.
  • BLHeli_32: the 32-bit ARM generation, documented here but closed source.

The open parts of the tree are very low-level. You are not reading a C HAL or an RTOS app. You are reading assembly files, board include files, generated .HEX firmware artifacts, EEPROM defaults, batch files for old Windows toolchains, and manuals.

That makes the repo different from something like Betaflight.

Betaflight is flight-controller firmware: sensors, control loops, receiver protocols, modes, mixers, and motor outputs.

BLHeli is below that: it lives inside the ESC and turns a throttle/control signal into motor commutation.

Why It Matters

ESC firmware affects:

  • Startup behavior.
  • Commutation timing.
  • Back-EMF zero-cross detection.
  • Demag compensation.
  • Braking and active freewheeling.
  • Bidirectional/3D behavior.
  • Throttle response.
  • Signal protocol support.
  • Beep and beacon behavior.
  • Temperature/current/voltage protection where hardware supports it.

That is why the exact target matters.

An ESC firmware file is not just “for 30A ESCs.” It is tied to MCU family, pin mapping, FET driver behavior, clock assumptions, deadtime, and hardware support. BLHeli makes this visible through its many .inc, .HEX, and .EEP files.

Repository Tour

The repo layout is straightforward:

Atmel/
SiLabs/
BLHeli_S SiLabs/
BLHeli_32 ARM/
COPYING
README.md

Atmel/ contains AVR assembly for older Atmel-based ESCs. It includes BLHeli.asm, ESC-specific include files, generated hex files, EEPROM files, and manuals.

SiLabs/ contains the original BLHeli assembly for Silicon Labs 8-bit ESCs.

BLHeli_S SiLabs/ contains the BLHeli_S assembly source, pinout include files named by letter, generated hex files, a Unix Makefile, and a Windows batch build script.

BLHeli_32 ARM/ contains BLHeli_32 documentation and firmware protocol specs, not the BLHeli_32 firmware source.

In the clone I inspected, the tree was about 74 MB and included roughly:

  • 1,015 .HEX firmware files.
  • 144 .EEP EEPROM files.
  • 186 .inc include files.
  • 3 main assembly source files.
  • 3 Windows batch build scripts.
  • 8 PDF manuals/support documents.

Firmware Families

BLHeli Atmel and SiLabs Rev14.x

The original BLHeli family has three code modes:

Mode Use
MAIN Helicopter main motor, with soft spool-up, governor, and low-voltage limiting
TAIL Helicopter tail motor, with rapid response, idle behavior, and bidirectional operation
MULTI Multirotor motors, with rapid response, closed-loop behavior, and bidirectional operation

The manuals describe support for 1 kHz, 2 kHz, 4 kHz, 8 kHz, and 12 kHz PWM input, plus regular 1-2 ms PPM and OneShot125. The input mode is detected on power-up.

These firmware targets also expose many tuning parameters: startup power, commutation timing, PWM frequency, demag compensation, rotation direction, input polarity, governor settings, closed-loop gains, beacon delay, and more.

BLHeli_S Rev16.x

BLHeli_S is the multirotor-focused 8-bit SiLabs generation.

The source root is:

BLHeli_S SiLabs/BLHeli_S.asm

The manual describes hardware-generated motor PWM, damped light mode, sync-loss protection, and input support for:

  • Regular 1-2 ms pulse input.
  • OneShot125.
  • OneShot42.
  • Multishot.
  • DShot150.
  • DShot300.
  • DShot600.

The naming convention is compact. A file like:

A_L_10_REV16_7.HEX

means:

  • A: MCU pinout variant.
  • L: 24 MHz MCU class.
  • 10: FET switching deadtime, in 20.4 ns units.
  • REV16_7: firmware revision.

That filename encodes hardware assumptions. Treat it as part of the safety system.

BLHeli_32 Rev32.x

BLHeli_32 is the 32-bit ARM generation.

The repository README says BLHeli_32 is closed source. The repo still includes a manual and Digital_Cmd_Spec.txt, which documents command IDs for beeps, ESC info, spin direction, 3D mode, save settings, extended telemetry, LED control, and other command slots.

The spec says these commands are valid for DShot and ProShot input signals, require zero throttle, and use the telemetry bit in command frames.

This distinction matters: you can inspect BLHeli_32 behavior from the manuals/specs, but you cannot audit the 32-bit firmware implementation from this repository.

Building From Source

This repo is not a modern make && flash embedded project.

The documented tooling reflects the history of the supported MCU families.

For Atmel BLHeli, the batch script expects AVR assembler tooling:

SET Revision=REV14_9
SET AtmelPath=C:\Atmel\avrassembler

For original SiLabs BLHeli, the batch script expects SiLabs and Raisonance tooling:

SET Revision=REV14_9
SET SilabsPath=C:\SiLabs
SET RaisonancePath=C:\Raisonance

For BLHeli_S, there is a Unix Makefile, but it wraps Simplicity Studio’s bundled Wine and Keil 8051 tools:

REVISION ?= REV16_7
TARGETS = A B C D E F G H I J K L M N O P Q R S T U V W Z
MCUS = H L
FETON_DELAYS = 0 5 10 15 20 25 30 40 50 70 90

On my machine, this build path was not available. Running make help inside BLHeli_S SiLabs/ failed immediately:

Makefile:49: *** "Could not find ~/local/SimplicityStudio_v4//support/common/wine/usr/bin/wine. Make sure to set the correct paths to the simplicity install location".  Stop.

That is a toolchain availability issue, not a BLHeli source failure.

Flashing and Configuration

The README points users to BLHeliSuite for flashing, configuration, and documentation, and to GitHub Releases for BLHeliSuite32.

This is the right place to be conservative. Do not flash random hex files from a blog post.

Before touching hardware:

  • Identify the exact ESC model.
  • Identify the MCU family.
  • Confirm whether it is BLHeli, BLHeli_S, or BLHeli_32 hardware.
  • Back up or note the current settings.
  • Remove propellers.
  • Use the supported suite/configurator path for that ESC family.
  • Confirm the firmware filename matches your hardware variant.

For BLHeli_S, a letter/delay mismatch can mean the wrong pinout or deadtime assumptions. For BLHeli_32, remember the source is not available in this repo.

Local Trial

I cloned the repo:

git clone --depth 1 https://github.com/bitdump/BLHeli.git /tmp/foss-post/BLHeli

The inspected commit was:

a5bcf99

The latest GitHub release observed was:

Rev32.10 / BLHeliSuite32 Rev32.10.0.0
published 2023-11-12

There are no Dockerfiles or compose files in the repo, and this is firmware rather than a server app, so no containers were started.

The only build check I attempted was the BLHeli_S Makefile:

cd "BLHeli_S SiLabs"
make help

It failed because the expected Simplicity Studio/Wine/Keil path was not installed locally. I did not assemble firmware, run BLHeliSuite, connect an ESC, or flash hardware.

When BLHeli is Useful

BLHeli is useful when you want to understand or work with ESC firmware at the source/artifact level.

It is especially relevant if you:

  • Maintain older Atmel or SiLabs ESCs.
  • Need to understand BLHeli_S target naming.
  • Want to inspect DShot and OneShot-era ESC behavior.
  • Are comparing ESC firmware generations.
  • Care about what is actually open in an FPV firmware stack.

It is less useful if you only need to configure a modern BLHeli_32 ESC. In that case, BLHeliSuite32 or a compatible configurator will be the practical tool, and this repo is mostly documentation/spec context.

Conclusion

BLHeli is part firmware source archive, part generated firmware catalog, part historical record of FPV ESC evolution.

The open code is low-level assembly for Atmel and SiLabs ESCs. BLHeli_S is still inspectable source. BLHeli_32 is documented here but closed source.

That split is the main takeaway. If you care about open firmware, BLHeli and BLHeli_S are inspectable. If you care about modern BLHeli_32 behavior, you can read the manual and protocol specs, but not the implementation.

For hardware work, treat every hex file as hardware-specific. ESC firmware is not a place for guesses.

FAQ

Is BLHeli open source?
The BLHeli and BLHeli_S source in this repository is GPL-3.0. The repository README states that BLHeli_32 firmware is closed source.
Does this project use Docker?
No. This is embedded ESC firmware and documentation. I found no Dockerfile or Compose file in the repo and did not start containers.
Can I build BLHeli_S on Linux?
The repo includes a BLHeli_S Makefile, but it expects Simplicity Studio’s bundled Wine and Keil 8051 tools at configured paths. Those tools were not installed on my machine, so the build was not attempted beyond path validation.
What is DShot support here?
BLHeli_S Rev16.x documentation describes DShot150, DShot300, and DShot600 support. BLHeli_32 documentation describes DShot support up to at least DShot1200, but BLHeli_32 source is not present in this repo.
Should I flash a random hex file from the repo?
No. Match the exact ESC hardware, MCU family, firmware family, pinout, and target naming first. Remove propellers and use the appropriate BLHeliSuite/BLHeliSuite32 workflow.