The ESP32-C3 and C6 in IoT Designs

A connected product needs a processor and a radio. The ESP32-C3 and ESP32-C6 put both on one RISC-V chip. Espressif aims the two parts squarely at IoT work. The ESP32-C3 holds the low-cost connected node with Wi-Fi and Bluetooth. The ESP32-C6 reaches into Wi-Fi 6, Thread, and Matter. Their radios, their cores, and the ESP-IDF software behind them decide how each one fits a design. Together they cover a wide span of IoT work on a RISC-V core.

Espressif and its RISC-V line

Espressif Systems is a Chinese fabless semiconductor company, based in Shanghai. It built its name on cheap Wi-Fi silicon. The ESP8266 put a Wi-Fi radio and a microcontroller on one low-cost chip. That part reached millions of hobby and product boards over the years. The ESP32 followed with more compute and Bluetooth. Those early parts ran an Xtensa core. Espressif then opened a RISC-V path across the range. The ESP32-C3 started that line as a low-cost connected node. The ESP32-C6 carried it into Wi-Fi 6 and the 802.15.4 radio. Other RISC-V parts fill the gaps around them. The move to RISC-V kept the whole software base intact. A design that knows the ESP world meets a familiar chip on a new core. Espressif shipped the ESP8266 in 2014. Its tiny ESP-01 board reached hobbyists first. The ESP32 arrived in 2016 with a dual Xtensa core. Later Xtensa parts, the ESP32-S2 and S3, followed. The RISC-V C-series then grew beside them. A companion part, the ESP32-H2, carries only the 802.15.4 radio. The range now spans low-cost Wi-Fi to Thread and Matter.

The ecosystem is the reason these parts sit on so many IoT boards. Espressif ships one SDK for the whole range, called ESP-IDF. A FreeRTOS base runs underneath it. An Arduino core reaches the same parts for a lighter start. Years of ESP8266 and ESP32 use left a deep well of code. A driver for almost any sensor already exists in the open. A cloud connector for the major platforms already exists. Provisioning, over-the-air updates, and security come built into the SDK. A team that ships one ESP part carries that knowledge straight to the next. The RISC-V parts inherit the whole toolchain and the whole community. That inheritance carries real value on an IoT schedule. A design starts far up the curve. The idf.py tool drives the build, the flash, and the monitor from one command. A menuconfig screen sets the options without hand-editing code. Non-volatile storage keeps the device settings across a reboot. A component registry pulls in third-party code by name. The documentation runs deep on the Espressif site. A large forum answers the corner cases. A new design rarely meets a problem someone has not already solved. Espressif updates the SDK on a steady release cycle. A long-term-support branch holds each major version. A design pins its build to one version for stability.

The ESP32-C3 as a connected node

The ESP32-C3 is Espressif’s low-cost RISC-V connected node. It runs a single-core 32-bit RISC-V processor at 160 MHz. On-chip SRAM holds 400 KB. A separate ROM carries the boot code and library routines. Its radio covers 2.4 GHz Wi-Fi and Bluetooth 5 Low Energy. Bluetooth mesh runs on the same radio. Twenty-two configurable GPIO come out to the pins. A 12-bit ADC, several serial blocks, and a temperature sensor fill out the peripherals. A USB-Serial-JTAG unit sits on the chip for programming and debug. This part arrived around 2020 as the successor to the ESP8266. It brought a modern core and Bluetooth LE to the low-cost Wi-Fi slot. Its core replaced the older single-core Xtensa design. A newer USB-Serial-JTAG unit dropped the need for an external UART chip. The part ships in the WROOM-02 and MINI-1 modules. A typical module carries 4 MB of flash. In volume the chip sells for a dollar or two. Its footprint suits a small sensor board.

