The DFRobot FireBeetle 2 ESP32-UE addresses several of those practical requirements. It has an external antenna connector, built-in Li-ion battery charging, low-power hardware, 16 MB flash, and 2 MB PSRAM. It also includes a connector for compatible displays.

In this article, we'll cover what these features do, set up the board in Arduino IDE, and show how to check its Wi-Fi signal strength and sleep current.

What Is the FireBeetle 2 ESP32-UE?

The FireBeetle 2 ESP32-UE uses an ESP32-WROOM-32UE-N16R2 module. This is based on the original dual-core ESP32, not a newer ESP32-S3 or ESP32-C6. You still get the familiar Wi-Fi, Bluetooth, PWM, ADC, DAC, touch sensing, UART, SPI, and I2C features.

Here are the main specifications:

• Dual-core Xtensa LX6 processor, up to 240 MHz
• 16 MB external flash and 2 MB PSRAM
• 520 KB internal SRAM
• 2.4 GHz Wi-Fi (802.11 b/g/n)
• Bluetooth 4.2 Classic (BR/EDR) and BLE
• USB-C for programming and power
• Single-cell Li-ion battery connector and onboard charging
• GDI display connector and onboard LEDs
• Board dimensions: 25.4 × 60 mm

DFRobot lists 17 digital pins and 11 analog-capable pins among the board's interfaces. Check the exact pins and their restrictions before wiring a project.

The processor is familiar. The differences are mostly in how DFRobot has packaged it for projects that need to work away from a desk.

Why Use an External Antenna?

If you've used a regular ESP32-WROOM module, you've probably seen the exposed PCB antenna at one end. The ESP32-WROOM-32UE replaces that antenna with a small RF connector for an external 2.4 GHz Wi-Fi/Bluetooth antenna.

This matters when the ESP32 sits inside an enclosure. A nearby battery, display, ground plane, wiring, or metal surface can affect antenna performance. An external antenna lets you choose a better location without moving the entire circuit board.

Imagine an outdoor environmental monitor. The board and sensors sit inside a weather-resistant enclosure, while the antenna can be placed away from the crowded electronics or outside the enclosure using suitable weatherproof hardware.

That does not automatically make the FireBeetle a long-range ESP32. Signal strength also depends on antenna gain, orientation, cable loss, obstacles, interference, and the access point. An external antenna gives you more control over placement, not a guaranteed increase in range. We'll return to a simple Wi-Fi comparison after setting up the board.

Battery Power Without a Separate Charger Board

A better antenna location solves one problem for a remote sensor. The next is power.

The FireBeetle has a PH2.0 connector for a single-cell 3.7 V nominal Li-ion/LiPo battery. A fully charged cell can reach about 4.2 V. The board also includes charging circuitry, so you can connect USB power to charge the attached battery while you develop or service the device.

On a typical ESP32 prototype, you might need a separate battery charger and a suitable regulator. The FireBeetle already includes much of that hardware, which can reduce the number of extra modules and wires.

Before connecting a battery, check the connector polarity against the board documentation. PH2.0 connectors on different products do not always use the same wiring order. Use a suitable protected cell or battery pack and follow the manufacturer's charging and handling requirements.

If you're building a solar-powered device, you still need a charging and power-management arrangement suitable for the solar panel and battery. The battery connector alone is not a solar charge controller.

How Low Can the FireBeetle Go?

Battery power becomes much more useful when the ESP32 can sleep between readings.

The ESP32 itself supports deep sleep, but a development board contains more than the ESP32. Its regulator, USB interface, LEDs, and other circuits may continue drawing current even while the processor sleeps.

DFRobot includes a low-power solder jumper, connected by default. According to DFRobot, disconnecting it reduces static consumption by approximately 500 µA, and the board can reach about 13 µA in deep sleep under the manufacturer's stated conditions. Treat that number as a published specification rather than a measured result for your complete project.

There is a tradeoff. With the jumper disconnected, DFRobot says the onboard RGB LED can only be driven when USB power is present. If you don't need that LED in a battery-powered design, the reduced standby current may be worthwhile.

We'll use a short deep-sleep sketch later and measure current from the battery connection. The actual result will also depend on sensors, displays, pull-ups, and other connected hardware.

What Do 16 MB Flash and 2 MB PSRAM Add?

The ESP32-UE module carries 16 MB flash, compared with the 4 MB found on many basic ESP32 development boards. That extra storage can make room for larger firmware images, OTA update partitions, web pages, fonts, and other files.

The amount available to a sketch or filesystem still depends on the selected flash-size settings and partition scheme. A 16 MB chip doesn't mean one Arduino sketch can automatically use all 16 MB.

PSRAM serves a different purpose. It adds 2 MB of external working memory, which can help when an application needs large buffers, such as a graphical interface, web response data, or image content. PSRAM is slower than internal RAM and is not a substitute for it in every application.

Also, having PSRAM on the module doesn't mean every allocation automatically uses it. The selected firmware configuration must initialize PSRAM, and applications may need PSRAM-aware allocations or libraries. We'll check shortly whether Arduino detects it.

The GDI Display Connector

The board also has DFRobot's GDI display interface. It uses an 18-pin FPC connection for compatible displays, helping reduce the jumper-wire clutter found in some display prototypes.

For example, a sensor node could read temperature and humidity, update a local dashboard, and send the same measurements over Wi-Fi:

This is one reason the extra flash and PSRAM are useful together. They leave more room for assets and display buffers in projects using graphical libraries such as LVGL. Make sure the specific display and its library support the FireBeetle's GDI pin mapping; GDI isn't a universal connector for all displays.

Understanding the FireBeetle ESP32-UE Pinout

The pinout is mostly familiar, but DFRobot uses Arduino-style aliases alongside the underlying ESP32 GPIO numbers.

For example, the onboard indicator LED is on GPIO2, which DFRobot labels D9 in its FireBeetle Arduino examples. The onboard WS2812 RGB LED uses GPIO5/D8, while the user button uses GPIO27/D4.

Check the actual GPIO number when adapting a generic ESP32 example. Some pins have boot-strapping functions, connect to onboard components, or are reserved for module memory or programming. The module's flash/PSRAM connections also mean you should not assume every GPIO number mentioned in a generic ESP32 tutorial is available for general use.

For analog sensors, one restriction is especially important. The original ESP32 shares ADC2 with Wi-Fi. If your project needs Wi-Fi and analog readings at the same time, use an available ADC1 pin instead. On this board, GPIO34 and GPIO35 are useful ADC1 options. Both are input-only and have no internal pull-up or pull-down resistors.

That small pin choice can save a lot of debugging in a Wi-Fi sensor project.

Getting Started with Arduino IDE

You can program the ESP32-UE with Arduino IDE, ESP-IDF, or MicroPython. We'll use Arduino here because the first tests need only a few lines of code.

To set up the board in Arduino IDE:

1. Install the esp32 by Espressif Systems boards package through Boards Manager. If it isn't listed, add https://espressif.github.io/arduino-esp32/package_esp32_index.json under Additional Boards Manager URLs.
2. Go to Tools > Board > ESP32 Arduino > FireBeetle ESP32-E. This is the selection shown in DFRobot's ESP32-UE getting-started guide, despite the board itself being the UE antenna variant.
3. Connect the board with a USB-C data cable and select the correct serial port.
4. Upload the blink sketch below.

const int LED_PIN = D9;  // FireBeetle alias for GPIO2

void setup() {
  pinMode(LED_PIN, OUTPUT);
}

void loop() {
  digitalWrite(LED_PIN, HIGH);
  delay(500);
  digitalWrite(LED_PIN, LOW);
  delay(500);
}

The small onboard LED should turn on for half a second and off for half a second. It's a useful first check that the board, USB connection, and Arduino settings are working.

Checking PSRAM

Next, upload this sketch and open Serial Monitor at 115200 baud:

void setup() {
  Serial.begin(115200);
  delay(1000);

  if (psramFound()) {
    Serial.println("PSRAM detected");
    Serial.print("Total PSRAM: ");
    Serial.println(ESP.getPsramSize());
    Serial.print("Free PSRAM: ");
    Serial.println(ESP.getFreePsram());
  } else {
    Serial.println("PSRAM not detected");
  }
}

void loop() {
}

A correctly initialized N16R2 module should report about 2 MB of total PSRAM, with some memory already in use.

Connecting to Wi-Fi and Reading RSSI

Now for a test that relates directly to the external antenna. This sketch connects to a 2.4 GHz network and prints the received signal strength indicator (RSSI) every second.

#include <WiFi.h>

const char* ssid = "YOUR_SSID";
const char* password = "YOUR_PASSWORD";

void setup() {
  Serial.begin(115200);
  WiFi.mode(WIFI_STA);
  WiFi.begin(ssid, password);

  unsigned long start = millis();
  while (WiFi.status() != WL_CONNECTED &&
         millis() - start < 15000) {
    delay(500);
    Serial.print(".");
  }

  if (WiFi.status() == WL_CONNECTED) {
    Serial.println("\nWi-Fi connected");
    Serial.print("IP address: ");
    Serial.println(WiFi.localIP());
  } else {
    Serial.println("\nWi-Fi connection timed out");
  }
}

void loop() {
  if (WiFi.status() == WL_CONNECTED) {
    Serial.print("RSSI: ");
    Serial.print(WiFi.RSSI());
    Serial.println(" dBm");
  } else {
    Serial.println("Wi-Fi disconnected");
  }
  delay(1000);
}

RSSI is expressed in dBm. -45 dBm indicates a stronger received signal than -80 dBm. The number will fluctuate as the radio environment changes.

Comparing Wi-Fi Signal Strength

To see what antenna placement changes in practice, compare the FireBeetle against a regular ESP32 board with a PCB antenna. Use the same access point, 2.4 GHz network, and test locations. Keep board and antenna orientation consistent, collect at least ten readings at each point, and calculate the average.

Record the external antenna model and any RF cable used. If possible, repeat the test with the FireBeetle antenna inside and outside the enclosure. That gives a more useful comparison than assuming an external antenna is always better.

Measuring Deep-Sleep Current

The other feature worth checking is power consumption. For a simple test, we can make the ESP32 sleep for 60 seconds, wake up, and then go back to sleep.

#include "esp_sleep.h"

void setup() {
  Serial.begin(115200);
  delay(500);

  esp_sleep_enable_timer_wakeup(60ULL * 1000000ULL);
  Serial.println("Entering deep sleep for 60 seconds");
  Serial.flush();
  esp_deep_sleep_start();
}

void loop() {
}

Use the Wi-Fi sketch from the previous section to record current while connected, then upload the deep-sleep sketch for the two sleep measurements. For current measurements, disconnect USB power and measure at the battery supply with a meter that can resolve microamp-level current. Keep the antenna connected but remove unnecessary external loads, such as a display or sensors, for the initial board-only comparison.

Measure with the low-power jumper intact, then repeat after disconnecting it, following DFRobot's instructions. Power the board down before changing the jumper, and note the meter and battery supply used. Wi-Fi active current changes rapidly, so a single instantaneous reading does not represent all operating conditions.

Is the FireBeetle 2 ESP32-UE Worth Choosing?

I wouldn't buy the FireBeetle just to blink LEDs or learn basic ESP32 programming. A cheaper, generic ESP32 board will do those jobs.

The FireBeetle becomes more interesting when several requirements appear together. Imagine a monitoring device in an enclosure that reads sensors every few minutes, reports data over Wi-Fi, and runs on a battery. In that case, you can position the antenna away from the electronics, use the onboard charger, and reduce standby current between readings. If you need a local dashboard, the extra memory and GDI interface are useful additions.

There are also reasons to choose something else. The FireBeetle uses the original ESP32 architecture. An ESP32-S3 board may be a better fit for newer processing features or native USB, while an ESP32-C6 is worth considering for Wi-Fi 6 or IEEE 802.15.4 support. Those boards have different peripheral and software tradeoffs, so the newer chip isn't automatically better for every project.

Final Thoughts

What makes the FireBeetle 2 ESP32-UE useful isn't a faster processor. It's the combination of an external antenna connection, battery-oriented power hardware, low-power options, and enough memory for a more complete IoT interface.

For a breadboard experiment, these details may not matter. But for an ESP32 that needs to sit inside a box, spend most of its time asleep, and communicate reliably, those details are exactly what I'd check before choosing a board.

Need board-specific pin mappings, power details, and reference drawings? See the official DFRobot FireBeetle 2 ESP32-UE documentation.

The post DFRobot FireBeetle 2 ESP32-UE: What Makes This ESP32 Board Different? appeared first on Teach Me Microcontrollers!.

The DFRobot C4001 takes a different approach. Instead of detecting infrared radiation from the human body, it uses a 24 GHz radar signal. The SEN0610 version of the C4001 can detect human presence as well as measure the distance and speed of a moving target. In this tutorial, I will connect the C4001 to an ESP32 and see how well it works as a human presence sensor. More importantly, I'll test whether it can continue detecting me when I'm sitting relatively still.

DFRobot C4001 SEN0610

The module I'm using is the DFRobot Gravity C4001 24 GHz mmWave Human Presence Detection Sensor, part number SEN0610. DFRobot offers different versions of the C4001, so this distinction matters. The SEN0610 used here is the 12-meter version.

Its main specifications are:

The board is quite small, measuring about 22 × 30 mm. My module also has a standard four-pin Gravity connector, so connecting it to another DFRobot board is straightforward. However, we can just as easily connect it to a regular ESP32 development board.

How mmWave Human Presence Detection Works

The C4001 is called a mmWave sensor because it uses radio waves with wavelengths measured in millimeters. In this case, the sensor operates around 24 GHz, which corresponds to a wavelength of roughly 12.5 mm.

Unlike a PIR sensor, the C4001 actively transmits a radio signal. When this signal encounters a person or another object, some of the radio energy reflects toward the sensor.

The sensor then compares the transmitted signal with the reflected signal. Changes in the returned signal can reveal information about the target. This is why a radar-based sensor can do more than simply produce a HIGH or LOW output when somebody moves. Depending on its operating mode, the C4001 can determine human presence, target distance, and target speed.

Why Can mmWave Detect a Person Sitting Still?

This is one of the most interesting differences between mmWave and PIR sensing. A PIR sensor detects changes in infrared radiation within its field of view. Someone walking across the room creates an obvious change, so a PIR sensor can detect that movement easily. However, if the person stops moving, the infrared pattern becomes relatively constant, and the PIR sensor may eventually stop reporting motion.

A person who appears stationary isn't actually perfectly motionless. Breathing moves the chest. We shift our posture slightly. Our head and hands make small movements even while we're sitting at a desk. A sufficiently sensitive radar sensor can detect these small changes in the reflected radio signal. This allows the C4001 to detect slight human movement and makes it useful for presence detection rather than only conventional motion detection.

This is also something I'll test later rather than simply taking the manufacturer's specification at face value.

How the C4001 Measures Distance

The C4001 uses FMCW, or Frequency-Modulated Continuous-Wave radar. Instead of continuously transmitting the same frequency, an FMCW radar changes its transmitted frequency over a defined interval. This changing signal is commonly called a chirp.

The reflected signal has traveled from the radar to the target and back again, so it arrives slightly later than the signal currently being transmitted. The radar compares the transmitted and received signals. Because the transmitted frequency is changing with time, the delay produces a difference between their frequencies. This difference is usually called the beat frequency. The farther away the target is, the longer the round trip takes and therefore the greater this frequency difference becomes.

In simplified form:

$R = \frac{c f_b}{2S}$

where:

• R is the distance to the target,
• c is the speed of light,
• f_b is the measured beat frequency, and
• S is the frequency sweep rate of the radar chirp.

You don't need to perform this calculation on the ESP32. The C4001 handles the radar processing internally and makes the resulting target information available through its UART or I2C interface.

How the C4001 Measures Movement and Speed

Radar can also detect movement using the Doppler effect. If a person moves toward or away from the sensor, the reflected radio signal changes slightly because of that motion. The principle is similar to the familiar change in pitch of a vehicle siren as the vehicle approaches and then moves away, except here we're dealing with electromagnetic waves rather than sound.

By analyzing these changes across its radar measurements, the C4001 can determine whether the target is moving and obtain information about its velocity. This gives us three useful pieces of information from one small module:

• Presence – Is somebody there?
• Range – How far away are they?
• Velocity – How fast are they moving toward or away from the sensor?

For an ESP32 project, most of the complicated radar processing therefore remains inside the C4001. From the ESP32 side, we're essentially communicating with a smart sensor and reading the processed results.

C4001 Pinout

Despite what is happening inside the sensor, connecting the module is surprisingly simple.

The Gravity connector has only four pins:

The same two signal pins therefore serve different functions depending on which communication interface is selected. Two DIP switches on the module configure the communication interface and I2C address.

For this tutorial, I will use I2C. This only requires two signal wires and lets the ESP32 communicate with the sensor using its normal I2C peripheral.

Connecting the C4001 to ESP32

For my test, I'll use the following connection:

Before powering the circuit, the switches on the C4001 must also be placed in the appropriate I2C configuration. The C4001 supports two I2C addresses: 0x2A and 0x2B. The DFRobot Arduino library identifies these as DEVICE_ADDR_0 and DEVICE_ADDR_1.

Installing the DFRobot C4001 Arduino Library

Fortunately, we don't need to implement the C4001 communication protocol ourselves. DFRobot provides the DFRobot_C4001 Arduino library.

Open the Arduino IDE Library Manager and search for DFRobot_C4001, then install the library. The library provides functions for presence and motion detection as well as obtaining target information such as range and speed.

Reading Distance and Speed with the ESP32

For our first test, we'll communicate with the sensor through I2C and print its readings to the Serial Monitor. The DFRobot library provides functions including:

