ESP32-S3 Development: When It Is the Right Chip, and How to Budget PSRAM, Displays and Power

Choosing between ESP32, ESP32-S3 and ESP32-C3

Most products that reach us with "we want to use an ESP32" have not yet decided which one, and the difference matters more than the shared brand suggests. The original ESP32 is a dual-core Xtensa LX6 with Wi-Fi and classic Bluetooth. The C3 is a single-core RISC-V part with Wi-Fi and BLE, aimed at cost. The S3 is a dual-core Xtensa LX7 with Wi-Fi and BLE, USB-OTG, more GPIO, support for larger external PSRAM, and vector instructions intended for neural network and signal processing work.

In practice the selection comes down to four questions, and they are worth answering before the schematic exists.

• Is there a screen? A colour display with a modern GUI framework is the strongest single argument for the S3. The PSRAM capacity and bandwidth, the display interfaces and the second core together make the difference between a product that feels responsive and one that feels like a prototype.
• Is there on-device inference? Keyword spotting, simple vision, anomaly detection on sensor streams — the S3's vector instructions exist for this class of work. If the product has no inference, that advantage is theoretical.
• Does the product expose USB? The S3 has native USB-OTG. If the product needs to appear as a device to a host, or needs USB firmware update without a serial bridge chip, that removes a part from the BOM and a failure point from the design.
• Is cost the binding constraint? If the job is "read a sensor and publish to MQTT", the C3 does it for less, and the engineering effort is similar. Choosing the S3 for a job the C3 can do is paying for silicon the product never uses.

Our firmware work spans the Espressif family alongside STM32, Ambiq Apollo, STC and AVR parts, and we choose per product rather than per habit. The honest default: screens and inference push toward S3; pure connectivity nodes stay on the cheaper parts.

PSRAM is a design decision, not a checkbox

The S3's internal SRAM is modest once Wi-Fi buffers, the TCP/IP stack and the application are accounted for. Any serious display work needs external PSRAM, and how that PSRAM is specified and configured affects the product's responsiveness as much as the choice of chip.

Three things to settle early:

• Quad versus octal PSRAM. Octal roughly doubles the usable bandwidth, which matters when a framebuffer is being read out continuously while the application writes to it. For large or high-refresh displays this is often the difference between a smooth interface and visible tearing.
• How much, and for what. Write the memory budget down before the UI is designed: framebuffer or draw buffers, image assets, networking buffers, application heap, and headroom. We treat this the same way on every GUI project — the budget comes before the first screen, and it is given the same weight as a power budget.
• Clock and layout. PSRAM at speed is a high-speed interface. Trace lengths, return paths and the clock configuration all affect whether the rated bandwidth is actually achieved on your board rather than on the evaluation kit.

The failure mode we see repeatedly is a GUI designed against a development kit with generous PSRAM, then ported to a cost-reduced board with a smaller part. Every fix at that point is a compromise.

Displays: LVGL on the S3

The S3 with PSRAM and LVGL has become a common combination for products that need a colour touchscreen without the cost and complexity of an application processor — thermostats, instrumentation front panels, handhelds, access control, appliance interfaces.

What we have learned shipping LVGL on resource-constrained hardware applies directly. Allocate GUI memory statically at startup where possible; dynamic allocation during screen transitions is where fragmentation hides. Size draw buffers to screen strips rather than full frames, using LVGL's partial rendering. Inventory every image asset before it enters the repository, and limit the font set ruthlessly — each variant and size is flash and RAM. These practices come from products we have delivered on Jieli AC79xx parts and are documented in our LVGL GUI development article; the constraints on an S3 are more generous but the discipline is identical.

The interface to the panel matters as much as the framework. The S3 supports SPI panels, parallel RGB and, with the right configuration, higher-bandwidth arrangements. SPI is simple and cheap and runs out of bandwidth at modest resolutions and refresh rates. Parallel interfaces cost GPIO and layout effort and buy headroom. This should be decided from the resolution, colour depth and target frame rate, calculated before the panel is ordered rather than discovered during bring-up.

Touch brings its own work: controller selection, I2C or SPI wiring, interrupt handling, and calibration. On our Raspberry Pi DSI display project — a different platform, same class of problem — touch calibration across 4.3, 5, 7 and 10 inch panels consumed a meaningful share of the bring-up time, with I2C debug logging used to diagnose the path. Budget for it.

Wi-Fi power: the number that decides battery products