Its single RISC-V core handles the application and the network stack together. A 160 MHz clock leaves room for a protocol stack and application logic side by side. Its Wi-Fi supports the 802.11 b, g, and n standards on 2.4 GHz. A long-range mode stretches the link past standard Wi-Fi range. Its Bluetooth stack covers the Bluetooth 5 Low Energy core features. Bluetooth mesh reaches a whole network of low-power nodes. A hardware link-layer controller offloads the radio timing from the core. Deep-sleep mode drops the part to microamp current between events. An RTC memory holds state across a deep sleep. That combination suits a battery sensor that wakes, reports, and sleeps. Security sits in hardware on the part. Secure boot checks the firmware signature at start. Flash encryption protects the stored image. A set of cryptographic accelerators speeds the TLS handshake to a cloud. The part reaches a cloud endpoint over Wi-Fi through the stack the SDK provides. A provisioning flow hands the device its Wi-Fi credentials on first boot. An over-the-air update replaces the firmware in the field. These pieces cover the core of a connected product. The ESP32-C3 carries them at the low end of the price range. A deep sleep can reach single-digit microamps on the part. Light sleep keeps the radio ready at a higher current. The RMT peripheral drives addressable LEDs without the core. An LEDC block generates PWM for dimming and motors. SPI, I2C, UART, and I2S reach the usual sensors and audio parts. The GPIO matrix routes signals to nearly any pin. A design wires the part to its sensors and its power with room to spare. A boot ROM brings the part up before the app runs. A second-stage bootloader loads the firmware from flash. A watchdog resets the part on a hang. These pieces run before any application code.

This chip ships mostly as a module. An ESP32-C3-MINI-1 or a WROOM-02 module carries the chip, a crystal, an antenna, and the flash. A module clears the wireless certification for the design that uses it. That step saves an RF layout and a full FCC test. A dev board like the ESP32-C3-DevKitM-1 exposes the pins over USB. Low-cost NodeMCU-style boards carry the part for a few dollars. A CH340 USB-serial chip handles programming on those boards. That module drops onto a product board with a known footprint. The design supplies power, an antenna clearance, and the GPIO wiring. The connected node is the part’s home. A sensor, a smart plug, or a small controller that talks to a network all fit the slot. A module ships pre-certified for the radio. That certification saves a design months of RF testing. Espressif sells the modules through the major distributors. A board house assembles them like any other part.

Power planning defines an IoT sensor design. The ESP32-C3 draws real current with the radio on. A transmit burst pulls tens of milliamps for a short window. Deep sleep drops the draw to microamps between bursts. A design times its wakeups to stretch a battery over months. The RTC memory carries the running state across each sleep. A wake, a Wi-Fi connect, a report, and a sleep make one cycle. That cycle’s energy sets the battery life. The rarer the reports, the smaller the cell a design can run. The part gives a design the sleep modes to hit its power target. A sensor that reports once an hour lives a long time on a small battery. A door sensor wakes on a contact and sleeps again. A soil probe wakes on a timer and reports a reading. Each one wakes rarely and sleeps deep. A long sleep between reports is what earns the battery life.

The ESP32-C3 holds the low-cost end of the connected-node market. It carries a RISC-V core, Wi-Fi, and Bluetooth LE on one cheap chip. It runs the full ESP-IDF stack. It reaches a cloud and takes an over-the-air update. It sleeps down to microamps for a battery design. The part covers a simple connected product from end to end. The chip asks for a 2.4 GHz antenna and little else. A module supplies that antenna and the certification. The design drops the module on the board and writes the firmware. The path from an idea to a working connected node stays short. A prototype starts on a dev board and a USB cable. The firmware moves to a custom board without change. The module carries the radio tuning across that move. A first product ships on the same code the prototype ran.

The ESP32-C6 and the new radios

With the C6, the line extends into new radios. Espressif documents it as its first Wi-Fi 6 SoC, integrating 2.4 GHz Wi-Fi 6, Bluetooth 5 (LE), and the 802.15.4 protocol. Wi-Fi 6 improves the airtime a crowded network hands each device. A target-wake-time feature lets a Wi-Fi device sleep on a schedule the router agrees to. The 802.15.4 radio opens Thread and Zigbee. Those mesh protocols carry low-power smart-home traffic. Bluetooth 5 Low Energy stays on the part for phone setup and beacons. All three radios sit on one chip. A design uses the radio its network speaks. The part reaches a Wi-Fi cloud, a Thread mesh, or a Zigbee network from the same silicon. Wi-Fi 6 on the part runs in a 20 MHz channel on 2.4 GHz. The target-wake-time feature saves power on a Wi-Fi sensor. A Thread device joins a mesh through a border router. A Zigbee device joins as a coordinator, a router, or an end device. The companion ESP32-H2 carries the 802.15.4 radio alone. The C6 answers a design that needs Wi-Fi alongside the mesh radio. A single antenna serves all three radios on the part. The module tunes that antenna for the design. A product ships one radio front end for every protocol.