radar.motionDetection();
radar.getTargetNumber();
radar.getTargetSpeed();
radar.getTargetRange();
radar.getTargetEnergy();

These functions allow the ESP32 to determine whether the sensor has detected a target and retrieve information about it.

#include <Wire.h>
#include "DFRobot_C4001.h"

#define SDA_PIN 21
#define SCL_PIN 22

// C4001 I2C address:
// DEVICE_ADDR_0 = 0x2A
// DEVICE_ADDR_1 = 0x2B
DFRobot_C4001_I2C radar(&Wire, DEVICE_ADDR_1);

void setup()
{
  Serial.begin(115200);

  // Initialize ESP32 I2C
  Wire.begin(SDA_PIN, SCL_PIN);

  // Connect to the C4001
  while (!radar.begin())
  {
    Serial.println("C4001 not detected.");
    delay(1000);
  }

  Serial.println("C4001 connected.");

  // Set the sensor to presence detection mode
  radar.setSensorMode(eExitMode);

  // Detection range: 30 cm to 10 m
  radar.setDetectionRange(30, 1000, 1000);

  // Sensitivity: 0 to 9
  radar.setTrigSensitivity(1);
  radar.setKeepSensitivity(2);

  // Trigger delay = 1 second (100 x 0.01 s)
  // Keep time = 2 seconds (4 x 0.5 s)
  radar.setDelay(100, 4);

  Serial.println("Presence detection started.");
}

void loop()
{
  if (radar.motionDetection())
  {
    Serial.println("Person detected");
  }
  else
  {
    Serial.println("No person detected");
  }

  delay(500);
}

Once the code is running, we should be able to observe the C4001 readings directly from the Arduino Serial Monitor.

Can the C4001 Detect a Person Sitting Still?

This is the test I'm most interested in. Detecting someone walking across a room isn't particularly difficult. Even an inexpensive PIR sensor can do that. The more useful question is:

Can the C4001 tell that I'm still in the room when I'm barely moving?

To find out, I positioned the sensor approximately 1 meter away and performed three simple tests.

In all three tests, the sensor detected me almost instantly. Although there's a noticeable delay between detection and no detection when I am out of the sensor's range.

Testing the C4001 Detection Distance

DFRobot specifies a maximum detection range of 12 meters for the SEN0610. However, a maximum specification doesn't necessarily tell us what to expect inside an actual room. So I performed a simple real-world test. I placed the C4001 in a fixed position and moved away from it while monitoring its output.

This isn't intended to be a laboratory characterization of the radar. Room geometry, sensor orientation, surrounding objects, and target movement can all affect radar measurements. Instead, the test gives us a better idea of what we can expect from the module in a normal indoor project.

Testing Target Speed

Since the C4001 can also report target velocity, I performed one more simple experiment. I walked toward the sensor and then away from it while watching the reported speed in the Serial Monitor.

Presence Detection vs Distance and Speed Measurement

There is an important distinction when experimenting with the C4001. The sensor provides operating modes intended for different applications. One is particularly useful for determining whether somebody is present, while another provides target information such as distance and speed. This matters because an occupancy sensor and a radar measurement sensor aren't necessarily doing the same job.

If I were building an automatic room-lighting system, for example, my main question would simply be "Is somebody still in the room?" For another project, such as detecting someone approaching a doorway, distance and speed become much more useful.

In presence detection mode (eExitMode), the C4001 focuses on determining whether someone is within the configured detection area. Rather than continuously reporting how far away a person is, the sensor provides a detection status. This makes it suitable for applications such as automatic lighting, where the important thing is whether someone is still occupying the space.

Another useful feature of this mode is the ability to adjust the trigger sensitivity, keep sensitivity, and detection delay. These settings help prevent the output from changing too quickly when a person briefly stops moving. For example, if someone is sitting at a desk, an occupancy sensor should ideally continue reporting their presence even when they are relatively still.

Distance and speed measurement mode (eSpeedMode) works differently. Here, the C4001 can report the target's distance in meters and speed in meters per second. This is particularly useful when tracking someone walking toward or away from the sensor. With the ESP32 connected to the Arduino Serial Plotter, we can visualize the speed readings as the person moves.

One limitation is that the measured speed mainly represents movement along the radar's line of sight. Someone walking directly toward the sensor produces a more useful radial-speed measurement than someone walking sideways across its field of view. Also, distance and speed measurements are not the same as reliable room-occupancy detection. A stationary person may be easier to monitor using the dedicated presence detection mode.

For practical applications, I would choose presence detection mode for occupancy-based automation and distance and speed measurement mode for projects that need information about a moving target. The distinction is worth remembering because switching modes changes not only the available measurements but also the configuration functions used in the Arduino sketch.

C4001 mmWave vs PIR Sensor

The C4001 isn't necessarily a replacement for every PIR sensor. PIR sensors remain extremely simple and inexpensive. For detecting obvious movement, such as somebody walking past a doorway, they can be perfectly adequate. The C4001 becomes more interesting when the application needs to know whether somebody remains present.

That makes mmWave especially attractive for occupancy-based automation where turning the lights off simply because someone hasn't moved enough for a PIR sensor is undesirable.

Where Can You Use the C4001?

The most obvious use for the C4001 is room occupancy detection. An ESP32 could use the C4001 to determine whether a room remains occupied and then control lights, ventilation, air conditioning, or other devices accordingly.

Other possible applications include:

• Smart lighting systems
• Home automation
• Office occupancy detection
• Automatic HVAC control
• Bathroom occupancy sensors
• Security systems
• Bedside presence detection
• Automatic doors
• Approach detection

The distance information also opens up more interesting possibilities. Instead of simply detecting someone, an ESP32 could respond differently depending on how close that person is to a device.

Final Thoughts

At first glance, the DFRobot C4001 performs the same basic job as countless inexpensive motion sensors: detecting whether somebody is nearby. The important difference is how it does it. Using 24 GHz radar allows the C4001 to detect subtle movement that would be difficult for a conventional PIR sensor to recognize. At the same time, FMCW radar allows the module to provide information such as target distance and velocity. And from the ESP32 side, using all of this is surprisingly straightforward. The complicated radar processing happens inside the C4001; our microcontroller simply retrieves the processed information through I2C or UART.

During testing, one of the more interesting things to examine with the C4001 is how it responds when a person stops moving. Unlike a conventional PIR sensor, which primarily responds to changes in infrared radiation, the C4001 uses radar to detect movement, including smaller movements associated with someone remaining in place. However, detecting a person who is sitting quietly is still more challenging than detecting someone walking directly toward the sensor. The result depends on the sensor's sensitivity settings, mounting position, and surrounding environment.

The distance and speed measurement mode also adds another dimension to the experiment. Instead of simply indicating that a target has been detected, the sensor can provide measurements that we can observe through the Arduino Serial Monitor or Serial Plotter. Walking toward and away from the sensor is a useful way to demonstrate these capabilities, although the readings can fluctuate because of body movement, changes in target reflection, and the angle at which the person approaches.

Another consideration is the detection environment. Walls, furniture, and other reflective objects can affect radar measurements, while movements outside the intended detection area may produce unwanted detections. For this reason, sensitivity and detection-range adjustments are important, particularly when using the C4001 in a small room or near a doorway.

Overall, the C4001 offers more flexibility than a basic motion detector. Its presence detection mode is useful for occupancy-based applications, while its distance and speed measurement mode opens up possibilities for movement monitoring and interactive projects. The ESP32 handles both modes using relatively simple Arduino code, leaving the more complicated signal processing to the radar module.

For projects where you only need to detect somebody walking past a sensor, a PIR sensor may still be the simpler and cheaper solution. However, when the question changes from "Did something move?" to "Is somebody still here?", a mmWave presence sensor such as the C4001 becomes much more interesting.

The post ESP32 mmWave Human Presence Detection with DFRobot C4001 appeared first on Teach Me Microcontrollers!.

An ESP32 can run small machine-learning models locally, recognize voice commands, classify sensor data, process images, and even communicate with much larger AI models through the Internet. Newer devices such as the ESP32-S3 are especially interesting because Espressif added processor instructions that accelerate neural-network and signal-processing operations.

However, the term ESP32 AI can mean several different things. It may refer to TinyML running directly on the microcontroller, an ESP32 acting as a client for cloud-based AI, an AI camera project, or even the popular AI-Thinker ESP32-CAM board. In this guide, I will separate those concepts and look at what AI on an ESP32 can realistically do.

What Does ESP32 AI Mean?

There isn't one specific technology called "ESP32 AI." Instead, there are several ways to combine artificial intelligence with an ESP32. The most important distinction is where the AI model actually runs.

1. AI Running Directly on the ESP32

In this setup, the trained machine-learning model is stored in the ESP32's flash memory and inference occurs directly on the microcontroller. For example, a microphone could continuously listen for the words "ON" and "OFF." Instead of sending every audio sample to a server, the ESP32 processes the audio locally and decides which word it heard. This is often called edge AI, embedded machine learning, or TinyML. I already have a complete TinyML with ESP32 tutorial that covers the model-training and deployment process in detail. This article will focus more on what is possible and which approach makes sense for a particular project.

2. ESP32 Connecting to Cloud AI

The ESP32 does not necessarily have to run the AI model. Because it has Wi-Fi, the ESP32 can collect data and send it to an AI service running on a much more powerful server.

The basic architecture looks like this:

3. ESP32 as Part of an AI System

There is also a middle ground. An ESP32 might preprocess sensor data locally and only send interesting events to a server. For example, it could detect unusual vibration using a small local model and then send the captured data to a more powerful AI service for further analysis. This hybrid approach can reduce bandwidth while still allowing the system to use large models.

ESP32 AI vs AI-Thinker ESP32-CAM

One source of confusion is worth clearing up early. Searching for "ESP32 AI" often returns results involving the AI-Thinker ESP32-CAM. Despite the name, AI-Thinker is the manufacturer/brand associated with the module. The "AI" in AI-Thinker does not mean that the ESP32-CAM itself contains a dedicated artificial-intelligence processor. The ESP32-CAM is still useful for AI projects because it combines an ESP32 with a camera. Images can either be processed locally with sufficiently small models or sent to another device or server for more demanding computer-vision tasks.

So:

The two concepts overlap, but they are not the same thing.

Can an ESP32 Really Run Artificial Intelligence?

Yes, but the important word is inference. Most ESP32 AI projects do not train their neural networks on the microcontroller. Training might require thousands or millions of calculations performed repeatedly over a large dataset. Instead, training normally takes place on a PC or cloud platform. Once training is finished, the much smaller resulting model is exported and placed on the ESP32.

The workflow therefore looks like this:

For example:

Why the ESP32-S3 Is Better for AI

The original ESP32 can run small machine-learning models, and that is exactly what I used in my earlier TinyML projects. However, if I were buying a board specifically for a new ESP32 AI project today, I would normally choose an ESP32-S3, preferably a version with PSRAM. The ESP32-S3 includes vector instructions that accelerate operations commonly found in neural networks and digital signal processing. It is important to describe this correctly: the ESP32-S3 does not have a large dedicated neural-processing unit comparable to the AI accelerator found in some application processors. Instead, its processor includes instructions that make certain mathematical operations considerably more efficient.

This matters because neural networks repeatedly perform operations such as multiplication and accumulation:

$y = \sum_{i=0}^{n} w_i x_i + b$

where:

• x represents input values,
• w represents trained weights,
• b is the bias, and
• y is the resulting output.

A neural network may perform these operations thousands or millions of times for a single inference. The ESP32-S3 can therefore execute appropriately optimized models faster than a classic ESP32.

PSRAM Also Matters

Processor speed isn't the only limitation. A machine-learning model needs memory for:

• model weights,
• input data,
• intermediate layer outputs,
• the tensor arena or working memory, and
• your normal application code and buffers.

For very small sensor models, internal RAM may be enough. Camera and audio applications become much more demanding. An ESP32-S3 board with external PSRAM gives you considerably more room for frame buffers and larger models. That does not mean PSRAM automatically makes inference fast. External memory is generally slower than internal SRAM. However, having a slower place to store something is much better than not having enough memory to run the model at all.

What Kind of AI Can an ESP32 Run?

"AI" covers an enormous range of applications. Some are well suited to microcontrollers while others are completely unrealistic. Here are several applications that fit the ESP32 particularly well.

Sensor Classification

This is one of the easiest places to start. Suppose an accelerometer is attached to a machine. Instead of simply checking whether vibration exceeds a fixed threshold, a trained model could classify several operating states:

• normal operation,
• idle,
• unbalanced load,
• excessive vibration,
• possible fault.

The input consists of relatively small numerical datasets, so the model can also remain small.

Anomaly Detection

Instead of teaching the ESP32 every possible fault condition, a model can learn what normal sensor readings look like and identify unusual patterns. Possible applications include:

• machine condition monitoring,
• water pump monitoring,
• battery monitoring,
• unexpected power consumption, and
• environmental sensors.

This is an area where embedded AI can be more useful than simply putting a fixed threshold inside an if() statement.

Voice and Sound Recognition

Audio is another good match for the ESP32-S3. Instead of converting speech into arbitrary sentences, a small model might recognize a limited vocabulary such as: LIGHT, ON, OFF, FAN, OPEN, CLOSE

That task is much easier than full speech-to-text. I have a separate ESP32 TinyML voice command project using Edge Impulse for a practical example.

Other audio applications include:

• glass-breaking detection,
• alarm detection,
• machine noise classification,
• clap or sound recognition, and
• wake-word detection.

Image Classification

A camera image can be reduced to a small resolution and passed through a lightweight neural network. The output could answer a question such as:

Is this object:

Person 0.91 Cat 0.05 Background 0.04

This is more realistic for an ESP32 than asking it to fully understand a high-resolution image.

Object Detection

Object detection is harder than simple image classification because the model must determine both what an object is and where it appears in the image. Optimized object-detection models can run on newer ESP32 hardware, but memory usage and inference time quickly become important. For a battery-operated camera expected to recognize one or two objects, an ESP32-S3 may make sense. For multi-object high-resolution detection at high frame rates, a Raspberry Pi or more powerful processor is normally a better choice.

Gesture Recognition

Gesture recognition can use either camera images or motion sensors. An accelerometer-based gesture recognizer is particularly attractive because the input data is tiny compared with an image. You could teach a device to recognize different movements and perform commands without buttons.

On-Device ESP32 AI vs Cloud AI

Running a model locally is not automatically better.

The right solution depends on what the project needs.

For example, imagine a smart door. A local ESP32 model could detect a particular sound or wake word without sending continuous microphone recordings anywhere.

However, if you want the user to ask:

"Was anyone standing near the front door while I was away this afternoon?"

that is a much more complicated task. Sending selected images or event data to a larger AI model would make more sense.

ESP32 AI Frameworks and Tools

There are now several ways to deploy AI models on ESP32 devices.

TensorFlow Lite for Microcontrollers

TensorFlow Lite for Microcontrollers, commonly called TFLM, is designed to run neural-network inference on microcontrollers with limited RAM. It is useful when you want to understand the model deployment process more directly. I have a separate TensorFlow Lite on ESP32 tutorial with a voice activity detection example.

ESP-DL

ESP-DL is Espressif's neural-network inference framework for ESP devices. Its current toolchain can take trained models, quantize them, and convert them into a format optimized for supported Espressif chips. This is particularly interesting for ESP32-S3 projects because the framework can make use of optimized kernels for the chip. If I were developing a new performance-sensitive ESP32-S3 AI project, ESP-DL would be one of the first frameworks I would investigate.

ESP-WHO

ESP-WHO is aimed more specifically at computer-vision applications.

Typical applications include:

• face detection,
• face recognition,
• camera-based classification, and
• other embedded vision projects.

It is therefore worth checking when your ESP32 AI project starts with a camera rather than a microphone or sensor.

ESP-SR

For audio applications, Espressif also provides ESP-SR. It contains components for functions such as:

• audio front-end processing,
• wake-word detection, and
• speech-command recognition.

For a product that only needs to understand a limited command vocabulary, this is much more realistic than running a general speech-to-text model.

Edge Impulse

Edge Impulse provides a higher-level workflow for collecting datasets, extracting features, training models, and deploying them to embedded devices. It is especially convenient when experimenting with:

• accelerometers,
• microphones,
• environmental sensors, and
• small image datasets.

It can save a lot of setup time when your main goal is testing whether machine learning improves the project rather than building the ML toolchain yourself.

How Much Faster Is ESP32-S3 for AI?

This is something I prefer to measure rather than answer only from specifications. A useful experiment is to run the same small neural-network model on a classic ESP32 and an ESP32-S3. The model from my existing TinyML tutorial can be reused so that the network itself remains constant.

The important measurements are:

• model size,
• inference time,
• available heap before loading the model,
• available heap while the model is running, and
• whether PSRAM is required.

Inference time can be measured around the model's Invoke() function:

unsigned long startTime = micros();

TfLiteStatus invokeStatus = interpreter->Invoke();

unsigned long inferenceTime = micros() - startTime;

Serial.print("Inference time: ");
Serial.print(inferenceTime);
Serial.println(" us");

Can an ESP32 Run an LLM?

Technically, extremely small experimental language models can be squeezed into surprisingly limited hardware. However, this needs some perspective. The language models people normally associate with AI assistants contain millions or billions of parameters and require far more memory and processing power than a normal ESP32 can provide.

So if the goal is something like this:

User: Should I water my tomato plants today?

ESP32: Based on the soil moisture, temperature, weather forecast and your previous watering schedule, I recommend waiting until tomorrow.

the practical architecture is usually:

The ESP32 handles sensors, actuators and networking while the LLM handles natural-language reasoning. That is the approach demonstrated in my ESP32 OpenRouter AI project. There are experimental reasons to run tiny language models locally, but I would not choose an ESP32 for a project that actually needs ChatGPT-like conversation.