Wi-Fi is power-hungry in bursts, and a battery-powered S3 product lives or dies on duty cycle rather than average current. The parts of the budget that matter:

• Deep sleep current, with everything the product actually leaves powered — PSRAM retention, RTC peripherals, external sensors, pull-ups, LEDs that nobody remembered.
• Wake and connect cost. Associating with an access point, obtaining an address and establishing a TLS session is where the energy goes. A device that wakes every minute spends most of its budget connecting, not sending.
• Transmit duty cycle. How long the radio is actually on, which follows from payload size, protocol overhead and retries under real signal conditions rather than bench conditions.

Techniques that earn their place: keeping a session alive rather than reconnecting when the reporting interval is short; batching readings so the radio wakes less often; using static IP configuration to skip DHCP where the network allows it; and choosing MQTT keep-alive intervals deliberately rather than leaving the library default.

We calculate the theoretical battery life from the product's duty cycle and then correct it with measurement, because datasheet typical values and measured values with real sensors attached routinely differ. This is the same method we apply on IoT terminals built on other low-power platforms, where RTC-timed wake-up and on-demand radio activation are what make multi-month battery life achievable.

USB-OTG: what it is actually worth

Native USB on the S3 removes the USB-to-serial bridge from the BOM, which is a small saving, but the practical value is larger than the component cost.

It makes firmware update over USB straightforward without a bridge chip and without exposing UART pins. It lets the product present itself as a composite device — mass storage for logs or configuration files, a serial port for diagnostics, HID for simple control — which can replace a bespoke desktop tool with something any technician can use. And in production it simplifies the flashing fixture.

The cost is design attention: USB is a differential interface with ESD requirements, connector mechanics and enumeration behaviour that must work when a user plugs in a random cable. Place the protection at the port, keep the differential pair short and matched, and test with cables of different quality rather than only the good one on the bench.

On-device inference: when the vector instructions matter

The S3's vector instructions accelerate the operations that dominate small neural networks, and Espressif's tooling supports deploying quantised models. In the products where this fits — keyword spotting, presence or gesture classification from a small sensor set, simple visual checks — it can remove the need for a cloud round trip and the latency, cost and privacy exposure that come with it.

The engineering reality is that the model must be designed for the budget from the start. Quantisation to int8, pruning, input resolution and feature extraction choices determine whether a model fits in the memory and latency envelope. Our approach on edge AI work is to treat model and hardware as one design problem: the model is sized against the chip's memory and the product's latency requirement before training effort is spent, not after.

It is also worth being honest about the ceiling. The S3 is a microcontroller. Workloads that need a real NPU or GPU — continuous video analytics, large models — belong on an application processor such as the Rockchip or Raspberry Pi platforms we also build on. Choosing the S3 for a job it cannot do wastes more time than choosing a more expensive part would have cost.

Provisioning and production

A connected product needs a way for the end user to get it onto their network, and this is where consumer products lose customers. If a buyer cannot get the device online within ten minutes of unboxing, nothing else about the product matters.

The common approaches on an S3 product are SoftAP provisioning, where the device hosts a temporary access point and a web page; BLE provisioning, where a phone app configures Wi-Fi over a BLE session; and QR-code assisted flows that remove the need to type an SSID and password. We have delivered app-side provisioning in production — in the 433MHz security linkage system the Flutter app binds devices by scanning a QR code and guides network setup with WiFi scanning, removing the error-prone manual entry step. Whichever route the product takes, the design rule is the same: every failed step must give clear feedback and a way forward, and the logs must make it possible to tell whether the failure was the device or the network.

Production brings its own list: factory flashing and test, per-device credentials and certificates, MAC and serial handling, and a firmware update path that works in the field. Secure boot and flash encryption are available on the S3 and should be decided at design time, because enabling them later changes the provisioning process and can be irreversible per device.

A short field guide

• Choose the S3 for screens, USB and on-device inference; choose a cheaper Espressif part for plain connectivity nodes.
• Specify PSRAM type and size from a written memory budget before the UI is designed.
• Calculate the display bandwidth from resolution, colour depth and frame rate before ordering the panel.
• Budget battery life from duty cycle, then correct it with measured current on real hardware.
• Use native USB for update and diagnostics, and design the ESD and layout for it properly.
• Size the model to the chip before training, not after.
• Decide secure boot and flash encryption at design time; they shape the production process.
• Design the provisioning flow for failure, because that is where real users meet the product.

If you are planning an ESP32-S3 product and want the firmware, the board and the app handled by one team, our firmware development service covers the chip selection through to production support.