Matter is the reason the C6 counts in smart-home work. Matter runs a device over Wi-Fi or over Thread. The ESP32-C6 carries both radios for that job. A Matter device built on the C6 joins an Apple, a Google, or an Amazon home. Bluetooth handles the initial commissioning of the device. The 802.15.4 radio carries a Thread end device on low power. The Wi-Fi radio carries a mains-powered Matter device. Espressif ships a Matter SDK on top of ESP-IDF. A team builds a certified Matter product on the part. The C6 put Matter in reach of a low-cost RISC-V design. A smart-home vendor reaches the whole Matter stack on one chip. The C6 runs a Matter device over Wi-Fi on mains power, or over Thread on a battery. Espressif’s esp-matter SDK builds both from the same tree. A Thread border router links the Thread devices to the wider network. The C6 serves as a Thread end device in that network. Certification runs through the Connectivity Standards Alliance. A vendor ships one design into several smart-home platforms. One certification covers the device across those platforms.

Two RISC-V cores sit on the ESP32-C6. A high-performance core runs the application at 160 MHz. A low-power core runs at 20 MHz for background work. Its low-power core handles sensor polling while the main core sleeps. On-chip SRAM holds 512 KB. A ROM carries the boot and library code. GPIO count reaches 30 on the larger package. Security matches the rest of the line, with secure boot, flash encryption, and cryptographic accelerators. The part draws low power on the Thread radio for a battery node. The low-power core stretches a battery further on a standing task. That layout suits a sensor that watches an input and wakes the main core on a change. Both cores share the on-chip memory. The main core sleeps while the low-power core watches. A wake event hands control back to the main core. USB-Serial-JTAG on the part handles programming and debug. The security block matches the secure-boot and flash-encryption features across the line. A design treats the C6 as a C3 with more radios and a helper core. Both cores run from the same ESP-IDF build. A standing task moves off the main core to save power. A wake source pulls the main core back when it is needed.

The radio is the reason

The radio is the reason a design reaches for these parts. The RISC-V core and the ESP-IDF stack make that radio usable.

Building an IoT design

ESP-IDF is the frame an IoT build sits in. It runs on FreeRTOS underneath. A component system pulls in Wi-Fi, Bluetooth, and the network stacks. The build uses a standard RISC-V GCC. A single command flashes the part over USB. A serial monitor prints the logs back. An Arduino core reaches the same chips for a lighter start. PlatformIO carries the parts for teams that use it. The SDK ships examples for Wi-Fi, Bluetooth, Thread, and Matter. A team starts a connected app from a working example. A menuconfig screen sets the options without editing headers. A partition table lays out the flash for the app and the storage. A build produces a single image to flash. esptool writes that image over the USB port. A monitor decodes a crash back to a line of source. A continuous-integration job builds the firmware on every commit. The RISC-V parts run the same ESP-IDF as the older Xtensa parts. A team moves its code across the family with light edits.

Connectivity carries the weight of an IoT design. A provisioning flow hands the device its Wi-Fi credentials without a keyboard. A phone app sends the network name and password over Bluetooth. The device joins the network and remembers it in non-volatile storage. A cloud connector links the device to AWS, Azure, or a private broker. ESP RainMaker offers a ready cloud and phone app from Espressif. An MQTT client carries the telemetry to a server. TLS protects the link with the on-chip crypto accelerators. The device reports its data and takes its commands over that link. A QR code on the device starts the whole provisioning flow. The stack for all of this ships inside ESP-IDF. An esp-tls layer wraps the socket in encryption. mbedTLS runs the handshake under it. The HTTP client fetches and posts to a REST endpoint. A WebSocket carries a live channel to a server. RainMaker maps the device to a phone control in minutes. AWS IoT Core takes the device over MQTT. A private broker serves a design that keeps its own cloud. A device registers once and reconnects on its own. A cloud pushes a command down to the device. That device streams its readings up on a schedule. A dashboard shows the whole fleet in one view.