When Should You Use AI Instead of Normal ESP32 Code?

Not every project benefits from machine learning. Suppose a soil moisture sensor reads between 0 and 4095 and you simply want to switch a pump on below a fixed threshold.

Normal code is better:

if (moisture < threshold) {
    startPump();
}

A neural network would add complexity without solving a real problem. AI becomes more useful when the input contains a pattern that is difficult to describe using simple rules.

Consider vibration monitoring. A normal program might say:

if (vibration > 500) {
    fault = true;
}

But suppose a healthy motor sometimes exceeds 500 during startup while a failing bearing creates a particular frequency pattern even though its peak vibration remains below 500. Now the problem is no longer just a threshold. A trained model may be able to distinguish those patterns.

A simple rule I use is:

Which ESP32 Should You Use for AI?

For most new projects, this is how I would choose:

The interesting part is that the most powerful AI does not necessarily require the most powerful ESP32. If the microcontroller only needs to send a JSON request to an online LLM, even a classic ESP32 may be perfectly adequate. It is local inference where the ESP32-S3's extra capabilities become important.

ESP32 AI Project Ideas

If you want to experiment with ESP32 AI, here are some projects that are realistic enough to build:

• Machine vibration classifier — use an accelerometer to distinguish normal and abnormal operation.
• Offline voice-controlled switch — recognize a handful of commands locally without sending audio to the cloud.
• Sound classifier — distinguish alarms, claps, machinery or other sounds using an I2S microphone.
• Smart camera — detect whether a person or object is present before saving or transmitting an image.
• Gesture controller — classify accelerometer movements and use them to control a device.
• Sensor anomaly detector — identify unusual temperature, current, pressure or vibration patterns.
• AI sensor assistant — collect sensor readings on the ESP32 and send them to an LLM to generate a human-readable explanation.

The first five can potentially operate entirely offline. The final example is better suited to a cloud AI service.

ESP32 AI Frequently Asked Questions

Is the ESP32 powerful enough for AI?

Yes, if the model and task are small enough. Sensor classification, anomaly detection, wake words, simple audio classification and lightweight vision applications can all be appropriate. Large generative AI models are not.

Do I need an ESP32-S3 for machine learning?

No. The original ESP32 can run small TinyML models. However, the ESP32-S3 is generally a better choice for new on-device AI projects because of its vector instructions and the availability of boards with substantial PSRAM.

Does the ESP32-S3 have an AI accelerator?

It has processor extensions designed to accelerate neural-network and signal-processing calculations. It is better to think of these as AI-friendly vector instructions rather than a separate high-performance NPU.

Do I need PSRAM?

Not always. Very small sensor models can run entirely from internal memory. PSRAM becomes increasingly useful for camera frames, audio buffers and larger neural networks.

Can ESP32 run ChatGPT locally?

Not in the sense most people expect from ChatGPT. Tiny experimental language models are possible, but practical conversational AI is better handled by having the ESP32 communicate with an online LLM.

Is ESP32-CAM an AI board?

The camera makes it useful for AI applications, but the "AI" in AI-Thinker ESP32-CAM refers to the module manufacturer rather than a dedicated AI processor.

Should I use TensorFlow Lite, ESP-DL or Edge Impulse?

TensorFlow Lite for Microcontrollers is useful for understanding conventional embedded ML deployment. ESP-DL is attractive when targeting Espressif hardware and taking advantage of optimized implementations. Edge Impulse provides a convenient end-to-end platform for collecting data, training a model and deploying it to the ESP32.

Final Thoughts

The ESP32 is not going to replace a GPU, Raspberry Pi, or cloud AI server. That is also not what makes ESP32 AI interesting. Microcontrollers operate directly beside sensors and actuators. If a tiny model can recognize the pattern you need, an ESP32 can make a decision locally within a small, inexpensive, and low-power device.

For simple machine-learning experiments, the classic ESP32 is still usable. For new projects that require local audio, vision, or larger models, the ESP32-S3 is the much more interesting platform, particularly when paired with PSRAM. And if the AI task is simply too large for a microcontroller, Wi-Fi gives us another option: let the ESP32 handle the physical world while a cloud model handles the heavy computation.

If you want to build your first model rather than just explore the possibilities, continue with my TinyML with ESP32 Tutorial. For voice projects, see my ESP32 voice command recognition tutorial. And if your goal is to connect an ESP32 to a large language model, see my ESP32 LLM/OpenRouter project.

The post ESP32 AI Guide: What Can ESP32 and ESP32-S3 Actually Do? appeared first on Teach Me Microcontrollers!.

The ESP32-S31 moves to a dual-core RISC-V processor running at up to 320 MHz, adds Wi-Fi 6, brings back Bluetooth Classic, includes an IEEE 802.15.4 radio for Zigbee and Thread, and adds considerably more hardware for displays, cameras, audio and edge AI.

Espressif announced the ESP32-S31 in March 2026 and moved the device into mass production in July. So unlike some chips that remain development announcements for months, the S31 is already moving into development boards and production modules.

What is the ESP32-S31?

The ESP32-S31 is a high-performance wireless microcontroller from Espressif intended for connected devices that need more processing power and more interfaces than a typical ESP32 application. Its two main processor cores use the 32-bit RISC-V architecture and can operate at up to 320 MHz. One of those cores includes a 128-bit data path and SIMD instructions intended to accelerate operations commonly found in signal processing, image processing and machine-learning workloads.

That already makes the architecture quite different from the ESP32-S3. The S3 uses two Xtensa LX7 cores running at up to 240 MHz.

The ESP32-S31 also provides 512 KB of internal SRAM, while external or in-package high-speed PSRAM can provide much larger working memory for applications such as graphical interfaces, cameras and AI models. Espressif currently lists ESP32-S31 chip variants with 16 MB or 32 MB of in-package Octal SPI PSRAM.

The important specifications can be summarized as follows:

Those specifications put the ESP32-S31 somewhere between the traditional ESP32 microcontrollers and Espressif's more application-processor-like devices.

ESP32-S31 Uses RISC-V

One of the biggest changes is the processor architecture. ESP32-S3 uses Espressif's familiar Xtensa LX7 cores. ESP32-S31 instead uses RISC-V, continuing Espressif's shift toward the open instruction-set architecture already found in chips such as the ESP32-C3 and ESP32-C6.

The two high-performance cores run at up to 320 MHz. Espressif also includes a 40 MHz low-power coprocessor, which allows some monitoring and low-power tasks to continue while the main processors are inactive. The increased clock frequency alone does not explain all of the performance improvement. One CPU core provides a 128-bit data path with SIMD instructions. SIMD, or Single Instruction Multiple Data, allows one instruction to operate on several pieces of data at the same time.

Consider image processing. If an algorithm needs to perform the same mathematical operation on thousands of pixels, processing several pixel values simultaneously can be much faster than processing each one individually. This is also useful for DSP operations, audio processing and neural-network inference. The S31 therefore isn't simply a faster ESP32 for blinking LEDs or reading sensors. Much of its additional hardware makes more sense once the application starts handling large streams of data.

Wi-Fi 6, Bluetooth and 802.15.4

Connectivity is probably the area where the ESP32-S31 separates itself most clearly from the ESP32-S3. The S31 supports 2.4 GHz Wi-Fi 6, or IEEE 802.11ax. Note the 2.4 GHz specification here: Wi-Fi 6 support does not mean that the ESP32-S31 suddenly becomes a 5 GHz Wi-Fi device. Its integrated radio operates in the 2.4 GHz band.

Bluetooth support is also considerably broader. ESP32-S31 supports both Bluetooth 5.4 Low Energy and Bluetooth Classic BR/EDR. This is interesting because Bluetooth Classic disappeared from several newer ESP32 variants, including the ESP32-S3. Bringing it back makes the S31 more useful for applications such as Bluetooth speakers and other devices that still need compatibility with traditional Bluetooth audio. Bluetooth LE support also extends to LE Audio, including the LC3 codec and multi-stream audio capabilities. Espressif specifically highlights audio as one of the intended application areas for the chip.

There is also an IEEE 802.15.4 radio, which provides the hardware foundation for protocols such as Zigbee and Thread. That means one ESP32-S31 can potentially act as a much more capable smart-home controller than an S3. For example, a gateway could communicate with Wi-Fi devices, Bluetooth devices and Thread or Zigbee sensors without requiring separate wireless microcontrollers for every protocol. This also makes the chip particularly interesting for Matter gateways and border-router-style devices.

Gigabit Ethernet

Another surprising addition is a 1000 Mbps Ethernet MAC. The important word here is MAC. The ESP32-S31 does not magically provide an RJ45 Ethernet connection directly from the chip. A design still needs the appropriate external Ethernet PHY and magnetics. Espressif's own ESP32-S31-Function-CoreBoard-1 demonstrates this approach. The board connects the S31's RGMII interface to an external Ethernet PHY and provides an RJ45 connector capable of 10/100/1000 Mbps auto-negotiation. Still, having a Gigabit-capable Ethernet MAC inside an ESP32-class SoC is significant. It makes applications such as network gateways, industrial controllers and high-bandwidth edge devices much more practical.

ESP32-S31 for Displays and Cameras

The S31 is clearly designed for products with more sophisticated user interfaces. It includes a DVP camera interface supporting 8- to 16-bit data, along with several LCD interfaces. These include parallel RGB displays up to 24 bits as well as I8080 and MOTO6800-style interfaces. Hardware can convert between formats including RGB565 and several YUV formats. Espressif also provides dedicated image-processing hardware such as a JPEG codec, Pixel Processing Accelerator (PPA) and 2D-DMA.

Why does that matter? Without dedicated hardware, operations such as moving a framebuffer, resizing an image or handling camera data can consume a large percentage of CPU time. The ESP32-S31 can offload some of those jobs. That gives the main processors more time for application logic, networking or AI inference. Up to 14 capacitive-touch channels are also available, making the chip suitable for touch panels and appliances where physical buttons are being replaced by interactive displays. I can see this being particularly useful for smart control panels, video doorbells, small instrument displays and voice-enabled appliances.

Edge AI on the ESP32-S31

Espressif has been promoting AI capabilities since the ESP32-S3, so we should be careful about what "AI" means here. The ESP32-S31 is not intended to compete with a desktop GPU running a large language model. Instead, its hardware acceleration makes it suitable for smaller edge AI inference tasks where data must be processed directly on the device. Examples include keyword recognition, wake-word detection, image classification, object detection, anomaly detection and signal classification.

The combination of SIMD instructions, a 128-bit data path, hardware image processing, fast PSRAM and dedicated mathematical acceleration makes these workloads considerably more practical than they were on earlier ESP32 devices. Espressif also lists CORDIC acceleration among the S31's dedicated hardware. This also explains the amount of PSRAM available. A simple sensor-reading program doesn't need 16 MB or 32 MB of RAM. Camera frame buffers, graphical interfaces, neural-network tensors and audio buffers certainly can.

Peripheral Interfaces

Despite its emphasis on multimedia, the ESP32-S31 is still a microcontroller. The chip provides traditional interfaces such as SPI, I2C, UART, I2S, PWM and GPIO alongside newer or higher-performance peripherals. It includes four main-system UART controllers plus a low-power UART. SPI interfaces support normal SPI as well as Dual, Quad and, on some controllers, Octal operation. There are also two high-performance I2C controllers plus a low-power I2C interface.

USB receives a major upgrade to USB 2.0 High-Speed OTG. High-Speed USB is a substantial improvement over the USB Full-Speed interface found on the ESP32-S3. The S31 also includes interfaces for CAN FD, SD/MMC, motor-control PWM, LED PWM, RMT, pulse counting and parallel I/O. On the analog side, the documentation lists ADC, DAC, a temperature sensor, touch sensing and an analog voltage comparator. With up to 60 programmable GPIOs, larger designs are less likely to run into the pin limitations that sometimes appear when an ESP32 project starts combining a display, camera, external memory and several peripherals.

ESP32-S31 vs ESP32-S3

The S31 may look like the natural replacement for the ESP32-S3, but that doesn't mean every S3 project needs one.

Espressif itself recommends the S31 for gateways, bridges and AI multimedia devices where multi-protocol connectivity or higher processing performance is important. The company still recommends the S3 for more cost-sensitive applications that don't need these capabilities. That seems like the sensible way to look at the two chips.

If your project is reading an I2C sensor and uploading a value to an MQTT server, an ESP32-S31 would probably be excessive. If your project combines a camera, display, voice interface, Wi-Fi, Bluetooth and Thread, then the advantages start to become obvious.

ESP32-S31 Modules and Development Boards

Espressif is already offering modules around the new chip. The ESP32-S31-WROOM-1 family is listed with different flash and PSRAM capacities, while the ESP32-S31-WROOM-3 is being used on Espressif's multimedia and function development boards.

One interesting example is the ESP32-S31-Korvo-1. This development board is clearly aimed at showing what the chip can do beyond ordinary IoT sensing. It includes audio hardware, dual microphones, speaker outputs, microSD support, USB High-Speed connectivity and connectors for an LCD and camera. A current WROOM-3 configuration used by the board includes 16 MB flash and 16 MB PSRAM. Espressif also provides the ESP32-S31-Function-CoreBoard-1, which adds Gigabit Ethernet and audio hardware while breaking out the important GPIO connections.

Programming the ESP32-S31

For now, ESP-IDF is the safest development environment for the ESP32-S31. Espressif says S31 support is available in the ESP-IDF master and v6.1 branches, with official tagged support planned from ESP-IDF 6.1.1 onward. Arduino support is a different story.

As of September 2026, the stable Arduino-ESP32 documentation still does not list the S31 among officially supported SoCs. Espressif developers have been working on S31 support for Arduino 4.x, which is based on ESP-IDF 6.1, but the Arduino team's current roadmap places the 4.0 release in November 2026. So if you purchase an ESP32-S31 board today expecting exactly the same Arduino IDE experience as an ESP32-S3 DevKit, expect some rough edges.

For developers already comfortable with ESP-IDF, however, the S31 can already be explored properly. This situation should improve as the software ecosystem catches up with the hardware.

Security Features

The ESP32-S31 also includes considerably more security hardware than is necessary for the average hobby project, but that becomes important in commercial products. The chip supports secure boot, flash and PSRAM encryption, hardware cryptographic acceleration and protected key handling. Hardware support includes AES-128/256, RSA, ECDSA and ECC operations. Espressif also includes TRNG and a RAM-based physical unclonable function, or PUF, as part of its security architecture.

Flash encryption uses XTS-AES-256, while secure boot can verify signed firmware before it executes. Together, these mechanisms make it more difficult to extract proprietary firmware or replace legitimate software with unauthorized code. These features may not matter while experimenting with a development board, but they become very important once an ESP32-based product leaves the lab.

Who is the ESP32-S31 For?

The ESP32-S31 makes the most sense when several previously separate requirements start appearing in the same project. A smart-home gateway is one example. It may need Wi-Fi for the local network, Thread or Zigbee for sensors, Bluetooth for commissioning, Ethernet for reliable wired connectivity and enough processing power to run local automation logic.

A smart display is another. Now the device may need LCD graphics, touch input, audio, Wi-Fi, Bluetooth and perhaps a camera.  The same applies to voice assistants, industrial gateways, security panels and camera-based edge devices. For those applications, the ESP32-S31 can potentially replace several chips with one highly integrated SoC.

For basic sensor nodes and conventional ESP32 projects, however, the S31 is unlikely to make the ESP32-S3, C3 or C6 obsolete. Those devices are cheaper, mature and already have a large software ecosystem.

Final Thoughts

The ESP32-S31 feels less like another variation of the ESP32 and more like Espressif stretching the definition of what an ESP32-class microcontroller can handle. You still get familiar microcontroller peripherals such as GPIO, SPI, I2C, UART and PWM. But those now sit beside a 320 MHz dual-core RISC-V processor, high-speed PSRAM, Wi-Fi 6, Bluetooth Classic and LE, Zigbee/Thread connectivity, High-Speed USB, Gigabit Ethernet, camera and display interfaces, and dedicated multimedia accelerators.

The hardware is impressive. The main limitation right now is software maturity. ESP-IDF is already the primary path for development, while Arduino support is still catching up. For developers who depend heavily on mature Arduino libraries, the ESP32-S3 remains easier to use today. But once the ecosystem matures, the ESP32-S31 could become one of Espressif's most interesting devices for smart displays, gateways, audio products and edge-AI projects. And considering how many interfaces Espressif has managed to put into a single microcontroller, there should be plenty of projects worth testing on it.

The post ESP32-S31 Explained: Specs, RISC-V, Wi-Fi 6 and ESP32-S3 Comparison appeared first on Teach Me Microcontrollers!.

I ran into this while testing an ESP32-S3 Mini. I knew the chip on my board was supposed to have 2 MB of PSRAM. One of my first tests successfully allocated a 1 MB buffer; however, it was surprisingly easy to read that result as if the board only had 1 MB available. Another memory test showed the actual 2 MB.

The important part was figuring out what each PSRAM value actually represented.

There is the total PSRAM physically available to the chip. Then there is the amount currently free. There is also the largest continuous block that your program can allocate. Those numbers are related, but they are not necessarily equal. In this tutorial, I'll show you how to enable PSRAM in the Arduino IDE, confirm that the ESP32-S3 actually detects it, allocate buffers inside it and check how much usable memory remains.

What is PSRAM on the ESP32-S3?

The ESP32-S3 already contains internal SRAM. This is where your program keeps variables, task stacks, temporary buffers, and other runtime data. Internal RAM becomes limited once the project starts using large buffers. A small sensor program will probably never care about PSRAM. This becomes noticeable in projects that:

