SimpleFOC: Field Oriented Control for BLDC and Stepper Motors on Arduino and PlatformIO

The control problem SimpleFOC targets

Driving a BLDC or stepper motor well is not a wiring problem, it is an algorithm problem. Field oriented control keeps the stator current aligned with the rotor flux so the motor produces torque instead of heat, and doing that requires a rotor angle, a way to command currents or voltages, and a control loop fast enough to keep up with the electrical time constant. The README states the project exists because available solutions are almost exclusively tied to specific hardware configurations and microcontroller architectures, and because FOC-controlled stepper solutions are even scarcer. SimpleFOC's stated goal is to support as many motor plus sensor plus driver plus MCU combinations as possible and to make moving between them as easy as the project can manage.

That framing tells you who it is for. It is for people who have a motor and a board on a bench, not for people buying a drive cabinet. The README points hobby and community users toward official SimpleFOC boards and toward community-developed boards, which is a signal that the project expects you to assemble the power stage yourself or buy one from its ecosystem. If your motor already has an integrated drive with a fieldbus interface, this library is solving a problem you have already paid someone else to solve.

How the library is structured: motors, sensors, drivers, MCU support

The repository layout is the clearest description of the architecture. The top level holds src/, examples/, library.json, library.properties, keywords.txt and a Doxyfile, which is the shape of an Arduino library that is also published to the PlatformIO registry. The examples directory is split by concern rather than by board: hardware_specific_examples/, motion_control/, motor_commands_serial_examples/, osc_control_examples/ and utils/. That split matches the README's claim of modularity. Motor, sensor and driver are separate objects you combine in a sketch, and the hardware-specific folder exists precisely because the generic path does not cover every board.

The v2.4.0 release notes describe movement inside that structure. Motion control gained a custom mode and an angle_nocascade mode for position control without a velocity cascade, and the notes state that all closed and open loop modes can now be used with any torque control mode, giving velocity_openloop with foc_current as an example. Torque control gained an estimated_current mode for model-based current estimation without current sensing. On the MCU side, v2.4.0 added ADC reads alongside low-side current sense on STM32, support for multiple motors sharing low-side current sensing with one ADC per motor, fixes to a BG341 low-side current sense sync regression introduced in v2.3.5, ESP32 safety and ADC-timer alignment work, Teensy4 phase state setting, and support for the Arduino Nano Matter board. The build badges cover AVR, STM32, ESP32, RP2040, SAMD, Teensy and MBED, so the cross-platform claim is backed by CI targets rather than by prose alone.

The practical consequence of separating control mode from torque mode is that you can change how the motor is driven without rewriting the loop that decides where it should go. That is a real design win, and it is also why the release notes matter more than usual here: the combinations are the API.

Installing SimpleFOC and running a first motor sketch

The README does not walk through installation, but the repository is packaged as a standard Arduino library with library.properties and library.json, and the homepage points to docs.simplefoc.com for the getting-started material. The README's own badges identify the two distribution channels: the Arduino Library Manager badge reads Simple FOC, and the PlatformIO registry badge reads askuric/Simple FOC. Those two strings are the names to search for, in the Arduino IDE's Library Manager and in the PlatformIO registry respectively. The repository does not include a PlatformIO configuration file at the top level, so you supply your own environment for your board.

Once the library is installed, the examples directory is the entry point. The README does not reproduce a full sketch, so the honest first step is to open examples/ and pick the folder that matches what you are doing: hardware_specific_examples/ if your board has quirks, motion_control/ if you are working on position or velocity loops, motor_commands_serial_examples/ if you want to drive the motor from a serial terminal, and osc_control_examples/ if you are sending commands over OSC. Each folder contains sketches you flash unchanged first, before you edit pin numbers or sensor configuration. What you see on the serial monitor depends entirely on which example you flashed; the motor_commands_serial_examples/ folder exists for the case where the sketch expects you to type commands into that monitor. Start there if you want to confirm the board talks back before you trust it with a spinning motor.