A shipped device needs updates in the field. The over-the-air support writes a new firmware image across the network. A dual-image partition keeps the old firmware as a fallback. A failed update rolls back to the working image. Secure boot rejects an unsigned image at start. Flash encryption keeps the stored firmware unreadable off the chip. An eFuse block holds the keys on the part. An anti-rollback counter blocks a downgrade to a flawed version. A fleet of devices takes a staged rollout from the cloud. These pieces turn a prototype into a product that lasts for years. The security sits in hardware where a design needs it. Secure boot version 2 checks an RSA-3072 signature. Flash encryption uses AES-XTS on the stored image. An eFuse burns the keys once and locks them. The digital-signature peripheral proves the device identity to a server. A rollback counter refuses an older image. The keys never leave the chip in the clear. A product carries these guards from the first unit. A signed image proves it came from the vendor. An encrypted flash hides the firmware from a reader. A locked eFuse blocks a later change to the keys. Security holds across the life of the product.

Power planning runs through the whole design. The power source sets the plan. A battery device sleeps between reports to save current. The deep-sleep current sets the battery life on a sensor. A design measures the energy of one wake-report-sleep cycle. It sizes the battery to the report rate the product needs. The low-power core on the C6 handles a standing sensor task on little current. The Wi-Fi target-wake-time feature trims the radio’s share of the budget. A design that plans its power hits its battery target. The part gives the design the sleep modes to reach it. A light-sleep mode keeps the radio ready while the core rests. Deep sleep powers down all but the RTC domain. A timer or a pin wakes the part from deep sleep. The RTC memory carries the state through the sleep. A design counts the microamp-hours of each cycle. The report rate and the sleep current set the battery life. A careful power budget stretches a coin cell across a year. The part exposes the modes a design needs to get there. A wake-source list decides what pulls the part out of sleep. A GPIO, a timer, or the radio can serve as that source. A design picks the wake path its job needs.

Where each part fits

These two parts split the IoT field by radio. The ESP32-C3 fits a Wi-Fi or Bluetooth product at the low end of cost. It suits a sensor, a smart plug, or a small controller that talks to a phone or a cloud. The ESP32-C6 fits a product that needs Wi-Fi 6, Thread, or Matter. It suits a smart-home device that joins a Thread mesh or a Matter home. The radio the network speaks decides between the two. A design reads its network first, then reaches for the part that carries the right radio. The price gap between them stays small, so the radio leads the choice. A Wi-Fi cloud sensor and a Bluetooth beacon run well on the C3. A Zigbee bulb, a Thread sensor, and a Matter product run on the C6. Each maps to the radio its network uses. A design reads its target network before it picks the part. The network’s radio names the chip. A quick read of the target protocol settles the part. That read comes early in the design.

This decision follows the network the product joins. The more a design leans on Thread or Matter, the more the C6 earns the socket. Both parts run the same ESP-IDF. A team carries its code from one to the other. Both parts inherit the ESP ecosystem. A driver and a cloud connector already exist for each. The ESP32-C3 answers the low-cost connected node. The ESP32-C6 answers the mesh and the Matter tier. Espressif’s ecosystem stands behind both. The CH32V and GD32V lines run through separate articles in this series. Together the ESP32-C3 and C6 cover the connected-product range on a RISC-V core. A team learns one SDK and ships both parts. A design moves from the C3 to the C6 when its network grows. The ecosystem carries the drivers, the cloud, and the updates for each. Espressif keeps the line current with new C-series parts. The RISC-V core runs the same code the Xtensa parts ran. A connected product reaches the market on proven ground. Both parts share a footprint family and a toolchain. A team carries one skill set across both. That shared base lowers the cost of moving between them.