• Store camera frame buffers
• Run TinyML models
• Build large JSON documents
• Process audio samples
• Buffer data before writing to an SD card
• Store images for a display
• Receive large network packets or files

These applications can quickly consume the available internal SRAM. PSRAM, or pseudo-static RAM, gives the ESP32-S3 an additional external memory space. Depending on the hardware configuration, the PSRAM can be connected through Quad SPI or Octal SPI.

Once initialized, PSRAM can be allocated much like normal RAM. However, it is still external memory and not simply another block of internal SRAM. Because it is external memory, it is slower and has some restrictions that internal SRAM does not.

If you are also deciding which ESP32-S3 pins are available for a project, see my ESP32-S3 pinout guide. Some GPIO pins are used internally by flash and PSRAM on certain modules.

Does Your ESP32-S3 Actually Have PSRAM?

Not every ESP32-S3 board has PSRAM. Two boards sold as "ESP32-S3" can have different flash and PSRAM configurations. For Espressif modules, the suffix printed on the chip or module often gives us a clue.

For PSRAM, look at the R suffix. R2 indicates 2 MB PSRAM, while R8 indicates 8 MB PSRAM. There are also ESP32-S3 variants without PSRAM, so don't assume every board includes it. On generic boards such as the ESP32-S3 Super Mini, I would not trust the product listing alone. Check the actual marking on the chip or module if possible. This is what I did with my own board. On the image below, you can see "FN4R2P415070," which means this board has 2MB of PSRAM. I trust the device marking more than the seller's listing.

Enabling ESP32-S3 PSRAM in Arduino IDE

The Arduino configuration also has to match the installed PSRAM. If you are using the generic ESP32-S3 board definition, select:

Tools > Board > ESP32 Arduino > ESP32S3 Dev Module

Then look for:

Tools > PSRAM

Depending on the Arduino-ESP32 version and selected board, you may see options such as:

• Disabled
• QSPI PSRAM
• OPI PSRAM

For a board with R2 PSRAM, select:

QSPI PSRAM

Then, for a board with R8 PSRAM, select:

OPI PSRAM

For example, if the device marking indicates an R2 configuration, I would select:

Tools > PSRAM > QSPI PSRAM

A wrong PSRAM or flash setting can also prevent the board from booting correctly. So if an ESP32-S3 starts rebooting after uploading even a simple sketch, the PSRAM setting is one of the first things I would check.

Detecting PSRAM from an Arduino Sketch

These are my Arduino settings for this article, so make sure you have the same before uploading and running the sketches here:

• Board: ESP32S3 Dev Module if your specific Mini board isn't listed
• USB CDC On Boot: Enabled
• Upload Mode: UART0 / Hardware CDC
• USB Mode: Hardware CDC and JTAG if that option is available
• Port: <your ESP32-S3's COM Port>
• Serial Monitor: 115200

Before allocating PSRAM, first check whether the Arduino core detects it. The simplest test is psramFound():

void setup() {
  Serial.begin(115200);
  delay(2000);

  if (psramFound()) {
    Serial.println("PSRAM detected!");
  } else {
    Serial.println("PSRAM not found.");
  }
}

void loop() {
}

If everything is configured correctly, you should see:

PSRAM detected!

If you get:

PSRAM not found.

A failed detection test can also be caused by the board or PSRAM configuration.

Check these first:

• The exact ESP32-S3 chip or module variant
• The board selected in Arduino IDE
• The QSPI or OPI PSRAM setting
• The memory specification supplied by the board manufacturer

Only after those checks would I start suspecting a hardware problem.

Checking ESP32-S3 PSRAM Size

The ESP object reports the total, free, minimum-free, and maximum allocatable PSRAM.

Try this sketch:

void setup() {
  Serial.begin(115200);
  delay(2000);

  Serial.println("ESP32-S3 PSRAM Test");
  Serial.println("-------------------");

  if (!psramFound()) {
    Serial.println("PSRAM not detected.");
    return;
  }

  Serial.println("PSRAM detected: YES");

  Serial.print("Total PSRAM: ");
  Serial.print(ESP.getPsramSize() / 1024.0 / 1024.0, 2);
  Serial.println(" MB");

  Serial.print("Free PSRAM: ");
  Serial.print(ESP.getFreePsram() / 1024.0);
  Serial.println(" KB");

  Serial.print("Minimum free PSRAM: ");
  Serial.print(ESP.getMinFreePsram() / 1024.0);
  Serial.println(" KB");

  Serial.print("Largest free block: ");
  Serial.print(ESP.getMaxAllocPsram() / 1024.0);
  Serial.println(" KB");
}

void loop() {
}

On a 2 MB ESP32-S3, the important result should be close to:

PSRAM detected: YES
Total PSRAM: 2.00 MB

The other numbers will vary depending on the Arduino core, libraries and anything your program has already allocated. The total PSRAM value alone is not enough when debugging memory use.

Total PSRAM Is Not the Same as Free PSRAM

There are four useful numbers in the previous program:

ESP.getMaxAllocPsram() is especially important when allocating large buffers.

For example, suppose the ESP32 reports:

Free PSRAM:          1200 KB
Largest free block:   700 KB

You have 1.2 MB free in total, but that does not mean you can allocate a single 1 MB buffer. The free memory may be split into several smaller regions. The heap is fragmented: the free memory exists, but it is split into smaller blocks. Free PSRAM and maximum allocatable PSRAM therefore need to be checked separately. This is what confused my earlier 1 MB allocation test. A successful 1 MB allocation tells me that a 1 MB block was available. It does not tell me that the board physically contains only 1 MB of PSRAM.

Allocating Memory with ps_malloc()

Next, we can allocate a buffer directly in PSRAM. Arduino-ESP32 provides ps_malloc(), which works much like the normal C malloc() function except that the allocation is specifically requested from PSRAM.

Here's a simple example that tries to allocate 1 MB:

void setup() {
  Serial.begin(115200);
  delay(2000);

  if (!psramFound()) {
    Serial.println("PSRAM not available.");
    return;
  }

  const size_t bufferSize = 1024 * 1024;

  uint8_t *buffer = (uint8_t *)ps_malloc(bufferSize);

  if (buffer == NULL) {
    Serial.println("PSRAM allocation failed!");
    return;
  }

  Serial.println("1 MB PSRAM allocation successful.");

  free(buffer);
  Serial.println("Buffer released.");
}

void loop() {
}

Always check whether the returned pointer is NULL. Large allocations can fail even when PSRAM is enabled. Also notice that we release the PSRAM buffer using:

free(buffer);

You don't need a special ps_free() function.

Actually Writing Data to PSRAM

I also wanted to verify that the allocated memory could be written and read back correctly. Let's allocate 1 MB, fill it with data and then verify the values.

void setup() {
  Serial.begin(115200);
  delay(2000);

  if (!psramFound()) {
    Serial.println("PSRAM not detected.");
    return;
  }

  const size_t bufferSize = 1024 * 1024;

  uint8_t *buffer = (uint8_t *)ps_malloc(bufferSize);

  if (buffer == NULL) {
    Serial.println("Could not allocate 1 MB in PSRAM.");
    return;
  }

  Serial.println("1 MB allocated successfully.");

  // Fill the buffer with a repeating pattern
  for (size_t i = 0; i < bufferSize; i++) {
    buffer[i] = i & 0xFF;
  }

  // Verify the contents
  bool passed = true;

  for (size_t i = 0; i < bufferSize; i++) {
    if (buffer[i] != (i & 0xFF)) {
      passed = false;
      break;
    }
  }

  if (passed) {
    Serial.println("PSRAM read/write test PASSED.");
  } else {
    Serial.println("PSRAM read/write test FAILED.");
  }

  free(buffer);
}

void loop() {
}

This verifies more than allocation alone:

• Confirms PSRAM initialization
• Confirms that a large contiguous block is available
• Writes across the allocated region
• Reads the data back
• Checks that the contents were preserved

A successful result should look like:

1 MB allocated successfully.
PSRAM read/write test PASSED.

ps_malloc() vs malloc() vs heap_caps_malloc()

ps_malloc() is not the only allocator that can use PSRAM. ESP32 applications also use malloc(). With PSRAM enabled, the ESP32 heap allocator can also place some ordinary allocations in external RAM. That means ordinary calls to malloc() may also use PSRAM depending on the allocation size, available memory, and configuration.

This lets existing libraries use the larger heap without calling ps_malloc() directly. For memory tests, I use ps_malloc() so I know the buffer is coming from PSRAM:

uint8_t *buffer = (uint8_t *)ps_malloc(bufferSize);

For even more control, we can use the ESP32 capability-based allocator:

#include "esp_heap_caps.h"

uint8_t *buffer = (uint8_t *)heap_caps_malloc(
    bufferSize,
    MALLOC_CAP_SPIRAM | MALLOC_CAP_8BIT
);

The MALLOC_CAP_SPIRAM flag specifically requests external PSRAM. For most Arduino projects, ps_malloc() is easier to read. I would reach for heap_caps_malloc() when I need more specific control over the type of memory being requested.

When Should You Use PSRAM?

PSRAM is best suited to large data where the lowest possible access latency is not required.

Good candidates include:

• Camera frames
• Image buffers
• Audio sample buffers
• Large arrays
• Machine-learning tensor arenas
• Large strings
• JSON documents
• Network receive buffers
• Temporary file buffers

For example, an ESP32-S3 used for TinyML may need hundreds of kilobytes just for model tensors and intermediate data. Moving this kind of bulk data to PSRAM leaves more internal SRAM available for the rest of the application. A 300 KB buffer might consume an uncomfortable amount of internal RAM. Put the same bulk data in PSRAM and you preserve internal memory for the operating system, Wi-Fi, task stacks, and peripherals.

PSRAM Is Not Just More Internal SRAM

An ESP32-S3 with 8 MB of PSRAM does not behave like a microcontroller with 8 MB of internal SRAM. External PSRAM sits behind the ESP32-S3's memory interface and cache. Frequently accessed data can perform reasonably well, but large accesses eventually exceed what the cache can hide. Use PSRAM when capacity matters. Keep frequently accessed or timing-sensitive data in internal SRAM. There is little benefit in moving small variables to PSRAM just because it is available. Use PSRAM for the large objects that actually justify it.

Some Data Still Needs Internal RAM

Some data cannot or should not be placed in PSRAM. Peripheral and DMA operations can have additional memory requirements. Some hardware structures must remain in internal memory even if the main data buffer lives in PSRAM. FreeRTOS task stacks are also normally kept in internal RAM.

PSRAM and external flash also share parts of the ESP32-S3 external-memory and cache system. This becomes relevant if you are writing lower-level code, performing flash operations, or debugging difficult timing-related crashes. This usually does not matter for a simple image or data buffer, but it matters more in drivers, networking, DMA, flash operations, and real-time applications.

A practical rule is:

Monitoring PSRAM While Your Program Runs

A memory leak or fragmentation problem may not become visible until the program has been running for a while. For debugging, I find it useful to periodically print both free PSRAM and the largest allocatable block.

void printPsramStatus() {
  Serial.print("Free PSRAM: ");
  Serial.print(ESP.getFreePsram() / 1024);
  Serial.println(" KB");

  Serial.print("Largest block: ");
  Serial.print(ESP.getMaxAllocPsram() / 1024);
  Serial.println(" KB");

  Serial.print("Minimum free PSRAM: ");
  Serial.print(ESP.getMinFreePsram() / 1024);
  Serial.println(" KB");
}

Call this at different stages of your program.

For example:

printPsramStatus();

camera.begin();

printPsramStatus();

loadModel();

printPsramStatus();

Comparing these readings shows which initialization step consumed the PSRAM. getMinFreePsram() records the lowest free-PSRAM level reached since boot. A temporary allocation might have already been released by the time you check the Serial Monitor, but the minimum value can reveal that memory usage briefly spiked.

Why Can an Allocation Fail When PSRAM Is Still Free?

Suppose your Serial Monitor says:

Free PSRAM: 1300 KB

Then this fails:

ps_malloc(1024 * 1024);

The reason becomes clear when you check the largest allocatable block.

Check:

ESP.getMaxAllocPsram()

You may discover something like:

Free PSRAM:       1300 KB
Largest block:     800 KB

The allocator has 1.3 MB available overall, but there is no single 1 MB continuous region. This can happen after many differently sized allocations and frees. If your application depends on a very large buffer, allocate it early during startup rather than waiting until the heap has been used heavily. If your application needs one large buffer, allocate it early before repeated allocations fragment the heap.

ESP32-S3 PSRAM Troubleshooting

PSRAM Size Shows 0 Bytes

First check:

psramFound()

If that also returns false, verify the Arduino IDE PSRAM configuration.

For R2 devices:

Tools > PSRAM > QSPI PSRAM

For R8 devices:

Tools > PSRAM > OPI PSRAM

Also confirm that your ESP32-S3 variant actually contains PSRAM.

The Board Keeps Rebooting

An incorrect flash or PSRAM mode can prevent some ESP32-S3 boards from starting correctly. Check the exact chip or module marking rather than guessing based on the development-board name.

ps_malloc() Returns NULL

Print:

ESP.getFreePsram()
ESP.getMaxAllocPsram()

The largest available block may be smaller than the buffer you are requesting. Also make sure the result of every allocation is checked before using the pointer.

My 2 MB Board Shows Slightly Less Than 2 MB Free

That is normal. ESP.getPsramSize() reports the total detected PSRAM, while ESP.getFreePsram() tells you how much remains available after system initialization and allocations. Don't use the free-memory value to identify how much memory is physically there.

I Allocated 1 MB. Does That Mean My Board Has 1 MB PSRAM?

No.

It only proves that the allocator successfully found a 1 MB continuous block.

Use:

ESP.getPsramSize()

to determine the total detected PSRAM.

Putting It All Together

I use the following sketch as a quick PSRAM check on a new ESP32-S3 board:

void setup() {
  Serial.begin(115200);
  delay(2000);

  Serial.println();
  Serial.println("ESP32-S3 PSRAM Check");
  Serial.println("====================");

  if (!psramFound()) {
    Serial.println("PSRAM: NOT DETECTED");
    return;
  }

  Serial.println("PSRAM: DETECTED");

  Serial.printf(
    "Total PSRAM: %.2f MB\n",
    ESP.getPsramSize() / 1024.0 / 1024.0
  );

  Serial.printf(
    "Free PSRAM: %.2f MB\n",
    ESP.getFreePsram() / 1024.0 / 1024.0
  );

  Serial.printf(
    "Largest block: %.2f MB\n",
    ESP.getMaxAllocPsram() / 1024.0 / 1024.0
  );

  const size_t testSize = 1024 * 1024;

  uint8_t *testBuffer = (uint8_t *)ps_malloc(testSize);

  if (testBuffer != NULL) {
    Serial.println("1 MB allocation: PASS");
    memset(testBuffer, 0x55, testSize);
    Serial.println("1 MB write: PASS");
   free(testBuffer);
  } else {
    Serial.println("1 MB allocation: FAIL");
  }
}

void loop() {
}

From this output I can verify that PSRAM is detected, see the total and available memory, check the largest block, and confirm that a reasonably large buffer can actually be allocated.

Conclusion

PSRAM is useful when an ESP32-S3 project needs large image, audio, machine-learning, or network buffers. It should not be treated the same as internal SRAM. First, make sure your particular ESP32-S3 actually contains PSRAM. Then configure the correct QSPI or OPI mode in Arduino IDE and verify it using psramFound() and ESP.getPsramSize(). After that, functions such as ps_malloc() make it straightforward to place large buffers in external memory.

My testing showed why total memory, free memory, and largest allocatable memory are three different things. Checking all three usually makes allocation problems much easier to trace.

In the next experiment, I will take this a step further and compare ESP32-S3 internal SRAM against PSRAM, including allocation size, read/write speed and what happens as the working buffer becomes larger.

The post ESP32-S3 PSRAM: How to Enable, Detect and Use It in Arduino appeared first on Teach Me Microcontrollers!.

For PIC microcontrollers, one of the easiest ways to program a device is through Microchip's PICkit programmer/debugger.

PICkit Versions

Microchip has released several generations of the PICkit programmer. The original version of this article stopped at PICkit 4, which was released in 2018. Since then, Microchip has introduced PICkit 5, which is now the current version.

PICkit 1

The original PICkit 1 Flash Starter Kit appeared in the early 2000s and was aimed mainly at beginners working with Microchip's small 8-pin and 14-pin Flash PIC microcontrollers. It consisted of a development board connected to a computer through USB. Compared to current programmers, device support was very limited, but the important thing was that it provided an inexpensive USB-based way to start programming PIC devices. Today, PICkit 1 is mainly of historical interest. Microchip no longer recommends it for new development.

PICkit 2

PICkit 2 was a major improvement and became very popular among PIC hobbyists. Unlike the first PICkit, it could program a much wider variety of PIC microcontrollers using ICSP or In-Circuit Serial Programming. One useful feature was its standalone PICkit 2 Programmer software. You could select a HEX file, connect a target PIC and program it without opening an entire MPLAB project. PICkit 2 also included some useful extra tools, including a UART terminal. However, both its software and supported-device list are now considered legacy. Microchip keeps the old PICkit 2 software in its development-tool archive.

PICkit 3

PICkit 3 replaced PICkit 2 and provided closer integration with MPLAB and later MPLAB X IDE. PICkit 3 can both program and debug compatible PIC microcontrollers. Debugging is particularly useful because you can stop your program at a breakpoint, inspect registers and variables, execute instructions step by step, and then continue running the program. You will still find plenty of PICkit 3 programmers and inexpensive clones for sale. They work well with many older PIC devices, including microcontrollers such as the PIC16F84A and PIC16F877A. However, Microchip stopped adding new device support to PICkit 3 on June 1, 2019, so I would not recommend buying one for a new development setup unless you specifically need it for older PICs.