Where SimpleFOC gets awkward

The first limitation is documentation coverage, and it is visible in the README itself. The installation path is not described there, only linked. The v2.4.0 notes mention a fix for a low-side current sense sync regression that was introduced in v2.3.5, which is a reminder that current sensing paths on STM32 have been moving and that a version bump can change behaviour you had already tuned around. If your design depends on low-side current sensing, treat the release notes as required reading rather than a changelog you skim.

The second limitation is the estimated_current mode. It estimates current from a model instead of measuring it, which is useful when you have no current sense hardware, but the README does not present it as equivalent to a real measurement. If your application needs torque accuracy under load or thermal variation, a model-based estimate is the wrong foundation, and you should plan for actual current sensing instead.

The third is scope. SimpleFOC assumes you are writing firmware for a microcontroller you control. It is not a drive firmware for a motor with an integrated controller and a fieldbus, and it is not a substitute for a certified motion controller in a machine that must pass functional safety review. The README's own framing, hobby community and community-developed boards, tells you which side of that line the project sits on.

SimpleFOC compared with vendor motor control SDKs

The obvious alternative is a vendor SDK: STM32 motor control software, TI's InstaSPIN-style offerings, or the motor control stacks that ship with a specific MCU family. The difference in approach is the axis of portability. A vendor SDK is tuned to one silicon family and one set of peripherals, so it can take advantage of hardware features a cross-platform layer cannot assume, and its current sensing and PWM paths are written against that specific timer and ADC arrangement. SimpleFOC inverts the priority: the same motor, sensor and driver objects are meant to follow you across AVR, STM32, ESP32, RP2040, SAMD, Teensy and MBED, and the hardware_specific_examples/ folder is the escape hatch when the generic path is not enough.

That trade is not free. A vendor SDK will usually be better documented for its own silicon and easier to get past a support ticket with the chip vendor. SimpleFOC will usually be faster to move between boards and easier to read if you want to understand the control loop rather than configure it. If your product is locked to one MCU family for its lifetime, the portability argument is worth less than it looks, and the vendor path becomes more attractive. If you are prototyping, teaching, or building a small run where the board may change, the portability is the whole point.

Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-08-05. The most recent tagged release is v2.4.0 from 2026-02-19, preceded by v2.3.5 on 2025-07-28 and v2.3.4 on 2024-07-21. The gap between v2.3.5 and v2.4.0 was roughly seven months, and v2.4.0 carried a large batch of changes: new motion control modes, feed forward terms in the motor classes, a velocity calculation rework, ESP32 safety work, and STM32 current sensing changes. A release that broad means an upgrade is a project, not a dependency bump. The release notes also show the library compiles across all v3.x arduino-esp32 versions as of v2.4.0, whereas v2.3.5 was compatible with v3.2.x, so the ESP32 toolchain version you pin interacts with the library version you pin. Budget time to re-flash and re-tune after a major bump, especially if you use current sensing.

The licence is MIT, which is permissive and imposes no copyleft obligation on your own firmware. That is the practical reading of the LICENSE file and the badge; it is not legal advice, and if you are shipping a product you should read the licence text and your own obligations rather than take a summary from an article.

Editorial conclusion

Adopt SimpleFOC if you are prototyping or building small-batch hardware on Arduino, PlatformIO or a supported board family and you want the same control code to follow you from one motor, sensor and driver combination to another. Do not adopt it if your project needs certified industrial drives, closed vendor support or a guaranteed long-term API freeze, because the release notes show control modes and interfaces still moving between v2.3.5 and v2.4.0. Before committing, verify three things: that your exact MCU appears in the library's build matrix or board list, that your sensor and driver combination is one the documentation covers, and whether you need current sensing, since the estimated_current mode is model-based and the README does not present it as a replacement for a real current sense path.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. simplefoc/Arduino-FOC on GitHub