# ESP-AT puts a command language on the ESP32 so a host MCU does not need one > ESP-AT is Espressif's AT command firmware for the ESP32, ESP32-C2, C3, C5, C6, C61 and S2, letting a host microcontroller drive wireless connectivity over a serial or SPI link. The interesting decision is in the compatibility table: the 5.x line dropped the original ESP32 and C3, and the S3 and H2 are excluded outright. **espressif/esp-at** — AT application for ESP32/ESP32-C2/ESP32-C3/ESP32-C6/ESP8266 - Repository: https://github.com/espressif/esp-at - Stars: 1,300 · Forks: 1,286 - Language: C - License: Apache-2.0 - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/espressif-esp-at ## The host MCU talks AT commands, not to a radio The design intent is spelled out in the introduction. Espressif SoCs serve as add-on modules, easily integrating wireless connectivity into existing products, and to reduce development costs Espressif offers a set of AT commands that let users interface with those products. The four stated benefits are a large number of built-in AT commands, easy integration with resource-constrained host platforms, easy-to-parse command-response protocols, and support for customized, user-defined AT commands. That last point is the one that changes the engineering picture. A fixed command set means your host firmware has to fit around whatever the module supports, while a path to define your own commands means the module can carry a feature that would be awkward to implement on a small host MCU. The project is hosted by Espressif Systems as an official project and is now supported and maintained by the Espressif esp-at team. ## The compatibility table has a hole in the middle of it The support matrix is the most informative page in the repository, and it does not read the way you would guess. For the ESP32, ESP32-C3, ESP32-C2, ESP32-C6 and ESP32-S2, the v4.2.0.0 release exists and the v5.0.1.0 column is marked as no plan to release. For the ESP32-C5 and ESP32-C61, the situation is reversed: there is no v4.2.0.0, and v5.0.1.0 is the released version. The master branch is supported across the board. So the two lines split the chip families rather than layering on top of each other, and the older chips are effectively frozen on the 4.x line while the newer ones start on 5.x. On top of that, the README states plainly that ESP-AT will not support the ESP32-S3 and ESP32-H2 series of chips. If your product is built on an S3, this project is not the answer. ## Three choices of firmware, and the README tells you which to pick The README offers three paths, each with a stated reason, which is more useful than a single recommendation. If the default AT firmware meets your requirements, it is recommended to use the latest released version of the firmware corresponding to the chip. If the default firmware does not meet your requirements and stability is a priority, you are told to develop your own AT firmware based on the latest released version. If you want more new features, you are told to develop based on the master branch. The distinction is between consuming a binary and forking the firmware, and it comes with a real obligation: the second and third options mean you now own a build of the firmware, and a chip update can break the assumptions in it. The badge legend behind the table spells out the four states, released, supported, pre-release and no-plan, and the released and supported ones link straight to the release page or the branch. ## The examples show what the command set reaches The examples directory is the fastest way to see the scope of the feature set, and the directory names are more informative than a command list. There is `at_custom_cmd`, which is the customised user-defined AT command path. There is `at_fs_to_http_server` and `at_http_get_to_fs`, which together show the module acting as an HTTP client and as a file server, meaning the module can hold a filesystem and expose it. There is `at_storage_security` and `at_interface_security`, two separate security examples covering stored data and the host interface. There is `at_sdio_host`, `at_spi_master` and the general UART path, so the host link is not restricted to serial. `at_override_module_config` is about changing the module's own configuration. The module configuration lives in a `module_config/` directory at the top of the repository, and the `components/` directory holds the firmware pieces themselves. ## Building the firmware needs Python packages and a build script The repository is a component based project with a `build.py` script and a `CMakeLists.txt` at the top level, alongside `bootloader_components/`, `main/`, `patches/`, `tools/` and `docs/`. The Python dependencies are pinned in a requirements file that says it is a list of packages needed for ESP-AT and that it is used with pip, referring to the Compile and Develop section of the ESP-AT User Guide for more information. Three packages are listed, and each maps to a specific job. The IDF Component Manager, pinned to the 3.1 series, is the general tooling. `pycryptodome` at version 3.19.1 is listed for the `at_interface_security` example. `littlefs-python` at version 0.15.0 is there for littlefs image building, which is the filesystem format that the file oriented examples work with. The `examples/` directory, `docs/` directory and `tools/` directory sit next to the sources, and the project also carries a `.pre-commit-config.yaml`, a `.gitlab-ci.yml` and a `.glab-ci.yml`, so the same code is built through GitHub and GitLab pipelines. ## A disclaimer comes before the feature list The README asks you to read the disclaimer in the documentation carefully and comply with its terms and precautions before using the ESP-AT solution, and that request comes before the introduction. It is not a boilerplate line. This firmware is what ends up driving the radio in a shipped product, and a host that talks to it over AT commands inherits whatever state the module holds, including stored credentials and network state. The examples that deal with `at_storage_security` and `at_interface_security` are the acknowledgement of that from the project side. Alongside the disclaimer there is a support periods document, published as an image and linked to a versions page, which tells you how long each release is expected to be supported. For a component that becomes part of your product's bill of materials, that table is the thing to pin your release choice to. ## Conclusion Adopt ESP-AT when your product uses an Espressif module as a wireless coprocessor and you would rather not implement the radio stack, the pairing flow and the network state machine on your host MCU. Do not adopt it if you need the S3 or H2, since the project states it will not support those series, and think twice if you need the original ESP32 with a current release, because the 5.x line is not planned for that chip. Verify first which released firmware matches your chip from the compatibility table, and read the disclaimer in the documentation, which the README asks you to read before using the solution. ## FAQ ### Which chips does ESP-AT support? The project covers the ESP32, ESP32-C2, ESP32-C3, ESP32-C5, ESP32-C6, ESP32-C61 and ESP32-S2. The README states that ESP-AT will not support the ESP32-S3 and ESP32-H2 series of chips. ### What is the difference between the v4.2.0.0 and v5.0.1.0 firmware lines? The lines split the chip families. The v4.2.0.0 release exists for the ESP32, C3, C2, C6 and S2, while v5.0.1.0 is marked as no plan for those chips and is the released version for the C5 and C61. ### Should I use the released firmware or build my own? The README gives three options. Use the latest released firmware for your chip if it meets your needs, develop from the latest released version if you need changes and stability is the priority, and develop from the master branch if you want the newest features. ### How do I build the ESP-AT firmware? The repository has a build.py script and a CMakeLists.txt at the top level. The Python dependencies are listed in requirements.txt, including the IDF Component Manager, pycryptodome for the interface security example and littlefs-python for littlefs image building, and the Compile and Develop section of the ESP-AT User Guide covers the process. ### Can ESP-AT be used over SPI or SDIO rather than UART? The examples directory includes `at_sdio_host`, `at_spi_master` and the general UART path, so the host link is not limited to serial. The repository also lists SPI and SDIO among its topics. ## Sources - [espressif/esp-at on GitHub](https://github.com/espressif/esp-at) - [Issues](https://github.com/espressif/esp-at/issues) - [License: Apache-2.0](https://github.com/espressif/esp-at/blob/master/LICENSE) - [README](https://github.com/espressif/esp-at/blob/master/README.md) - [Releases](https://github.com/espressif/esp-at/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/espressif-esp-at