PICkit 4

Microchip introduced the MPLAB PICkit 4 on February 27, 2018, as the replacement for PICkit 3. The PICkit 4 increased programming speed considerably, supported a wider target-voltage range and added support for more programming and debugging interfaces. Microchip stated that it could program devices up to five times faster than PICkit 3. PICkit 4 was an excellent programmer and remains perfectly usable if you already own one. However, Microchip now lists it as an archived programmer that is no longer available as its current development tool.

PICkit 5

The current version is the MPLAB PICkit 5 In-Circuit Debugger/Programmer, released in May 2023. PICkit 5 supports not only PIC and dsPIC devices but also Microchip's AVR, SAM, and Arm-based devices. It connects to the computer through USB Type-C and works with MPLAB X IDE and MPLAB IPE. Another interesting feature is its Programmer-to-Go capability. PICkit 5 can work with Microchip's mobile Programmer-to-Go application through Bluetooth Low Energy, making it possible to program devices in the field without keeping the programmer connected to a PC.

Here's a quick comparison:

For a new setup today, PICkit 5 is the obvious choice. If you already have a PICkit 3 or PICkit 4 and your PIC microcontroller is supported, however, there is no reason you can't continue using it.

How PICkit Programs a PIC Microcontroller

PICkit programmers normally use ICSP, which stands for In-Circuit Serial Programming.

The advantage of ICSP is right there in the name: you can program the microcontroller while it is already installed in your circuit. You don't need to remove the PIC and put it into a separate programming socket every time you change your program.

For most traditional PIC microcontrollers, five important connections are involved:

The exact pins on the PIC microcontroller vary according to the device, so always check its datasheet before connecting your programmer. Microchip recommends a typical pull-up resistor of around 10 kΩ between MCLR and VDD. You should also avoid putting large capacitors or other circuits directly on the PGC and PGD lines because they may interfere with programming signals.

Connecting PICkit to a PIC16F84A

Let's use the PIC16F84A from our previous tutorials as an example. For the 18-pin PDIP version of the PIC16F84A, the ICSP connections are:

The PIC16F84A supports ICSP through RB6 and RB7, so the device can remain installed on your breadboard or PCB while you program it.

Make sure you also connect the normal power and oscillator circuitry required by the PIC16F84A. One detail that often confuses beginners is target power. The PIC can either be powered by your circuit or, depending on the programmer and configuration, supplied from the programmer. For normal development, I prefer powering the target circuit from its own regulated supply and allowing the PICkit to sense that voltage. Microchip also recommends external target power for its normal debugger connection.

Most importantly, never apply a supply voltage higher than the maximum allowed by your particular PIC microcontroller.

What is a HEX File?

When you write a PIC program in assembly language or C, the microcontroller doesn't directly understand your source code.

The assembler or compiler first converts your program into machine instructions. The build process then generates a HEX file containing the data that will eventually be written to the PIC's program memory.

For example, if your MPLAB project is called:

blink.X

building that project may produce a file similar to:

blink.X.production.hex

You don't normally need to open or edit this file manually. You simply give it to the programmer.

The PICkit then transfers the contents of the HEX file into the microcontroller's Flash program memory.

Loading a HEX File Using MPLAB IPE

For programming an existing HEX file, the easiest current method is MPLAB IPE, or Integrated Programming Environment. MPLAB IPE installs together with MPLAB X IDE. Unlike the full IDE, IPE concentrates on programming devices rather than writing and compiling programs. Microchip itself recommends IPE when you already have a HEX file that you simply want to program into a device.

Here's the complete process:

1. Install MPLAB X IDE and MPLAB IPE. Download the current MPLAB X installer from Microchip and make sure MPLAB IPE is selected during installation. Connect your PICkit to the computer afterward.

2. Connect the PICkit to your target PIC. Wire MCLR/VPP, VDD, VSS, PGD, and PGC correctly. Pay particular attention to the Pin 1 marker on the PICkit connector.

3. Power the target circuit. If your board uses its own power supply, turn it on before attempting to connect. The PICkit needs to detect the target supply voltage.

4. Open MPLAB IPE. Select the correct device family and then select the exact PIC microcontroller. For our example, this would be PIC16F84A.

5. Select the programmer. Choose the connected PICkit from the Tool field and click Connect. The Output window should indicate that the programmer has connected and the target has been detected.

6. Load the HEX file. Select File > Import > Hex, browse to your compiled `.hex` file and open it. IPE should display a message indicating that the HEX file loaded successfully.

7. Click Program. MPLAB IPE erases the required memory locations, writes your program and verifies the contents afterward.

8. Check the result. A successful operation produces a Programming/Verify complete message in the Output window.

9. Run your circuit. Disconnect the programmer if necessary or simply reset/power-cycle the PIC. Your program should now execute from Flash memory.

If you're using the LED-blinking program from our earlier PIC16F84A tutorial, the LED should now start blinking exactly as it did in the simulator—except this time the code is running on a real PIC microcontroller.

Programming Directly from MPLAB X IDE

If you are actively writing the program yourself, you don't actually have to export the HEX file and manually open MPLAB IPE every time. MPLAB X IDE can build and program the device directly.  After connecting the PICkit, open your project properties and select the PICkit as your hardware tool. Build the project and use the Make and Program Device command. MPLAB X will compile the project, create the HEX file internally, and immediately send it to the PICkit.

This gives us two slightly different workflows:

For beginners learning PIC assembly or XC8 programming, you will probably spend most of your time in MPLAB X and only use IPE when you need to program an existing HEX file.

Common PICkit Programming Problems

Target Device Not Detected

This is probably the most common PICkit error. First, make sure the PIC has power. Then verify the VSS connection and check that the PICkit's Pin 1 is connected to MCLR/VPP rather than accidentally reversing the connector. Also verify that you selected the correct PIC model in MPLAB.

Failed to Program Device

Check the PGC and PGD wiring. These are the two lines carrying the actual programming clock and data. Circuits connected to these pins can also interfere with ICSP. Large capacitors are particularly problematic because they slow the edges of the programming signals.

Wrong Device ID

If MPLAB reports a device ID different from what it expects, confirm that the selected PIC model matches the physical device on your breadboard. For example, don't select PIC16F84A if you actually installed a PIC16F628A.

PIC Works in the Programmer but Not After Disconnecting It

If programming succeeds but your application doesn't run afterward, check the rest of the target circuit. The PIC may need an oscillator, proper configuration bits, MCLR pull-up, power-supply decoupling, and other supporting components depending on the device. The programmer only guarantees that your program was written correctly. It cannot fix an incorrectly wired target circuit.

PICkit 3 Cannot Program a Newer PIC

This can simply be a device-support issue. PICkit 3 hasn't received support for new devices since 2019. If you are working with a newer Microchip device, use PICkit 5 or another currently supported Microchip programmer instead.

Which PICkit Should You Buy?

If you are buying a programmer today, I recommend PICkit 5. It provides current device support and works with the latest Microchip development tools. It also gives you debugging capabilities, which become increasingly valuable as your programs grow more complicated.

If you already have a genuine PICkit 4, keep using it as long as your target device remains supported.

PICkit 3 is still useful for learning with older devices such as the PIC16F84A, PIC16F628A, and PIC16F877A, especially if you already own one. However, I wouldn't purchase PICkit 3 specifically for a new collection of Microchip devices because its supported-device list is effectively frozen.

Conclusion

At this point, we have completed the whole basic PIC development cycle. We write our program in assembly or C, compile it into machine code, generate a HEX file, and finally use a programmer such as PICkit to transfer that program into the microcontroller. The important part to remember is that modern PIC programmers use ICSP, allowing you to program the PIC without removing it from your circuit. Once you have MCLR/VPP, VDD, VSS, PGD and PGC wired correctly, programming becomes a straightforward process.

For an existing HEX file, use MPLAB IPE. If you're developing the program yourself, you can program the device directly from MPLAB X IDE. From here, the PIC is finally ready to leave the simulator and start controlling real hardware. If you're following my PIC16F84A tutorials, the next step is to start writing more useful programs and learn how the PIC executes assembly-language instructions.

The post How to Program a PIC Microcontroller with PICkit and MPLAB IPE appeared first on Teach Me Microcontrollers!.

There is one problem: documentation for these generic Super Mini boards is often incomplete. Different online sellers sometimes show different pin diagrams, memory specifications, and even different onboard LED connections.

In this guide, I will show you how to set up the ESP32-S3 Super Mini in the Arduino IDE, identify the hardware you actually received, test its flash and PSRAM, and control the onboard RGB LED. We will also look at the pinout and some common upload problems.

What is the ESP32-S3 Mini?

The ESP32-S3 Super Mini is a small third-party development board built around the ESP32-S3 microcontroller. The ESP32-S3 itself uses two Xtensa LX7 CPU cores running at up to 240 MHz and includes 2.4 GHz Wi-Fi and Bluetooth Low Energy.

The particular Super Mini version commonly sold online uses an ESP32-S3FH4R2. The letters at the end are important:

• F - the chip contains flash memory.
• H4 - 4 MB of flash is integrated into the package.
• R2 - 2 MB of PSRAM is integrated into the package.

This makes the small board considerably more capable than its physical size suggests. In particular, the PSRAM can be useful for frame buffers, image processing, web applications, and other programs that need more working memory than the ESP32-S3's internal RAM can comfortably provide.

However, not every board advertised as an "ESP32-S3 Mini" necessarily contains the same chip. Before relying on the memory specifications printed by a seller, I recommend checking the marking on the ESP32-S3 itself and then verifying the memory through software.

ESP32-S3 Mini vs ESP32-S3-MINI-1

There is also an official Espressif product named the ESP32-S3-MINI-1. Do not confuse this with the ESP32-S3 Super Mini development board shown in this tutorial.

The ESP32-S3-MINI-1 is an Espressif module intended to be soldered into another PCB. The ESP32-S3 Super Mini, meanwhile, is a complete development board with a USB-C connector, voltage regulator, buttons, and exposed pins.

Online stores sometimes shorten both names to "ESP32-S3 Mini", which is why the terminology can be confusing.

ESP32-S3 Super Mini Specifications

For the common ESP32-S3FH4R2-based version, the important specifications are:

The 3.3 V logic level is worth remembering. Do not apply 5 V directly to an ESP32-S3 GPIO pin.

ESP32-S3 Super Mini Pinout

The compact Super Mini board exposes fewer pins than a full-size ESP32-S3 development board. This is one of the compromises required to make the board so small.

The version used for this guide has GPIO1 through GPIO13 together with the default UART TX and RX pins.

*GPIO48 is commonly used for the RGB LED on this Super Mini layout. Generic boards can vary, so check your board if the RGB example later in this guide does not work.

Where are GPIO19 and GPIO20?

The ESP32-S3 has native USB support. GPIO19 and GPIO20 can serve as the USB D- and D+ signals, respectively. On this board, the USB-C connector already uses the ESP32-S3's USB interface, so these pins are not presented like ordinary header pins.

This native USB connection is one of the reasons the Super Mini can be made so small: it does not necessarily need a separate CH340, CP2102, or other USB-to-UART converter.

Which Pins Should Beginners Use?

For initial projects, I would start with GPIO1, GPIO2, GPIO4, GPIO5, GPIO6, GPIO7, GPIO8, GPIO9, GPIO10, GPIO11, GPIO12 or GPIO13.

GPIO3 is usable, but it is also one of the ESP32-S3's strapping pins. A circuit that forces an inappropriate logic level on a strapping pin during reset can change the way the microcontroller boots.

Installing ESP32-S3 Support in Arduino IDE

If you have already programmed another ESP32 board using the Arduino IDE, you may already have Espressif's Arduino core installed. Otherwise, install the ESP32 package using the Arduino IDE's Boards Manager.

1. Open the Arduino IDE.
2. Open Boards Manager.
3. Search for esp32.
4. Install the package published by Espressif Systems.
5. Restart the Arduino IDE if necessary.

The generic Super Mini normally does not have its own entry in the Arduino board list. Instead, select:

Tools > Board > ESP32 Arduino > ESP32S3 Dev Module

This gives us access to the configuration options needed for the S3.

Recommended Arduino IDE Settings

For a common ESP32-S3FH4R2 Super Mini, I recommend starting with these settings:

QSPI PSRAM is especially important. The ESP32-S3FH4R2 contains 2 MB of Quad SPI PSRAM. Selecting the wrong PSRAM type can prevent the board from booting correctly or cause the PSRAM test to fail.

Why Enable USB CDC On Boot?

On many older ESP32 boards, a separate USB-to-serial IC creates the COM port. The ESP32-S3 can instead expose a serial interface directly through its internal USB hardware.

With USB CDC On Boot = Enabled, calls such as:

Serial.println("Hello");

can appear directly in the Arduino Serial Monitor through the USB-C connection.

If your sketch uploads correctly but the Serial Monitor remains completely blank, this setting is one of the first things I would check.

First Test: Serial Output

Before testing anything more complicated, let's confirm that the microcontroller can run a sketch and communicate with the computer.

void setup() {
  Serial.begin(115200);

  delay(2000);

  Serial.println();
  Serial.println("ESP32-S3 Super Mini is running!");
}

void loop() {
  Serial.println("Hello from ESP32-S3");
  delay(1000);
}

Upload the program and open the Serial Monitor at 115200 baud.

You should see something similar to:

ESP32-S3 Super Mini is running!
Hello from ESP32-S3
Hello from ESP32-S3
Hello from ESP32-S3

If this works, we have already confirmed three things: the ESP32-S3 is running, USB programming works and USB serial output works.

Testing the ESP32-S3 Mini Flash and PSRAM

One specification I would definitely verify on a generic ESP32-S3 Super Mini is its memory. Fortunately, Arduino gives us functions that can report the flash and PSRAM sizes directly.

Upload the following program:

#include <Arduino.h>

void setup() {
  Serial.begin(115200);
  delay(2000);

  Serial.println("ESP32-S3 Hardware Test");
  Serial.println("----------------------");

  Serial.print("Chip model: ");
  Serial.println(ESP.getChipModel());

  Serial.print("CPU cores: ");
  Serial.println(ESP.getChipCores());

  Serial.print("CPU frequency: ");
  Serial.print(ESP.getCpuFreqMHz());
  Serial.println(" MHz");

  Serial.print("Flash size: ");
  Serial.print(ESP.getFlashChipSize() / 1024.0 / 1024.0, 2);
  Serial.println(" MB");

  Serial.print("PSRAM detected: ");
  Serial.println(psramFound() ? "YES" : "NO");

  Serial.print("PSRAM size: ");
  Serial.print(ESP.getPsramSize() / 1024.0 / 1024.0, 2);
  Serial.println(" MB");

  Serial.print("Free PSRAM: ");
  Serial.print(ESP.getFreePsram() / 1024);
  Serial.println(" KB");
}

void loop() {
}

Expected Result for the ESP32-S3FH4R2 Version

On a Super Mini that really contains an ESP32-S3FH4R2, the important parts of the result should look approximately like this:

ESP32-S3 Hardware Test
----------------------
Chip model: ESP32-S3
CPU cores: 2
CPU frequency: 240 MHz
Flash size: 4.00 MB
PSRAM detected: YES
PSRAM size: 2.00 MB
Free PSRAM: 2045 KB

If the program reports PSRAM size: 0 MB, this does not immediately mean your board lacks PSRAM. First verify that:

Tools > PSRAM > QSPI PSRAM

is selected.

If PSRAM still does not appear, inspect the marking on the chip. A different ESP32-S3 variant may have been fitted to your board.

Experiment: Actually Allocating Data in PSRAM

Detecting PSRAM is useful, but I also wanted a test that actually writes data to it. The following experiment allocates a 1 MB buffer using PSRAM, fills it with data, and then checks whether the allocation succeeded.

#include <Arduino.h>

const size_t BUFFER_SIZE = 1024 * 1024;

void setup() {
  Serial.begin(115200);
  delay(2000);

  if (!psramFound()) {
    Serial.println("PSRAM not found.");
    return;
  }

  Serial.print("Free PSRAM before allocation: ");
  Serial.print(ESP.getFreePsram());
  Serial.println(" bytes");

  uint8_t *buffer = (uint8_t *)ps_malloc(BUFFER_SIZE);

  if (buffer == NULL) {
    Serial.println("1 MB PSRAM allocation FAILED.");
    return;
  }

  Serial.println("1 MB PSRAM allocation successful.");

  for (size_t i = 0; i < BUFFER_SIZE; i++) {
    buffer[i] = i & 0xFF;
  }

  bool passed = true;

  for (size_t i = 0; i < BUFFER_SIZE; i++) {
    if (buffer[i] != (i & 0xFF)) {
      passed = false;
      break;
    }
  }

  Serial.println(passed ?
                 "PSRAM read/write test PASSED." :
                 "PSRAM read/write test FAILED.");

  Serial.print("Free PSRAM after allocation: ");
  Serial.print(ESP.getFreePsram());
  Serial.println(" bytes");

  free(buffer);
}

void loop() {
}

For a working 2 MB PSRAM device, the 1 MB allocation should succeed. More importantly, the final verification confirms that the data written to the buffer can also be read back correctly.

A successful test should produce something similar to:

Free PSRAM before allocation: 2095103 bytes
1 MB PSRAM allocation successful.
PSRAM read/write test PASSED.
Free PSRAM after allocation: 1046511 bytes

This experiment also demonstrates why PSRAM is useful. A one-megabyte buffer would consume far too much of the ESP32-S3's normal internal RAM, while the external/in-package PSRAM gives memory-hungry applications much more room.

Using the ESP32-S3 Super Mini RGB LED

Another nice feature of many ESP32-S3 Super Mini boards is the onboard addressable RGB LED. On the version covered by this guide, the LED is a WS2812-compatible device connected to GPIO48.

An addressable RGB LED is different from three ordinary LEDs. Instead of supplying separate red, green, and blue signals, we send a digital data stream containing the required color.

Installing the NeoPixel Library

Open the Arduino Library Manager and install the Adafruit NeoPixel library.

Then upload this example:

#include <Adafruit_NeoPixel.h>

#define RGB_PIN 48
#define NUM_PIXELS 1

Adafruit_NeoPixel pixel(
  NUM_PIXELS,
  RGB_PIN,
  NEO_GRB + NEO_KHZ800
);

void setup() {
  pixel.begin();
  pixel.clear();
  pixel.show();
}

void loop() {
  // Red
  pixel.setPixelColor(0, pixel.Color(50, 0, 0));
  pixel.show();
  delay(1000);

  // Green
  pixel.setPixelColor(0, pixel.Color(0, 50, 0));
  pixel.show();
  delay(1000);

  // Blue
  pixel.setPixelColor(0, pixel.Color(0, 0, 50));
  pixel.show();
  delay(1000);

  // Off
  pixel.clear();
  pixel.show();
  delay(1000);
}

I deliberately limited the color values to 50 instead of the maximum 255. Full-brightness WS2812 LEDs can be surprisingly bright, and there is no reason to run the LED at maximum power for a simple test.

Expected RGB Test Result

The onboard LED should cycle through:

1. Red for one second
2. Green for one second
3. Blue for one second
4. Off for one second

What if GPIO48 Does Not Work?

The "Super Mini" name is used by multiple manufacturers, and not all board revisions are identical. Some ESP32-S3 boards use another GPIO for the addressable LED.

If the code runs but the LED remains dark:

• Check the seller's pinout for your exact board.
• Inspect the board for a WS2812-style LED.
• Try the GPIO number specified by the board manufacturer.
• Do not assume that every ESP32-S3 board uses GPIO48.

Testing Wi-Fi

Since the ESP32-S3 includes Wi-Fi, a quick network scan is another useful hardware test. It verifies that the radio and antenna are operating without requiring your Wi-Fi password.

#include <WiFi.h>

void setup() {
  Serial.begin(115200);
  delay(2000);

  WiFi.mode(WIFI_STA);
  WiFi.disconnect();
  delay(100);

  Serial.println("Scanning Wi-Fi networks...");

  int networks = WiFi.scanNetworks();

  if (networks == 0) {
    Serial.println("No Wi-Fi networks found.");
  } else {
    Serial.print(networks);
    Serial.println(" networks found:");

    for (int i = 0; i < networks; i++) {
      Serial.print(i + 1);
      Serial.print(": ");
      Serial.print(WiFi.SSID(i));
      Serial.print(" (");
      Serial.print(WiFi.RSSI(i));
      Serial.println(" dBm)");
    }
  }
}

void loop() {
}

The output will depend entirely on your location. A typical result might look like:

Scanning Wi-Fi networks...
13 networks found:
1: Stacey's_Wifi_2.4 (-65 dBm)
2: Stacey's_Wifi_2.4_EXT (-71 dBm)
3: innengarten_Guest (-82 dBm)
...

If the board can reliably find nearby 2.4 GHz networks, we now know that the basic radio system and onboard antenna are working.

ESP32-S3 Super Mini BOOT and RESET Buttons

The board normally provides two small buttons: BOOT and RESET.

The RESET button resets the ESP32-S3. The BOOT button is associated with the bootstrapping circuitry and is useful when manually forcing the chip into its firmware download mode.

Most uploads should work without touching either button. However, these buttons become useful if a program crashes early during startup, disables USB functionality or otherwise makes the normal upload process unreliable.

Manually Entering Download Mode

If the Arduino IDE cannot upload to the board, try the following:

1. Press and hold BOOT.
2. Press and release RESET.
3. Release BOOT.
4. Check the Arduino IDE's Port menu again.
5. Select the newly detected port.
6. Upload the sketch.

You can also try holding BOOT while connecting the USB cable.

Troubleshooting the ESP32-S3 Super Mini

No COM Port Appears

First try another USB cable. Some USB-C cables are intended only for charging and contain no data connections.

If the cable is good, manually enter download mode using the BOOT and RESET buttons. Then check whether a new serial device appears.

Sketch Uploads but Serial Monitor is Blank

Verify:

Tools > USB CDC On Boot > Enabled

Also make sure the Serial Monitor baud rate matches the value in:

Serial.begin(115200);

After changing USB-related settings, upload the sketch again.

PSRAM Reports 0 Bytes

Check:

Tools > PSRAM > QSPI PSRAM

Then rerun the memory test.

If PSRAM is still unavailable, read the ESP32-S3 chip marking. Your board may use a different variant than the common ESP32-S3FH4R2.

Board Resets After Enabling PSRAM

Make sure you did not select OPI PSRAM for an FH4R2 board. Its integrated 2 MB PSRAM uses Quad SPI, so select QSPI PSRAM.

RGB LED Does Not Light

GPIO48 is common for the ESP32-S3 Super Mini RGB LED, but board revisions differ. Verify the pinout supplied with your particular board.

Upload Suddenly Stops Working After Running a Sketch

Because the board uses the ESP32-S3's native USB interface, the USB connection is partly under the control of the microcontroller itself. A crashing application can therefore make the normal serial port disappear.

Use the BOOT/RESET procedure to enter the ESP32-S3 ROM downloader and recover the board.

Uploads Fail at High Speed

If uploads are unreliable, lower the upload speed. A lower setting takes slightly longer but can be more reliable with some computers, USB hubs and cables.

ESP32-S3 Super Mini Test Summary

Before using a generic development board in a larger project, I like to verify its important features instead of relying entirely on the seller's specifications. For the ESP32-S3 Super Mini, the tests in this guide cover most of the board's important hardware.

Is the ESP32-S3 Super Mini Worth Using?

The ESP32-S3 Super Mini is an interesting board because it gives you most of the important ESP32-S3 features without the size of a conventional development board.

Compared with smaller single-core ESP32 variants, the S3 gives you considerably more processing power. The common ESP32-S3FH4R2 version also includes 2 MB of PSRAM, which makes it particularly attractive for projects involving displays, large buffers, web interfaces, and other memory-intensive applications.

Native USB is another advantage. Besides normal serial communication, the ESP32-S3's USB hardware makes the chip suitable for projects involving USB devices. That creates possibilities beyond the usual Wi-Fi sensor and web-server projects.

The main disadvantage is documentation. "ESP32-S3 Super Mini" is not one tightly controlled board design, so a pinout or memory specification found online may not describe every version being sold.

Fortunately, we can verify most of the important details ourselves. Check the chip marking, run the flash and PSRAM test, confirm the RGB LED GPIO and keep a copy of the pinout for the exact board you own. Once those details are known, the ESP32-S3 Super Mini becomes a very capable compact development board for embedded and IoT projects.

The post ESP32-S3 Mini Getting Started Guide: Super Mini Pinout, Arduino IDE Setup, PSRAM and RGB LED appeared first on Teach Me Microcontrollers!.

The original Pico uses Raspberry Pi's RP2040, while the Pico 2 replaces it with the newer RP2350. The change brings faster processor cores, more RAM, twice the flash storage, hardware floating-point support, more Programmable I/O resources, optional RISC-V processing, and a considerably more advanced security architecture.

At the same time, Raspberry Pi intentionally kept the Pico 2 largely compatible with the original Pico. The physical board size and 40-pin layout remain familiar, which makes moving an existing project to the newer board relatively straightforward.

Let's take a closer look at the Raspberry Pi Pico vs Pico 2 and determine when the newer board is actually worth using.

Raspberry Pi Pico vs Pico 2 Specifications

The conventional peripheral count has not changed very much. Both boards still provide two UART controllers, two SPI controllers, two I2C controllers, three exposed ADC inputs, PWM, USB, and 26 multifunction GPIO pins.

The major improvements are inside the microcontroller.

RP2040 vs RP2350

The most important difference between the two boards is the microcontroller.

The original Raspberry Pi Pico uses the RP2040, Raspberry Pi's first microcontroller. It contains two Arm Cortex-M0+ processor cores running at up to 133 MHz, along with 264 kB of SRAM. The Raspberry Pi Pico 2 uses the newer RP2350. Its primary processors are two Arm Cortex-M33 cores running at up to 150 MHz, and the chip contains 520 kB of SRAM.

So the improvement isn't simply:

133 MHz → 150 MHz

The Cortex-M33 is also a much more capable processor architecture than the Cortex-M0+. This becomes important for applications involving signal processing, mathematical calculations, control algorithms, audio processing, encryption, and other CPU-intensive tasks.

Cortex-M0+ vs Cortex-M33

The Cortex-M0+ used by the RP2040 was designed as a small and efficient processor for embedded applications. It works extremely well for jobs such as:

• Reading sensors
• Driving displays
• Controlling motors
• Handling GPIO
• Running communication protocols
• General microcontroller projects

The Cortex-M33 used by the RP2350 belongs to a more advanced Arm architecture. Among other improvements, it provides DSP instructions, hardware floating-point support, and Arm TrustZone security features.

This means the Pico 2 can perform more useful work per clock cycle in many applications. The performance improvement is therefore greater than the relatively small increase from 133 MHz to 150 MHz might suggest.

Hardware Floating-Point Support

One particularly useful improvement is the addition of hardware floating-point support.

The RP2040 does not contain a dedicated floating-point unit. It can certainly perform floating-point calculations, but these operations rely on software routines and optimized functions provided by the platform.

The Cortex-M33 processors in the RP2350 include hardware support for single-precision floating-point calculations as well as DSP instructions.

This can matter when your program performs calculations involving:

sin()
cos()
sqrt()
PID calculations
digital filters
FFT
sensor fusion

For example, a simple sensor calculation such as:

temperature = adc_voltage * calibration_factor;

will work perfectly well on either board. However, an application continuously processing hundreds or thousands of floating-point calculations can benefit from the Pico 2's newer processor.

This makes the Pico 2 particularly interesting for robotics, audio processing, digital filtering, motion processing, and advanced control systems.

Almost Twice the RAM

The original Pico contains 264 kB of SRAM. The Pico 2 increases this to 520 kB. That's close to twice as much working memory.

RAM becomes important when your application needs to hold large amounts of temporary data such as:

• Display framebuffers
• Audio samples
• Sensor histories
• Image data
• Large arrays
• Filesystem buffers
• Large MicroPython objects

For a blinking LED or basic temperature sensor, 264 kB is already far more than necessary. For graphics, data acquisition, audio processing, or larger MicroPython applications, however, the additional RAM can make a noticeable difference.

Twice the Flash Storage

Raspberry Pi also doubled the onboard flash memory.

The original Pico comes with 2 MB of QSPI flash, while the Pico 2 provides 4 MB.

Flash stores your program together with other data included with the firmware.

Two megabytes is already generous for many embedded applications, but flash consumption can increase quickly when a project contains:

• Fonts
• Images
• Audio samples
• Lookup tables
• MicroPython modules
• Large application resources

The Pico 2 therefore gives considerably more room for an application to grow.

Pico 2 Can Also Run RISC-V

One of the most unusual features of the RP2350 is that it contains processors based on two different instruction-set architectures.

Alongside its two Cortex-M33 processors are two Hazard3 RISC-V cores.

The RP2350 can therefore be configured to operate using:

Dual Arm Cortex-M33

or

Dual Hazard3 RISC-V

This does not normally mean that you have four general-purpose processor cores available to your application at the same time. Instead, the RP2350 allows the system to use either the Arm pair or the RISC-V pair.

For most Pico 2 users, the Cortex-M33 processors will remain the normal choice.

For embedded developers interested in experimenting with RISC-V, however, the Pico 2 provides a particularly interesting development platform.

More Programmable I/O

Programmable I/O, or PIO, was one of the features that made the original RP2040 unusual. PIO uses small programmable state machines that can generate and receive digital signals without requiring constant attention from the main CPU. The original Pico provides eight PIO state machines.  The Pico 2 increases this to twelve PIO state machines.

PIO can be used for applications such as:

• WS2812 addressable LEDs
• VGA video generation
• Custom serial protocols
• Additional UART-like interfaces
• Precise pulse generation
• Logic analyzer inputs
• Unusual sensor interfaces

If your project makes heavy use of PIO, the Pico 2 gives you considerably more resources to work with.

Better Security

Security is another area where the RP2350 is substantially different from the RP2040.

The RP2350 adds a much more extensive security architecture, including features such as:

• Arm TrustZone for Cortex-M
• Secure boot capabilities
• SHA-256 acceleration
• True random number generation
• One-time-programmable storage
• Hardware support for isolating secure resources

For a hobby project blinking LEDs, these features may not matter at all.

For a commercial embedded product, however, they can become very useful.

For example, secure boot can help ensure that only authorized firmware runs on a device. Hardware cryptographic support can also help with authentication, device identity, and secure firmware updates.

Are Pico and Pico 2 Pin Compatible?

One of the best things about the Pico 2 is that Raspberry Pi retained the familiar 40-pin physical layout of the original Pico.

Both boards expose 26 multifunction GPIO pins, and normal peripheral connections can generally remain in the same locations.

For example, an existing circuit could contain:

Raspberry Pi Pico
      |
      +-- BME280 via I2C
      |
      +-- OLED via SPI
      |
      +-- Servo via PWM
      |
      +-- Push Button via GPIO

In many cases, the original Pico can simply be replaced with a Pico 2 without redesigning the surrounding circuit.

This compatibility is one of the strongest advantages of the second-generation board because an existing Pico design does not necessarily need to be rebuilt from scratch.

What About Existing Pico Programs?

Basic applications written using standard APIs are also relatively easy to move between the two boards.

For example, a simple MicroPython LED blink program looks familiar:

from machine import Pin
from time import sleep

led = Pin(25, Pin.OUT)

while True:
    led.toggle()

GPIO, I2C, SPI, UART, ADC, and PWM applications written through supported APIs generally require little or no modification.

Programs that directly manipulate RP2040 hardware registers are a different matter. Because the RP2350 is a different microcontroller, very low-level code may need to be updated.

For most Arduino, MicroPython, and Pico SDK projects, however, the transition is much easier.

Programming the Pico 2

The familiar Pico programming process remains.

Both boards can be programmed using C/C++ and MicroPython, and both support Raspberry Pi's UF2 drag-and-drop programming method.

Hold the BOOTSEL button while connecting the board to USB and the bootloader appears as a USB mass-storage device. You can then copy the appropriate UF2 firmware file to the board.

One important point is that firmware compiled for the RP2040 should not simply be assumed to work as RP2350 firmware. When downloading MicroPython or building C/C++ applications, select the correct Pico 2 target.

GPIO and Peripheral Comparison

Despite the much more capable processor, the conventional peripheral configuration remains familiar.

Moving to the Pico 2 therefore doesn't suddenly provide twice as many UART, SPI, or I2C controllers.

The biggest improvements are concentrated in the processor, RAM, flash storage, PIO subsystem, and security hardware.

Does the Pico 2 Have Wi-Fi?

No. The standard Raspberry Pi Pico 2 does not include Wi-Fi or Bluetooth.

Just as Raspberry Pi offers both Pico and Pico W boards based on the RP2040, there are separate Pico 2 and Pico 2 W boards based on the RP2350.

The family can therefore be viewed like this:

RP2040
 ├── Pico
 └── Pico W

RP2350
 ├── Pico 2
 └── Pico 2 W

If your project requires wireless networking, the Pico 2 W is the appropriate second-generation version.

When Does the Pico 2 Make a Difference?

For simple microcontroller projects, you may notice very little difference.

Consider a basic temperature display:

Sensor → I2C → Pico → Display

The RP2040 already has far more processing power than this application requires. Replacing it with a Pico 2 probably won't make the temperature reading appear noticeably faster.

Now consider a more complicated system:

Multiple Sensors
       |
       v
Signal Filtering
       |
       v
Sensor Fusion
       |
       v
PID Control
       |
       v
High-Speed Data Logging
       |
       v
Display Output

Here, the faster Cortex-M33 processors, hardware floating point, additional RAM, extra flash, and increased PIO resources can become useful.

The same is true for audio processing, robotics, graphics, real-time data acquisition, and other demanding embedded applications.

Should You Upgrade an Existing Pico Project?

Not necessarily.

If your existing Raspberry Pi Pico project already works reliably and isn't running out of CPU time, RAM, flash, or PIO resources, replacing the RP2040 board may provide no practical improvement.

A push button doesn't need a Cortex-M33 processor just to tell you whether it has been pressed.

The Pico 2 becomes worthwhile when the limitations of the original Pico actually start becoming relevant.

Which One Should You Choose?

Choose the Raspberry Pi Pico if:

• Your project consists mainly of ordinary sensor and GPIO tasks.
• The RP2040 already provides enough processing power.
• You don't need large amounts of RAM.
• You don't need advanced security features.
• Lowest possible board cost is important.

Choose the Raspberry Pi Pico 2 if:

• You need more CPU performance.
• You need more RAM or flash storage.
• Your program performs significant floating-point calculations.
• You are doing DSP or signal processing.
• You need additional PIO state machines.
• You want the RP2350 security features.
• You want to experiment with RISC-V.
• You want additional performance headroom for future expansion.

For a new project, the Pico 2 is generally the more capable choice when the small additional cost isn't an issue.

That doesn't make the original Pico obsolete. The RP2040 remains more than capable enough for a very large number of embedded applications.

Raspberry Pi Pico vs Pico 2: Final Thoughts

The Raspberry Pi Pico 2 represents a much more substantial upgrade than its nearly identical appearance suggests.

The change from RP2040 to RP2350 brings:

• Cortex-M33 processors instead of Cortex-M0+
• 150 MHz maximum clock instead of 133 MHz
• 520 kB RAM instead of 264 kB
• 4 MB onboard flash instead of 2 MB
• Hardware floating-point and DSP support
• Optional Hazard3 RISC-V processors
• 12 PIO state machines instead of 8
• A much more capable security architecture

At the same time, Raspberry Pi retained the familiar Pico form factor and external pin arrangement.

For simple embedded projects, the original Raspberry Pi Pico remains perfectly capable. But for applications involving signal processing, larger programs, robotics, graphics, security, or applications that simply need more room to grow, the Raspberry Pi Pico 2 is clearly the more capable platform.

The post Raspberry Pi Pico vs Raspberry Pi Pico 2: What's the Difference? appeared first on Teach Me Microcontrollers!.

There is an important catch. The APDS-9960 does not simply look at an object and return a value such as "red" or "green." It measures the red, green, blue, and overall light reaching the sensor. When we use it to identify the color of an object, what we are really measuring is light reflected from that object's surface.

This makes the light source, distance, and positioning of the sensor surprisingly important. In this tutorial, I will connect an APDS-9960 to an ESP32, read its RGB values, and test it on real colored objects. I will also show why getting consistent color detection requires more than just reading three numbers from the sensor.

How the APDS-9960 Detects Color

The APDS-9960 contains separate sensing channels for:

• Red light
• Green light
• Blue light
• Clear or overall light intensity

The sensor converts the amount of light detected by each channel into digital values that can be read by the ESP32 through I2C.

For example, when a red object is illuminated with white light, the surface tends to reflect more of the red wavelengths while absorbing more of the other visible wavelengths. Ideally, the red value measured by the APDS-9960 will therefore be higher than the green and blue values.

The basic arrangement looks like this:

This distinction is important. We are not directly measuring an intrinsic "color value" stored inside the object. We are measuring reflected light. Change the light source or the physical arrangement and the measured values can change too.

Why the Light Source Matters

For an object to be measured, there must first be enough visible light falling on it. The object then reflects part of that light toward the APDS-9960.

During my initial tests, simply placing a colored plastic folder near the APDS-9960 without deliberate illumination produced very low RGB values. Illuminating the plastic with the flashlight from a phone made the differences between the channels much easier to observe.

This gives us our first important rule when using the APDS-9960 for color detection:

Use a consistent light source.

A phone flashlight is perfectly adequate for experimentation, but a permanent project would be better served by one or more fixed white LEDs mounted at a known distance and angle from the target.

Relying entirely on room lighting can create problems. The readings taken during daytime near a window may be different from readings taken at night under a warm-white lamp. Even two apparently white light sources can have significantly different spectral characteristics.

The APDS-9960 does contain an integrated infrared LED, but that LED is intended for its proximity and gesture functions. Infrared illumination is not a substitute for a visible white light source when we want to determine the visible color of an object.

Why Sensor Positioning Matters

The second thing that became obvious during testing was that positioning matters almost as much as illumination.

Changing the distance between the APDS-9960 and the object changes how much reflected light reaches the sensor. Changing the angle can also change the relative RGB readings, particularly when testing smooth or glossy materials.

There are actually several distances and angles that we should try to keep constant:

The effect becomes even more noticeable with transparent or semi-transparent objects. Light can travel through the material, reflect from whatever is behind it, and eventually reach the sensor. In this case, the background effectively becomes part of the measurement.

If your final project needs repeatable color detection, consider building a small fixture or enclosure that holds the sensor, light source, and target at fixed positions.

Connecting the APDS-9960 to ESP32

The APDS-9960 communicates through I2C. For a typical ESP32 development board, GPIO21 and GPIO22 can be used as SDA and SCL respectively.

GPIO21 and GPIO22 are only conventional I2C pins on the ESP32. Other GPIO pins can be assigned in software if necessary.

Also check the particular APDS-9960 breakout board you are using before applying power. The bare APDS-9960 is a low-voltage device, while some breakout boards add regulators or level shifting. For an unknown generic module, using 3.3 V is the safer starting point.

The APDS-9960 has a fixed I2C address of 0x39.

Installing the APDS-9960 Library

For this experiment, I used the Adafruit APDS9960 Library. In the Arduino IDE, open the Library Manager and search for:

Adafruit APDS9960

Install the library together with any dependencies requested by the Arduino IDE.

ESP32 APDS-9960 Color Sensor Code

The following sketch initializes the sensor, waits until new color data is available, and then reads the red, green, blue, and clear channels.

I also calculate normalized RGB values, which we will discuss shortly.

#include <Wire.h>
#include <Adafruit_APDS9960.h>

#define SDA_PIN 21
#define SCL_PIN 22

Adafruit_APDS9960 apds;

void setup()
{
  Serial.begin(115200);
  delay(1000);

  Serial.println();
  Serial.println("APDS-9960 Color Sensor Test");

  Wire.begin(SDA_PIN, SCL_PIN);

  if (!apds.begin())
  {
    Serial.println("APDS-9960 not found.");
    Serial.println("Check wiring and power.");

    while (1)
    {
      delay(1000);
    }
  }

  Serial.println("APDS-9960 detected.");

  // Increase sensitivity for reflected-light measurements
  apds.setADCIntegrationTime(100);
  apds.setADCGain(APDS9960_AGAIN_16X);

  // Enable RGB / ambient-light sensing
  apds.enableColor(true);
}

void loop()
{
  uint16_t red;
  uint16_t green;
  uint16_t blue;
  uint16_t clear;

  while (!apds.colorDataReady())
  {
    delay(5);
  }

  apds.getColorData(&red, &green, &blue, &clear);

  Serial.println("-------------------------");

  Serial.print("R: ");
  Serial.println(red);

  Serial.print("G: ");
  Serial.println(green);

  Serial.print("B: ");
  Serial.println(blue);

  Serial.print("C: ");
  Serial.println(clear);

  if (clear > 0)
  {
    float rNorm = (float)red / clear;
    float gNorm = (float)green / clear;
    float bNorm = (float)blue / clear;

    Serial.print("Normalized: R=");
    Serial.print(rNorm, 3);

    Serial.print(" G=");
    Serial.print(gNorm, 3);

    Serial.print(" B=");
    Serial.println(bNorm, 3);
  }

  delay(500);
}

I increased the ADC integration time and selected 16× gain because reflected-light measurements can sometimes be weak. A longer integration time allows the sensor to collect light for longer, while the higher gain increases sensitivity.

These values are not mandatory. In a brightly illuminated setup, the sensor may produce very large readings or saturate. If this happens, reduce the gain or integration time.

Testing a Red Plastic Folder

For my first test, I placed a red plastic folder in front of the APDS-9960 and illuminated it using the flashlight from a phone.

The ESP32 reported:

R: 7
G: 3
B: 3
C: 13
Normalized: R=0.538 G=0.231 B=0.231

The absolute values are quite small, but the important part is the relationship between the channels. The red channel is clearly stronger than both green and blue.

Even this simple experiment shows that the APDS-9960 can distinguish a strongly red surface.

Testing a Green Semi-Transparent Folder

I then replaced the red folder with a green semi-transparent plastic folder while using the same phone flashlight.

This time, I obtained:

R: 11
G: 29
B: 27
C: 72
Normalized: R=0.153 G=0.403 B=0.375

The green channel is the highest:

However, notice that the blue reading is also very close to green. The result is therefore not nearly as clear-cut as our red sample.

There are several possible contributors. The folder is semi-transparent, so some of the measured light can come through the plastic rather than only being reflected from its surface. The background behind the plastic can therefore affect the reading. The spectrum of the phone flashlight also affects the amount of red, green, and blue energy available for reflection or transmission.

The result still looks significantly different from the red sample, but it demonstrates why a single rule such as "the largest RGB value is the color" can easily become unreliable.

Why Normalize the RGB Values?

Suppose we move the light closer to the object. The raw red, green, and blue values may all increase even though the object's color has not changed.

One simple way of reducing the effect of overall brightness is to divide each RGB channel by the clear-channel reading:

$R_n = \frac{R}{C}$

$G_n = \frac{G}{C}$

$B_n = \frac{B}{C}$

For our red folder:

$R_n = \frac{7}{13} = 0.538$

$G_n = \frac{3}{13} = 0.231$

$B_n = \frac{3}{13} = 0.231$

The resulting ratios make the dominance of red easy to see.

Normalization is useful for simple object classification, but it should not be confused with full color calibration. It cannot completely compensate for a different light source, different viewing angle, reflections, transparency, or other changes to the optical setup.

Also be careful when the clear value is very small. For example, when C is only 10 or 20 counts, a change of just one ADC count represents a significant change in the calculated ratio. It is better to improve the illumination or sensor sensitivity than to build a classifier from extremely weak signals.

Raw RGB Values Versus Object Color

A common mistake when building a color detector is to assume that an object can be classified simply by finding the largest channel:

if (red > green && red > blue)
{
  // Must be red?
}

This can work for strongly separated colors under controlled conditions, but our green-folder experiment shows the problem. Green was 29 while blue was 27. Those values are too close for me to confidently build a universal rule around them.

A more practical system should first collect several measurements of every object or color that needs to be recognized.

For example:

Take multiple measurements instead of relying on only one reading. From these samples, you can establish ranges or thresholds that are appropriate for your particular hardware and mechanical arrangement.

Using a Confidence Margin

For simple experiments, another improvement is to require the winning color channel to exceed the others by a minimum amount.

For example:

String classifyColor(float r, float g, float b)
{
  const float margin = 0.08;

  if ((r - g > margin) && (r - b > margin))
    return "RED";

  if ((g - r > margin) && (g - b > margin))
    return "GREEN";

  if ((b - r > margin) && (b - g > margin))
    return "BLUE";

  return "UNSURE";
}

Our red folder would easily satisfy this type of test. The green translucent folder probably would not because its green and blue readings are very close. Returning UNSURE is usually better than confidently returning the wrong color.

The value of 0.08 here is only an example. A real threshold should come from measurements of your actual objects.

Improving APDS-9960 Color Detection

If I were turning this breadboard experiment into a real color-sensing project, I would make several changes.

1. Use a Fixed White LED

Instead of holding a phone flashlight by hand, mount a white LED at a fixed angle and distance from the target.

This gives every object approximately the same illumination and makes calibration much more meaningful.

2. Keep the Object at a Fixed Distance

A mechanical stop, slot, guide, or enclosure can make sure every sample appears at the same distance from the APDS-9960.

This is particularly useful for projects such as a color sorter where objects always travel through the same sensing position.

3. Control the Viewing Angle

Glossy plastic can produce strong specular reflections. A small change in angle may send much more or much less reflected light directly into the sensor.

Mounting the sensor and illumination mechanically eliminates much of this variation.

4. Control the Background

This becomes important when testing thin or translucent objects. Place an opaque and consistent backing behind the object if possible.

A white, black, or otherwise known background can produce much more repeatable measurements than whatever happens to be sitting behind the test object.

5. Average Several Measurements

Instead of classifying an object from one sample, take perhaps 5 to 20 readings and calculate an average.

This reduces the effect of occasional noisy readings and small changes in reflected light.

6. Avoid Extremely Low Signal Levels

If the clear reading is only a few counts, normalized values can become unstable. Increase illumination, increase integration time, increase gain, or move the object closer until the sensor produces a healthier signal.

At the other extreme, avoid saturating the sensor. If values approach their maximum range, reduce gain, integration time, or illumination.

Is the APDS-9960 a Good Color Sensor?

After experimenting with it, I would say yes, with some qualifications.

The APDS-9960 can definitely distinguish differences in reflected color. Our red sample produced a strongly dominant red channel, while the green sample produced a completely different RGB distribution.

However, I would use it primarily for color classification rather than precision color measurement.

Good applications include:

• Detecting whether an object is red, green, or blue
• Sorting a limited set of known colored objects
• Identifying colored markers or cards
• Educational experiments involving reflected light
• Adding simple color awareness to an ESP32 project

I would not expect an uncalibrated APDS-9960 sitting openly on a breadboard to accurately identify arbitrary colors under arbitrary room lighting.

The key is to treat the sensor, illumination source, object position, and background as one optical measurement system.

Final Thoughts

The APDS-9960 is much more than a gesture sensor. Its red, green, blue, and clear channels allow it to become a surprisingly useful color detector when connected to an ESP32.

The most important lesson from my tests, however, is that color sensing is really an optical-system problem. The APDS-9960 measures the light that reaches it. When detecting the color of an object, this is largely light that has been reflected from that object.

As a result, the light source matters. Distance matters. Angle matters. The background matters, and the material itself matters.

For a quick experiment, a phone flashlight and a hand-held sample are enough to prove that the sensor responds differently to different colors. For a reliable project, use fixed white illumination and keep the sensor, object, and light source in repeatable positions.

With those conditions controlled, the APDS-9960 becomes a good candidate for simple color classification projects such as object sorters, colored-card interfaces, educational experiments, and other ESP32 projects where only a limited set of known colors needs to be identified.

The post Using APDS-9960 as a Color Sensor with ESP32: Reflected Light and Positioning Matter appeared first on Teach Me Microcontrollers!.

The antenna connection is part of a carefully designed radio-frequency path. The antenna, connector, coaxial cable, PCB trace, matching components, and surrounding ground plane all affect how much of the ESP32's transmitted power is actually radiated.

In this tutorial, we will look at the safest ways of adding an external antenna to an ESP32. This includes choosing a module with a factory-installed U.FL connector, changing an antenna selection jumper, modifying an existing PCB, selecting the correct antenna, and positioning it inside the finished project.

Important: The antenna arrangement differs between ESP32 boards. Before moving or removing any component, find the schematic for your exact development board and inspect the RF section under magnification.

Why Add an External Antenna to an ESP32?

Most ESP32 development boards already contain a small meandered PCB antenna. For a board sitting openly on a desk, this antenna is often sufficient. Problems usually appear after the board is installed in the final product.

An external antenna may be useful when:

• The ESP32 is installed inside a metal enclosure.
• A battery, LCD, motor, relay, or large PCB is close to the built-in antenna.
• The device must communicate through several walls.
• The ESP32 is located near the edge of the access point's coverage.
• The product needs an antenna mounted outside its enclosure.
• The orientation of the built-in PCB antenna is unsuitable for the installation.
• A directional antenna is required for a fixed point-to-point link.

An external antenna does not automatically guarantee longer range. A badly positioned external antenna connected through a poor cable can perform worse than the original PCB antenna. The entire wireless link must be considered.

A simplified link budget can be written as:

$P_R = P_T + G_T + G_R - L_{path} - L_{cable} - L_{mismatch}$

Here, P_R is the received power, P_T is the transmitted power, G_T and G_R are antenna gains, and the remaining terms represent path, cable, and impedance mismatch losses.

This equation explains why installing a higher-gain antenna may not help when a long, lossy cable or an incorrectly modified RF trace introduces additional losses.

Understand Which Type of ESP32 Board You Have

The term “ESP32 board” can refer to the ESP32 chip, a shielded ESP32 module, or a complete development board. The antenna may be part of any one of these assemblies.

ESP32 Modules with External Antenna Connectors

Espressif sells several module families in separate PCB-antenna and external-antenna versions. Examples include:

The letter U commonly indicates an external-antenna connector in Espressif module names. However, this naming convention should not be assumed for every third-party board. Always verify the full module number printed on the metal shield.

A module such as the ESP32-WROOM-32UE does not contain the familiar meandered PCB antenna. Its RF output is routed directly to the small connector on the module. This is normally the easiest and most reliable option for adding an external antenna.

What Is a U.FL Connector?

U.FL is a miniature 50 Ω coaxial connector family made by Hirose. ESP32 sellers sometimes call the same connector an IPEX connector. More precisely, Espressif's first-generation external antenna connector is compatible with Hirose U.FL, I-PEX MHF I, and Amphenol AMC cable plugs.

These connectors are very small and should be handled carefully. The cable plug must be centered directly over the board receptacle and pressed vertically downward. When correctly connected, it should produce a small tactile click.

Do not press the connector at an angle. Doing so can bend the center contact or pull the receptacle away from the PCB.

Also be careful when ordering cables. I-PEX MHF I and MHF 4 are different connector families. An MHF 4 cable is smaller and should not be forced onto a first-generation U.FL or MHF I receptacle.

U.FL-to-SMA Pigtails

A common arrangement uses a short U.FL-to-SMA coaxial pigtail. The U.FL end connects to the ESP32 module, while the SMA end is mounted through the enclosure. A larger external whip antenna then screws onto the SMA connector.

This arrangement provides two advantages:

• The fragile U.FL connector remains protected inside the enclosure.
• The external antenna can be replaced without repeatedly disconnecting the U.FL plug.

Choose the SMA end carefully. SMA and reverse-polarity SMA connectors look similar but have different center contacts. Verify that the panel connector and antenna are compatible before ordering.

Method 1: Use an ESP32 Module with a Factory U.FL Connector

The best method is to begin with a board or module designed for an external antenna. Examples include development boards populated with an ESP32-WROOM-32UE, ESP32-S3-WROOM-1U, or ESP32-C3-WROOM-02U.

Parts Required

• ESP32 development board with an external-antenna module
• Compatible U.FL or MHF I cable assembly
• 2.4 GHz, 50 Ω antenna suitable for the module
• Optional U.FL-to-SMA bulkhead pigtail
• Plastic connector tool or fine nonmetallic tweezers

Connection Procedure

1. Disconnect USB power and any external power supply.
2. Confirm the connector type using the module datasheet.
3. Inspect the U.FL receptacle for contamination or damage.
4. Align the cable plug directly over the receptacle.
5. Press downward on the metal connector body rather than on the cable.
6. Route the cable so that it does not pull sideways on the connector.
7. Add strain relief to the cable several millimeters away from the receptacle.
8. Install the antenna before applying power.

Do not attach adhesive, epoxy, or hot glue directly over the connector until the connection has been tested. Strain relief should hold the cable to the main PCB without pulling on the RF receptacle.

Method 2: Move the ESP32 Antenna Selection Jumper

Some development boards contain both a PCB antenna and a U.FL-style connector. Only one path should normally be active. A small zero-ohm resistor or solder bridge connects the ESP32's RF feed to the selected antenna.

This arrangement is particularly common on some ESP32 camera boards and compact IoT development boards.

How the Three-Pad Selector Works

A typical selector contains three pads:

• The center pad is connected to the ESP32 RF output.
• One outside pad leads to the built-in PCB antenna.
• The other outside pad leads to the U.FL connector.

A zero-ohm resistor bridges the center pad to one of the two antenna paths. To select the external antenna, the resistor is removed from the PCB-antenna path and installed between the center pad and the connector path.

The arrangement is not identical on every board. The external path may be above, below, or beside the original jumper. Never assume that rotating the resistor by 90 degrees is correct without tracing the circuit.

Tools Required

• Fine-tip temperature-controlled soldering iron
• Fine soldering tweezers
• Flux
• Solder wick
• Magnification
• ESD-safe work surface
• Multimeter for checking shorts and continuity

Modification Procedure

1. Remove all power from the board.
2. Take a clear photograph of the original jumper position.
3. Identify the radio feed, PCB antenna route, and connector route from the schematic or PCB traces.
4. Apply a small amount of flux to the zero-ohm resistor.
5. Heat both ends evenly and lift the component with tweezers.
6. Clean the pads using solder wick if necessary.
7. Place the resistor between the RF feed pad and the external-connector pad.
8. Inspect the joint under magnification.
9. Check that the PCB antenna path is no longer connected.
10. Connect the external antenna before powering the ESP32.

A solder blob can sometimes be used instead of reinstalling the zero-ohm resistor, but it must not bridge all three pads. Connecting the PCB antenna and external antenna simultaneously creates an uncontrolled RF junction that can cause severe impedance mismatch.

A multimeter can identify an accidental short or open circuit, but it cannot prove that the RF path has a 50 Ω characteristic impedance at 2.4 GHz. Proper RF performance must be evaluated through signal, throughput, or network-analyzer testing.

Method 3: Add a Coaxial Connection to a Board Without U.FL

This is the most difficult method and should normally be used only for experimentation. If a standard ESP32-WROOM module already contains the PCB antenna, the RF path is part of the module itself. The carrier board does not usually provide a convenient antenna feed that can be modified.

For this type of board, replacing the complete module or development board with an external-antenna version is usually safer than cutting into the module's PCB antenna.

When a Direct PCB Modification Is Possible

A modification may be possible when:

• The RF feed trace is visible and accessible.
• The board contains an exposed matching network.
• The existing PCB antenna can be disconnected without disturbing the matching components.
• A nearby ground point is available for the coaxial shield.
• The modification is being performed on a prototype rather than a certified production product.

Why a Loose Wire Is Not Recommended

A common shortcut is to solder a random wire to the antenna feed. Although the wire may radiate some RF energy, it does not provide a controlled 50 Ω connection. The exposed section of wire, ground geometry, nearby objects, and solder joint all become part of the antenna.

The free-space wavelength at 2.4 GHz is approximately:

$\lambda = \frac{c}{f} \approx 125\text{ mm}$

A free-space quarter wavelength is therefore approximately:

$\frac{\lambda}{4} \approx 31\text{ mm}$

This does not mean that soldering a 31 mm wire to the ESP32 will produce a properly matched antenna. Practical antennas are affected by conductor width, ground plane dimensions, dielectric material, enclosure, loading, and nearby components.

Recommended Direct-Modification Approach

When a direct modification is unavoidable, use a short length of 50 Ω micro-coaxial cable rather than an unshielded wire.

1. Locate the antenna feed and matching network.
2. Determine which side of the series component is connected to the radio.
3. Remove the jumper or cut the trace leading to the built-in antenna.
4. Solder the coaxial cable's center conductor to the radio-side RF feed.
5. Solder the coaxial shield to ground immediately beside the feed point.
6. Keep the exposed center conductor extremely short.
7. Secure the cable to the PCB so movement does not pull on the RF pad.
8. Terminate the other end at a proper U.FL, SMA, or other 50 Ω connector.

The shield connection is as important as the center conductor. A long shield lead creates inductance and can make an otherwise short connection behave poorly at 2.4 GHz.

Do not scrape or cut the antenna trace while the board is powered. Avoid excessive heat because small RF pads can separate easily from the PCB.

Designing an External Antenna Connection on a Custom ESP32 PCB

If you are creating a custom ESP32 board, the RF connection should be designed into the PCB rather than added afterward.

The RF trace between the matching network and antenna connector should have a characteristic impedance of approximately 50 Ω. The correct trace width depends on:

• PCB dielectric thickness
• Copper thickness
• Dielectric constant
• Distance to the reference ground plane
• Whether the trace is microstrip or coplanar waveguide
• Spacing between the trace and surrounding ground copper

Because these values depend on the PCB manufacturer's stack-up, copying the RF trace width from another board does not guarantee the correct impedance.

RF Layout Guidelines

• Keep the RF trace as short as possible.
• Do not create branches or stubs in the antenna path.
• Keep the trace width consistent.
• Avoid routing the RF trace through vias.
• Maintain a continuous ground reference beneath the trace.
• Use ground vias along the sides of a coplanar RF trace.
• Keep crystals, high-speed clocks, USB lines, UART lines, and switching regulators away from the antenna section.
• Place the matching network close to the ESP32 RF output or antenna as directed by the reference design.
• Keep copper and signal traces away from the connector area where required by the connector footprint.
• Include a pi or CLC matching footprint even when the initial design uses zero-ohm or unpopulated components.

The matching network gives you a way to compensate for the final PCB, connector, enclosure, and antenna during RF testing. The correct matching values normally require a vector network analyzer or equivalent RF measurement setup.

Choosing the Correct ESP32 External Antenna

The antenna must match the radio, connector, installation, and certification requirements of the exact ESP32 module.

Frequency

Common ESP32, ESP32-C3, and ESP32-S3 modules operate their Wi-Fi and Bluetooth radios in the 2.4 GHz band. A 2.4 GHz Wi-Fi or Wi-Fi/Bluetooth antenna is therefore required for these modules.

Do not select an antenna only because it physically fits the connector. An antenna intended only for GPS, cellular, LoRa, or sub-GHz operation may have very poor performance at 2.4 GHz.

For newer ESP32 variants supporting additional radio bands, use an antenna specified for every band that the design will use.

Impedance

The antenna and cable should have a nominal impedance of 50 Ω. This matches the RF system used by the ESP32 module and standard Wi-Fi antenna assemblies.

Antenna Gain

Higher gain does not mean that the antenna generates additional power. It concentrates radiation in particular directions while reducing it in others.

For example, a vertical high-gain whip may provide more horizontal coverage but create weaker areas directly above or below the antenna. A low-gain antenna may produce a more useful radiation pattern for a device whose orientation changes.

Certification must also be considered. Some Espressif external-antenna module datasheets specify the antenna used during certification and recommend that replacement antenna gain not exceed that value. The ESP32-WROOM-32UE and ESP32-S3-WROOM-1U documentation, for example, specifies a 2.4 GHz, 50 Ω antenna and lists 2.33 dBi as the certification antenna's maximum gain.

That value should not automatically be applied to every ESP32 module. Check the datasheet and certification documents for your exact part number. Using a different antenna type or higher gain may require additional EMC or regulatory testing.

External Whip Antenna

A screw-on whip antenna is useful when the antenna can be mounted outside the enclosure. It is easy to replace and can be oriented after installation.

Adhesive FPC Antenna

An adhesive flexible antenna can be installed inside a plastic enclosure. It should be mounted according to the antenna manufacturer's instructions. Some flexible antennas are designed to operate against a specific ground plane, while others require clearance from metal.

Do not fold, cut, or sharply bend the active antenna section. The coaxial cable may usually be routed around the enclosure, but the radiating element should remain in its intended shape.

PCB Antenna

A separate PCB antenna can be connected through a coaxial cable and mounted away from the ESP32 board. As with an FPC antenna, the antenna's ground-plane and clearance requirements must be followed.

Directional Antenna

A patch, panel, or Yagi-style antenna may be useful for a fixed point-to-point connection. It must be aimed correctly and may not be suitable for devices that move or need coverage in several directions.

ESP32 Antenna Placement

Antenna placement is often more important than antenna gain. Moving an ordinary antenna away from metal and electrical noise can produce a greater improvement than replacing it with a higher-gain antenna in the same poor location.

Keep the Antenna Away from Metal

Metal close to an antenna can block radiation and change its resonant frequency. Avoid placing the antenna directly against:

• Metal enclosures
• Large batteries
• Heat sinks
• LCD frames
• Metal mounting plates
• Large connectors
• Shielding cans

When using a metal enclosure, mount the antenna outside through a bulkhead connector. The coaxial cable can pass through the wall while the antenna remains in free space.

Keep the Antenna Away from Noise Sources

Switching regulators, DC motors, relays, high-speed displays, USB circuits, memory buses, and digital clocks can introduce interference. Place the antenna and its cable away from these circuits whenever possible.

Do not route the antenna cable parallel to high-current motor or relay wiring. If the paths must cross, crossing at approximately 90 degrees is generally preferable to running them together.

Respect the PCB Antenna Keepout Area

When using an ESP32 module's built-in PCB antenna, place the antenna end at the edge of the carrier PCB. Allowing the antenna to extend beyond the edge is usually the preferred arrangement.

If the antenna cannot extend past the board, there should be no copper, traces, or components under or beside the active antenna region. Espressif recommends providing at least 15 mm of clearance around the PCB antenna inside the finished enclosure.

The exact keepout geometry should come from the hardware design guide for the selected module.

Consider Polarization

A straight whip antenna normally has linear polarization. For communication with a typical access point whose antennas are vertical, starting with the ESP32 antenna vertically oriented is reasonable.

Rotating one antenna by 90 degrees relative to the other can reduce the received signal. Reflections inside buildings may reduce or change this effect, so the final orientation should still be tested experimentally.

Do Not Coil the Cable Around the Antenna

Extra coaxial cable should be routed away from the radiating element. Do not wrap it tightly around the whip or place a coil directly behind an adhesive antenna. The cable shield and nearby conductive objects can alter the antenna pattern.

Test the Finished Enclosure

An antenna that performs well on an open workbench may behave differently after the enclosure, battery, display, and wiring are installed. Always evaluate the complete assembled product.

Testing the ESP32 Antenna Modification

Test the original antenna before making the modification so that you have a baseline. Use the same ESP32 board, access point, location, power supply, orientation, and firmware for both tests.

Useful measurements include:

• Average RSSI
• Packet loss
• Connection and reconnection time
• TCP or UDP throughput
• Maximum usable distance
• Performance through walls
• Performance at different antenna orientations

RSSI is measured in dBm. Values closer to zero represent a stronger received signal. Because RSSI changes with movement, reflections, and nearby people, compare averages rather than relying on one reading.

Arduino RSSI Test Sketch

The following sketch connects to an access point and prints individual RSSI readings followed by their average:

#include <WiFi.h>

const char *ssid = "YOUR_WIFI_SSID";
const char *password = "YOUR_WIFI_PASSWORD";

const int sampleCount = 20;
const unsigned long sampleDelayMs = 500;

void setup() {
  Serial.begin(115200);
  delay(1000);

  WiFi.mode(WIFI_STA);
  WiFi.begin(ssid, password);

  Serial.print("Connecting");

  unsigned long startTime = millis();

  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.print(".");

    if (millis() - startTime > 30000) {
      Serial.println("\nConnection timed out.");
      return;
    }
  }

  Serial.println("\nConnected.");
  Serial.print("IP address: ");
  Serial.println(WiFi.localIP());
  Serial.print("BSSID: ");
  Serial.println(WiFi.BSSIDstr());
}

void loop() {
  if (WiFi.status() != WL_CONNECTED) {
    Serial.println("Wi-Fi disconnected.");
    delay(2000);
    return;
  }

  long rssiTotal = 0;

  Serial.println("Collecting RSSI samples:");

  for (int i = 0; i < sampleCount; i++) {
    int32_t rssi = WiFi.RSSI();
    rssiTotal += rssi;

    Serial.print("Sample ");
    Serial.print(i + 1);
    Serial.print(": ");
    Serial.print(rssi);
    Serial.println(" dBm");

    delay(sampleDelayMs);
  }

  float averageRssi = (float)rssiTotal / sampleCount;

  Serial.print("Average RSSI: ");
  Serial.print(averageRssi, 1);
  Serial.println(" dBm\n");

  delay(3000);
}

Record several test runs with the original antenna and several more with the external antenna. Do not hold the board or antenna during one test and place it on a table during another. Your hand can affect the antenna and invalidate the comparison.

Use More Than RSSI

An improved RSSI reading does not always mean that the entire connection is better. Interference, packet retries, antenna pattern, and access-point behavior can affect actual data transfer.

For a more useful evaluation, transfer a large file or run a local TCP throughput test while monitoring packet loss and disconnections. Repeat the test in the location where the device will actually operate.

Troubleshooting an ESP32 External Antenna

The External Antenna Performs Worse

Check the following:

• The zero-ohm jumper may still select the PCB antenna.
• Both antenna paths may accidentally be connected.
• The U.FL plug may not be fully seated.
• The antenna may be designed for the wrong frequency.
• The antenna may be too close to metal.
• The coaxial cable may be damaged or excessively long.
• The antenna may have a null in the direction of the access point.
• The connector or RF pad may have been damaged during soldering.

Wi-Fi Works Only When the Board Is Close to the Router

This often indicates an open or badly mismatched antenna path. Inspect the selector resistor and U.FL connection. Confirm that the antenna is connected to the radio side of the matching network rather than to the isolated PCB-antenna side.

The Signal Changes When the Cable Is Touched

A large change when touching the cable can indicate that the cable shield is not properly grounded, the connector is loose, or an exposed section of conductor is acting as part of the antenna.

The U.FL Connector Detached from the PCB

Do not attempt to glue it back in place and expect the RF path to work. The center signal pad and surrounding ground pads must be electrically restored. If the pads have lifted, repair normally requires microscope-assisted micro-soldering and a careful RF connection.

The Board Resets While Transmitting

This problem is more likely related to the power supply than the antenna. Wi-Fi transmission produces short current peaks. Check the 3.3 V regulator, USB cable, supply wiring, and decoupling capacitors.

Frequently Asked Questions

Can I connect an antenna directly to an ESP32 GPIO?

No. The Wi-Fi and Bluetooth antenna uses the ESP32's RF output path, not a general-purpose input/output pin. Connecting an antenna to a GPIO will not improve radio range and may expose that GPIO to unwanted RF signals or static discharge.

Can I use the PCB antenna and external antenna at the same time?

Not by simply connecting both paths together. A passive split creates an impedance mismatch and divides transmitted power. A proper diversity or dual-antenna design requires an RF switch, matching network, and support from the selected ESP32 variant and firmware.

Can I solder an SMA connector directly to the board?

Only when the board has a correctly designed 50 Ω RF footprint and sufficient mechanical support. A full-size SMA connector is too large to hang from a small antenna feed pad. A short micro-coaxial pigtail connected to a panel-mounted SMA connector is usually safer.

Will a 9 dBi antenna give three times the ESP32 range?

Not necessarily. Gain is directional, cable loss reduces the improvement, and the other end of the connection must still receive and return data. Higher gain may also exceed the antenna conditions used for the module's regulatory certification.

Does the external antenna improve both Wi-Fi and Bluetooth?

On common ESP32 modules, Wi-Fi and Bluetooth share the 2.4 GHz RF path. A correctly selected external antenna can therefore affect both. The exact internal radio arrangement should still be confirmed in the datasheet for the selected ESP32 variant.

Can I operate an external-antenna ESP32 without an antenna?

Avoid intentionally transmitting for extended periods without an antenna. An open connector produces a severe impedance mismatch, greatly reduces communication performance, and may stress the RF output stage.

Is firmware configuration required after moving the antenna jumper?

Normally, no. A passive zero-ohm antenna selector changes the physical RF path and is not controlled by software. Boards using an electronic RF switch or antenna-diversity circuit may require GPIO or ESP-IDF configuration.

Summary

The safest way of adding an external antenna to an ESP32 is to use a module designed for it, such as an ESP32-WROOM-32UE or ESP32-S3-WROOM-1U. The factory connector preserves the module's controlled RF path and avoids cutting the built-in PCB antenna.

For boards containing both a PCB antenna and a U.FL connector, locate the antenna selector and move its zero-ohm jumper to the external path. Do not leave both antenna paths connected.

Directly modifying a PCB-antenna module is possible in some cases, but it requires isolating the existing antenna and attaching a properly grounded 50 Ω micro-coaxial cable. A loose wire is not a reliable substitute for a matched antenna connection.

Finally, pay close attention to placement. Keep the antenna away from metal, high-speed circuits, batteries, displays, and noisy wiring. Test the complete device in its final enclosure using RSSI, packet loss, and actual throughput rather than assuming that a larger antenna will automatically provide better range.

The post Adding an External Antenna to ESP32: U.FL, PCB Modifications, and Placement appeared first on Teach Me Microcontrollers!.