This guide provides a complete ESP32-S3 pinout reference, including the GPIO pins used for ADC, touch sensing, PWM, UART, SPI, I2C, USB, JTAG, and boot configuration. We will use the popular ESP32-S3-DevKitC-1 as our reference development board, although most of the GPIO information also applies to other ESP32-S3 boards. If you're new to the board, see our ESP32-S3 Getting Started Guide for Arduino IDE setup, board configuration, uploading your first sketch, and basic testing.

One important difference from the original ESP32 is that the ESP32-S3 has a much larger number of available GPIO pins. It also includes native USB support and as many as 14 capacitive-touch inputs.

Suggested diagram labels: Digital GPIO, ADC1, ADC2, Touch, USB, UART, JTAG, strapping pins, flash/PSRAM-related pins, power, and onboard RGB LED.

ESP32-S3 Pinout Overview

The ESP32-S3 chip has 45 physical GPIO pins, numbered GPIO0 through GPIO21 and GPIO26 through GPIO48. Notice that GPIO22 through GPIO25 do not exist on the ESP32-S3. Not all 45 GPIOs are necessarily available on a development board. Some GPIO pins are connected internally to the SPI flash and PSRAM, while others may be assigned to onboard components.

The ESP32 architecture also uses a flexible GPIO Matrix. This means peripherals such as UART, I2C, PWM, and many SPI signals can be routed to different GPIO pins instead of having a single permanently assigned pin. This flexibility is useful when designing an ESP32-S3 project, but it also means that a pinout diagram alone does not always tell you which pins you should actually use.

Interactive ESP32-S3 Pinout Diagram

ESP32-S3 GPIO Pin Reference

The following table summarizes the most important functions and restrictions of the ESP32-S3 GPIO pins.

GPIO	Main Functions	Notes
GPIO0	RTC GPIO	Strapping/BOOT pin
GPIO1	ADC1_CH0, TOUCH1, RTC	Generally available
GPIO2	ADC1_CH1, TOUCH2, RTC	Generally available
GPIO3	ADC1_CH2, TOUCH3, RTC	Strapping pin
GPIO4	ADC1_CH3, TOUCH4, RTC	Generally available
GPIO5	ADC1_CH4, TOUCH5, RTC	Generally available
GPIO6	ADC1_CH5, TOUCH6, RTC	Generally available
GPIO7	ADC1_CH6, TOUCH7, RTC	Generally available
GPIO8	ADC1_CH7, TOUCH8, RTC	Generally available
GPIO9	ADC1_CH8, TOUCH9, RTC, FSPI	Generally available
GPIO10	ADC1_CH9, TOUCH10, RTC, FSPI	Generally available
GPIO11	ADC2_CH0, TOUCH11, RTC, FSPI	Generally available
GPIO12	ADC2_CH1, TOUCH12, RTC, FSPI	Generally available
GPIO13	ADC2_CH2, TOUCH13, RTC, FSPI	Generally available
GPIO14	ADC2_CH3, TOUCH14, RTC, FSPI	Generally available
GPIO15	ADC2_CH4, RTC, U0RTS	Generally available
GPIO16	ADC2_CH5, RTC, U0CTS	Generally available
GPIO17	ADC2_CH6, RTC, U1TXD	Generally available
GPIO18	ADC2_CH7, RTC, U1RXD	Generally available
GPIO19	ADC2_CH8, USB D-, RTC	Native USB
GPIO20	ADC2_CH9, USB D+, RTC	Native USB
GPIO21	RTC GPIO	Generally available
GPIO26–32	SPI flash/PSRAM	Normally reserved for memory
GPIO33–37	SPI flash/PSRAM functions	Availability depends on memory configuration
GPIO38	General GPIO	RGB LED on DevKitC-1 v1.1
GPIO39	MTCK / JTAG	JTAG pin
GPIO40	MTDO / JTAG	JTAG pin
GPIO41	MTDI / JTAG	JTAG pin
GPIO42	MTMS / JTAG	JTAG pin
GPIO43	UART0 TX	Serial/programming output
GPIO44	UART0 RX	Serial/programming input
GPIO45	General GPIO	Strapping pin
GPIO46	General GPIO	Strapping pin
GPIO47	General GPIO	Generally available
GPIO48	General GPIO	RGB LED on original DevKitC-1

Keep in mind that the exact availability of GPIO33 through GPIO37 depends on the ESP32-S3 module and its flash/PSRAM configuration. Always check the module fitted to your development board before using these pins.

Best ESP32-S3 GPIO Pins to Use

If you simply need GPIO pins for LEDs, buttons, sensors, relays, and similar devices, it is generally best to avoid pins involved in boot configuration, flash/PSRAM, USB, and debugging. For a typical ESP32-S3 development board, the following pins are among the easier GPIOs to work with:

• GPIO1
• GPIO2
• GPIO4 to GPIO18
• GPIO21
• GPIO47

These are not the only GPIO pins you can use. They are simply good starting choices because they normally do not interfere with the ESP32-S3 boot process or its USB and JTAG interfaces. GPIO38 and GPIO48 can also be usable depending on the board revision. On the ESP32-S3-DevKitC-1, however, one of these pins is connected to the onboard addressable RGB LED.

ESP32-S3 Pins to Avoid or Use With Caution

Some ESP32-S3 pins can still be used as GPIOs but have important secondary functions.

Using one of these pins does not necessarily cause a problem. The important point is to understand what functionality you may lose or what boot behavior your external circuit might affect.

ESP32-S3 Strapping Pins

The ESP32-S3 has four strapping pins:

• GPIO0
• GPIO3
• GPIO45
• GPIO46

Strapping pins are read by the ESP32-S3 during reset to determine certain startup settings. After the chip has booted, they can generally function as normal GPIO pins. The most familiar example is GPIO0. Holding GPIO0 at the appropriate level during reset can place the ESP32-S3 into its firmware download mode. This is what the BOOT button on many ESP32-S3 boards controls. Because the state of a strapping pin matters during reset, avoid connecting external circuits that force these pins to an inappropriate logic level during startup.

ESP32-S3 ADC Pins

The ESP32-S3 contains two 12-bit SAR ADC peripherals providing a total of 20 analog input channels.

ADC1 Pins

ADC2 Pins

For new designs, ADC1 is generally the better choice when you have free pins available. Also remember that the ESP32-S3 GPIO voltage is 3.3 V. Never apply a 5 V analog signal directly to an ADC pin. Use a voltage divider or appropriate signal-conditioning circuit when measuring higher voltages. If accuracy is important, Espressif also recommends filtering the ADC input. A small capacitor close to the ADC input can reduce noise, and software calibration can further improve measurement accuracy.

ESP32-S3 Touch Pins

The ESP32-S3 provides 14 capacitive-touch GPIO pins. These can detect changes in capacitance caused by a finger approaching or touching an electrode.

Touch inputs are useful for projects such as touch buttons, sliders, control panels, and proximity sensors without requiring a mechanical switch.

ESP32-S3 PWM Pins

PWM on the ESP32-S3 is much more flexible than on traditional Arduino boards. Instead of having a small number of pins permanently designated as PWM pins, the ESP32-S3 can route the LEDC PWM peripheral to suitable GPIO pins through the GPIO Matrix.

The ESP32-S3 provides 8 LEDC channels. These can be used for applications including:

• LED brightness control
• RGB LEDs
• Motor speed control
• Servo control
• Generating periodic digital signals

This means there is no simple list of dedicated "PWM pins" like there is on an Arduino Uno. Instead, choose a suitable output-capable GPIO that is not required for another important function.

ESP32-S3 I2C Pins

The ESP32-S3 provides two I2C controllers. Thanks to the GPIO Matrix, the SDA and SCL signals can be assigned to different GPIO pins. Therefore, the ESP32-S3 does not have only one mandatory pair of I2C pins. For example, you could connect an I2C sensor using GPIO8 for SDA and GPIO9 for SCL:

#include <Wire.h>

#define SDA_PIN 8
#define SCL_PIN 9

void setup() {
  Wire.begin(SDA_PIN, SCL_PIN);
}

void loop() {
}

If a development board or Arduino board definition specifies default I2C pins, calling

Wire.begin()

ESP32-S3 SPI Pins

The ESP32-S3 contains multiple SPI interfaces. Some SPI interfaces are used internally for flash and PSRAM, while others can be used to connect external devices such as:

• TFT displays
• SD cards
• Ethernet controllers
• ADC and DAC modules
• Radio transceivers

SPI signals can often be routed through the GPIO Matrix, so external SPI devices do not always need to use a single fixed pin configuration. However, avoid blindly selecting GPIO26 through GPIO32 because these pins are normally associated with the ESP32-S3's flash and PSRAM interfaces.

ESP32-S3 UART Pins

The ESP32-S3 has three UART controllers. UART signals can normally be routed to different GPIOs, making it possible to choose convenient pins for serial devices such as GPS modules, fingerprint sensors, GSM modules, and other microcontrollers. Two pins have particularly important default UART0 functions:

GPIO43 and GPIO44 can be reused, but doing so may interfere with serial console output or other UART0 functions depending on how the board and firmware are configured.

ESP32-S3 Native USB Pins

Unlike the original ESP32, the ESP32-S3 includes native USB functionality.

These pins support the ESP32-S3's native USB functionality, including USB Serial/JTAG and USB OTG applications. GPIO19 and GPIO20 can be configured as normal GPIOs, but doing so prevents them from simultaneously serving as the native USB data pins. If your board uses the ESP32-S3 USB connector for programming, debugging, or USB device functionality, leave these GPIOs assigned to USB.

ESP32-S3 JTAG Pins

The traditional JTAG interface is available through GPIO39 to GPIO42:

If you are not using external JTAG debugging, these pins may be available for other GPIO functions. However, keeping them free can be useful during firmware development and debugging. The ESP32-S3 also supports USB Serial/JTAG through GPIO19 and GPIO20, so debugging does not always require the traditional four-pin JTAG connection.

ESP32-S3 Flash and PSRAM Pins

Flash and PSRAM are where ESP32-S3 pin selection becomes particularly board-dependent. GPIO26 through GPIO32 are normally used for communication with SPI flash and PSRAM and should not be treated as general-purpose GPIOs.

GPIO33 through GPIO37 may also be required when the ESP32-S3 uses Octal flash or Octal PSRAM. The exact GPIO availability therefore depends on the ESP32-S3 chip or module installed on your board. For example, some ESP32-S3-WROOM configurations use GPIO35, GPIO36, and GPIO37 internally. Those pins cannot then be used to connect external peripherals even if they appear in a generic ESP32-S3 GPIO table. This is why you should check both the ESP32-S3 chip pinout and the documentation for your exact ESP32-S3 module or development board.

ESP32-S3-DevKitC-1 RGB LED Pin

The ESP32-S3-DevKitC-1 includes an onboard addressable RGB LED, but there is an important difference between board revisions.

If an RGB LED example does not work despite using the correct ESP32-S3 board definition, check which DevKitC-1 revision you own. This distinction is also worth remembering when connecting another peripheral to GPIO38 or GPIO48.

ESP32-S3 Power Pins

On the ESP32-S3-DevKitC-1 you will also find several power-related pins:

The ESP32-S3 GPIOs themselves use 3.3 V logic. Do not connect a 5 V logic output directly to an ESP32-S3 GPIO unless the signal is converted to a safe voltage using a voltage divider, level shifter, or another appropriate circuit.

ESP32-S3 GPIO Example with Arduino

GPIO programming on the ESP32-S3 works much like other Arduino-compatible microcontrollers. For example, the following sketch toggles an LED connected to GPIO4:

#define LED_PIN 4

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

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

  digitalWrite(LED_PIN, LOW);
  delay(500);
}

GPIO4 is a convenient example because it is a general-purpose pin while also supporting ADC and capacitive-touch functionality. The same physical pin can perform different functions depending on how the peripheral registers or Arduino libraries configure it.

ESP32-S3 vs ESP32 Pinout

If you are moving from the original ESP32 to the ESP32-S3, do not assume that existing pin assignments can be copied directly. The two chips have substantially different GPIO layouts. The ESP32-S3 also introduces native USB on GPIO19 and GPIO20 and has different ADC, touch, flash, PSRAM, and strapping-pin assignments. At the same time, the ESP32-S3 provides considerably more usable GPIO resources, making it better suited for projects requiring many sensors, displays, buttons, or other peripherals. Always use an ESP32-S3-specific pinout when designing an ESP32-S3 circuit rather than referring to a standard ESP32 pinout diagram.

Frequently Asked Questions

How many GPIO pins does the ESP32-S3 have?

The ESP32-S3 chip has 45 physical GPIO pins: GPIO0 through GPIO21 and GPIO26 through GPIO48. The exact number available on a development board is smaller because some GPIOs may be connected to flash, PSRAM, USB, or onboard peripherals.

What are the best GPIO pins to use on the ESP32-S3?

For ordinary digital peripherals, GPIO1, GPIO2, GPIO4 through GPIO18, GPIO21, and GPIO47 are generally convenient choices. Always check the exact development board because onboard hardware can reserve additional pins.

Which ESP32-S3 pins should I avoid?

GPIO26 through GPIO32 should normally be avoided because they are associated with flash/PSRAM. GPIO0, GPIO3, GPIO45, and GPIO46 are strapping pins. GPIO19 and GPIO20 are used for native USB, while GPIO39 through GPIO42 are associated with JTAG.

Which ESP32-S3 pins support ADC?

GPIO1 through GPIO10 belong to ADC1, while GPIO11 through GPIO20 belong to ADC2. Together they provide 20 ADC channels.

Which ESP32-S3 pins support touch?

GPIO1 through GPIO14 provide the ESP32-S3's capacitive-touch inputs.

Which ESP32-S3 pins are used for USB?

GPIO19 is USB D- and GPIO20 is USB D+. Reassigning these pins as ordinary GPIOs disables their use for the native USB interface.

Does the ESP32-S3 have fixed I2C pins?

No. The ESP32-S3 GPIO Matrix allows I2C SDA and SCL to be assigned to suitable GPIO pins. Development-board definitions may provide default pins, but they can usually be changed in software.

Can any ESP32-S3 GPIO generate PWM?

PWM signals from the LEDC peripheral can be routed to suitable output-capable GPIOs. The ESP32-S3 has eight LEDC PWM channels rather than a fixed set of Arduino-style PWM pins.

Why are GPIO22 through GPIO25 missing?

The ESP32-S3 GPIO numbering is not continuous. Its physical GPIO ranges are GPIO0–GPIO21 and GPIO26–GPIO48, so GPIO22, GPIO23, GPIO24, and GPIO25 simply do not exist on the chip.

Conclusion

The ESP32-S3 provides a flexible GPIO system with plenty of pins for sensors, displays, communications interfaces, and other peripherals. Its GPIO Matrix makes interfaces such as I2C, UART, SPI, and PWM much less dependent on fixed pin assignments than on many conventional microcontrollers.

The main pins to pay attention to are the GPIO0, GPIO3, GPIO45, and GPIO46 strapping pins, GPIO19 and GPIO20 USB pins, GPIO39 through GPIO42 JTAG pins, and the GPIOs reserved for flash and PSRAM. Once these restrictions are understood, choosing pins for an ESP32-S3 project becomes relatively straightforward.

If you are working with a specific ESP32-S3 development board, remember that the board itself may reserve additional GPIOs for LEDs, displays, cameras, PSRAM, or other onboard hardware. Always combine this ESP32-S3 GPIO reference with the schematic or pinout of your exact board.

The post ESP32-S3 Pinout Diagram | ESP32-DevKitC-1 appeared first on Teach Me Microcontrollers!.

This PID tuning calculator uses the classic Ziegler-Nichols closed-loop method to calculate starting values for Kp, Ki, and Kd. Enter the ultimate gain and oscillation period of your system, choose the controller type, and the calculator will generate the corresponding tuning constants.

How to Use the PID Tuning Calculator

The calculator requires two values measured from your system:

• Ku (Ultimate Gain) — the proportional gain at which the system produces sustained oscillation.
• Tu (Ultimate Period) — the time required for one complete oscillation at the ultimate gain.

You can enter the oscillation period in either seconds or milliseconds.

Then select whether you want a P, PI, or PID controller and click Calculate PID Values.

The calculator returns the recommended starting values for:

• Kp — proportional gain
• Ki — integral gain
• Kd — derivative gain

For Arduino users, the tool also generates the corresponding constants for the popular PID_v1 library.

Finding Ku and Tu

To use the Ziegler-Nichols closed-loop tuning method, first disable the integral and derivative terms:

Ki = 0;
Kd = 0;

Start with a low Kp value and gradually increase it while observing the system response.

At some gain, the output may begin oscillating around the setpoint without the oscillation continuously growing or disappearing. This gain is called the ultimate gain, Ku.

Measure the time between two consecutive peaks of the oscillation. This is the ultimate period, Tu.

For example, suppose sustained oscillation occurs when:

Ku = 4.0
Tu = 2.0 seconds

For a PID controller, the classic Ziegler-Nichols equations produce approximately:

Kp = 2.4
Ki = 2.4
Kd = 0.6

These values can then be used as the starting point for further tuning.

[IMAGE PLACEHOLDER: Graph showing sustained oscillation with Ku and Tu labeled]

Ziegler-Nichols PID Formulas

The calculator uses the classic closed-loop Ziegler-Nichols rules.

For a proportional controller:

$K_p = 0.5K_u$

For a PI controller:

$K_p = 0.45K_u$

$K_i = \frac{K_p}{T_u/1.2}$

For a PID controller:

$K_p = 0.6K_u$

$K_i = \frac{K_p}{T_u/2}$

$K_d = K_p\frac{T_u}{8}$

These equations provide a systematic way to obtain initial PID parameters instead of choosing arbitrary Kp, Ki, and Kd values.

Using the Results with Arduino

If you are using Brett Beauregard's Arduino PID library, the calculated values can be inserted directly into your sketch:

double Kp = 2.4;
double Ki = 2.4;
double Kd = 0.6;

PID myPID(&Input, &Output, &Setpoint,
          Kp, Ki, Kd, DIRECT);

The calculator automatically generates a similar code snippet using your calculated values.

For a complete explanation of Arduino PID control, including manual PID implementation, the PID_v1 library, integral windup, sample time, and practical tuning, see my Arduino PID Controller Tutorial.

The Calculated Values Are Starting Points

Ziegler-Nichols tuning does not guarantee the best possible response for every system.

The method tends to produce relatively aggressive tuning and may result in noticeable overshoot. Some systems also should not be deliberately driven into sustained oscillation because doing so could damage a motor, heater, mechanical assembly, or other hardware.

After calculating Kp, Ki, and Kd, observe how your actual system responds.

Typical adjustments include:

The goal of this PID calculator is therefore not to produce a universally perfect controller, but to give you a useful set of initial PID tuning values that you can refine on your actual hardware.

PID Tuning Calculator Summary

To use the calculator:

1. Set Ki and Kd to zero.
2. Increase Kp until sustained oscillation occurs.
3. Record this gain as Ku.
4. Measure the oscillation period Tu.
5. Enter Ku and Tu into the calculator.
6. Select P, PI, or PID control.
7. Use the calculated values as your starting point.
8. Fine-tune the controller while observing the real system response.

PID tuning is ultimately an experimental process. The calculator gives you a more systematic place to start, while testing on the actual system determines the final Kp, Ki, and Kd values.

The post PID Tuning Calculator: Calculate Kp, Ki and Kd appeared first on Teach Me Microcontrollers!.

The Raspberry Pi Pico 2 has a 40-pin header with 26 exposed GPIO pins, including three analog inputs. It also includes 520 KB of SRAM and 4 MB of onboard flash memory. Despite the upgraded microcontroller, the Pico 2 retains the same physical pinout as the original Pico, making it largely compatible with existing Pico hardware and accessories.

Like the original Pico, the Pico 2 can run code using the Pico C/C++ SDK, Arduino IDE, or MicroPython. Its GPIO pins operate at a 3.3 V logic level.

Interactive Pinout

Raspberry Pi Pico 2 Pinout Description

Most of the GPIO pins on the Raspberry Pi Pico 2 can perform several different functions. In general, these functions include GPIO, UART, I2C, ADC, PWM, PIO, and SPI. The Pico 2 uses the same 40-pin layout as the original Pico. Therefore, projects that connect to GP0 through GP28, the power pins, or the RUN pin can generally use the Pico 2 without changing the wiring.

General Purpose Pins

The Pico 2 exposes 26 GPIO pins on its headers. These are GP0 to GP22 and GP26 to GP28. Most GPIO pins can also serve as UART, I2C, SPI, PWM, or programmable I/O pins. The RP2350 provides three Programmable I/O or PIO blocks, compared with two on the original RP2040. Together, these provide 12 PIO state machines for implementing custom digital interfaces.

Analog Input Pins

Three ADC inputs are available directly on the Pico 2 headers:

• GP26 – ADC0
• GP27 – ADC1
• GP28 – ADC2

The RP2350 contains a 12-bit analog-to-digital converter. Although the RP2350A provides four ADC-capable GPIOs internally, only three are exposed as GPIO pins on the Pico 2 header.

Power Pins

The Raspberry Pi Pico 2 provides several pins for powering the board and connected peripherals:

• VBUS – USB input voltage, normally around 5 V when USB is connected
• VSYS – Main system power input
• 3V3(OUT) – Regulated 3.3 V output
• 3V3_EN – Enables or disables the onboard 3.3 V regulator
• ADC_VREF – Reference voltage for the ADC
• GND / AGND – Digital and analog ground connections

SWD Pins

The SWD pins are used to program and debug the Raspberry Pi Pico 2 using the Serial Wire Debug interface. The three dedicated pads provide SWCLK, GND, and SWDIO.

Raspberry Pi Pico vs. Pico 2 Pinout

One of the advantages of upgrading from the original Pico to the Pico 2 is that the two boards use the same physical pin layout. GP0 is still on pin 1, GP1 is on pin 2, GP26/ADC0 is on pin 31, and the power and ground pins remain in the same locations.

However, the RP2350 adds several capabilities that are not available on the RP2040. These include an additional PIO block, additional alternate GPIO functions, and the RP2350's high-speed HSTX peripheral. These advanced functions do not change the physical header layout.

This means that, for most existing Raspberry Pi Pico projects, you can replace the original Pico with a Pico 2 without changing the circuit wiring.

Raspberry Pi Pico 2 Schematic

(Click to view larger image)

The post Raspberry Pi Pico 2 Pinout appeared first on Teach Me Microcontrollers!.

I recently picked up a small tool that combines both interfaces in one device: the UTS-T02 USB-to-RS232/RS485 converter. A slide switch selects between RS232 and RS485 operation, while three LEDs indicate power, transmit activity, and receive activity. The unit also uses a removable three-position screw terminal instead of permanently attached wires. The product listing identifies the USB interface chip as the CH343G.

This is a simple device, but it can be surprisingly useful when developing or troubleshooting embedded systems. In this article, we'll look at what it does, how the two modes differ, and how we can actually use it to communicate with embedded hardware.

What Does the USB to RS232/RS485 Converter Do?

The job of the converter is simple: it gives a computer an RS232 or RS485 serial interface through USB.

Once connected, the computer sees the converter as a serial port. A serial terminal, Python program, test application, Modbus utility, or other PC software can then use that serial port to communicate with the external device.

The CH343 used inside this converter is a USB-to-UART bridge from WCH. The CH343 family supports virtual serial-port operation and baud rates from 50 bps up to 6 Mbps at the chip level. The maximum speed of the complete UTS-T02 should not automatically be assumed to be 6 Mbps, however, because the RS232/RS485 transceiver circuitry also affects the usable communication rate.

The interesting part of this particular adapter is that the UART signal generated internally is converted into one of two different electrical interfaces:

• RS232 for point-to-point serial communication
• RS485 for differential serial communication, particularly over longer cables and in electrically noisy environments

A small switch on the side selects which interface is connected to the terminal block.

Understanding the Terminals

There are only three terminals on the end of the converter:

The dual labels initially look strange because the same physical terminals serve completely different purposes depending on the switch position. The seller's interface diagram describes the A+/TXD terminal as RS485 A or the connection toward the RS232 receiver, while B-/RXD becomes RS485 B or the connection toward the RS232 transmitter.

For normal RS232 wiring, remember that the transmitter of one device connects to the receiver of the other:

USB Converter             RS232 Device

TXD  -------------------> RXD
RXD  <------------------- TXD
GND  -------------------- GND

In RS485 mode, the wiring instead becomes:

USB Converter             RS485 Device

A+   -------------------- A
B-   -------------------- B
GND  -------------------- GND

RS232 Is Not TTL UART

This is one of the most important things to understand about this tool.

Do not connect the RS232 terminals directly to an ESP32, Arduino, Raspberry Pi Pico, STM32, or similar microcontroller UART.

The UART peripheral inside a microcontroller normally operates at logic levels such as 3.3 V. RS232 uses positive and negative voltages instead. Valid RS232 receiver signals are normally greater than +3 V or less than -3 V, with transmitter levels typically extending farther in either direction.

If your microcontroller has a normal TTL/CMOS UART, you need an RS232 transceiver such as a MAX3232 between the microcontroller and this adapter.

Computer
   |
  USB
   |
UTS-T02
(RS232)
   |
 RS232
   |
MAX3232
   |
3.3 V UART
   |
 ESP32

This also means that the UTS-T02 does not replace the common CH340, CP2102, or FT232 USB-to-TTL adapters used when programming or debugging development boards. It serves a different purpose.

What's Inside the UTS-T02?

Since this adapter combines USB, RS232, and RS485 in such a small enclosure, I decided to open it and see what hardware is actually doing the conversion.

There are two main ICs on the PCB. The larger chip is a WCH CH343, which handles the USB-to-UART conversion. The smaller chip is an SP485EE, a half-duplex RS485 transceiver responsible for converting the UART signals into the differential A and B signals used by RS485.

The basic RS485 signal path is therefore:

PC USB
   |
   v
CH343
USB-to-UART
   |
   v
SP485EE
RS485 Transceiver
   |
   +---- A+
   |
   +---- B-

The RS485 side is straightforward, but the RS232 side was more interesting. There is no obvious MAX232 or MAX3232-style RS232 transceiver on the board. At first glance, this raises the possibility that the terminal marked RS232 might simply expose logic-level UART signals from the CH343.

Is the RS232 Output Really RS232?

To find out, I switched the adapter to RS232 mode and measured the TXD terminal relative to GND.

With the serial port idle, I measured approximately -5 V at TXD. I then repeatedly transmitted the character U from the PC and observed the TXD signal using an oscilloscope. The waveform switched between positive and negative voltages rather than between 0 V and a positive logic voltage.

This is important because a normal TTL or CMOS UART would typically switch between 0 V and 3.3 V or 5 V. RS232 instead uses bipolar signaling, where the idle or mark state is represented by a negative voltage.

TTL UART:

Logic high  ---- +3.3 V or +5 V
Logic low   ---- 0 V


UTS-T02 RS232 TX:

Idle        ---- approximately -5 V
Data        ---- switches between
                positive and negative voltages

The character U is particularly useful for viewing a serial waveform because its hexadecimal value is 0x55, or 01010101 in binary. This creates frequent transitions in the transmitted data and makes the signal easy to observe on an oscilloscope.

Based on these measurements, the UTS-T02's RS232 setting is not simply exposing the CH343's logic-level UART. The board contains additional circuitry that converts the UART signal into bipolar RS232 voltage levels, even though this circuitry is not implemented using an obvious dedicated MAX232-family IC.

The internal architecture therefore appears to be approximately:

+---- RS232 level conversion ---- TXD/RXD
                         |
USB ---- CH343 ---- UART-+
                         |
                         +---- SP485EE ------------------- A+/B-
                                  RS485

I haven't reverse-engineered every component of the RS232 level-conversion circuit, so I won't claim exactly how the positive and negative voltages are generated. However, the measured -5 V idle level and bipolar transmit waveform confirm that the output behaves electrically as an RS232 interface rather than an ordinary TTL UART.

Testing RS232 Mode

The easiest first test for the RS232 side is a loopback test.

Set the switch to RS232 and connect the TXD and RXD terminals together. Connect the converter to the computer and determine which COM port has been assigned to it.

Open your preferred serial terminal and configure a reasonable baud rate such as:

• 9600 baud
• 8 data bits
• No parity
• 1 stop bit
• No flow control

Characters transmitted by the PC should return through the RXD terminal and appear in the terminal program.

This is a useful first check because it verifies the USB interface, serial driver, transmit circuit, receive circuit, and terminal connection without requiring another device.

Using RS232 with a Microcontroller

To test this converter against a microcontroller, we can put a MAX3232 between the adapter and the MCU.

UTS-T02 TXD ---- MAX3232 ---- MCU RX
UTS-T02 RXD ---- MAX3232 ---- MCU TX
UTS-T02 GND ----------------- MCU GND

You can then run a simple UART echo program on the microcontroller. Anything typed into the PC terminal is sent through USB, converted to RS232, converted back to logic-level UART by the MAX3232, and finally received by the microcontroller.

The response travels through exactly the opposite path.

This setup can be useful when developing equipment that must eventually communicate with an existing RS232 system. Instead of requiring the actual equipment during every firmware test, the PC and converter can act as the other end of the serial connection.

RS485 Mode

RS485 is where this converter becomes particularly useful for embedded development.

Unlike the single-ended RS232 interface, RS485 uses differential signaling. Information is represented by the voltage difference between two wires rather than the voltage of a single signal relative to ground. This makes RS485 much better suited to long cables and electrically noisy environments. RS485 also supports multiple nodes on the same bus.

The UTS-T02 is designed for two-wire half-duplex RS485. Half-duplex means the same pair of wires is used for both transmitting and receiving, so only one device should drive the bus at a time. Two-wire half-duplex is the most common RS485 configuration.

RS485 BUS

UTS-T02     Device 1       Device 2
  A ----------- A ------------ A
  B ----------- B ------------ B
 GND ---------- GND ---------- GND

Unlike an RS485 transceiver attached directly to a microcontroller, the converter does not expose separate Driver Enable and Receiver Enable pins. From the user's perspective, direction switching is therefore handled inside the adapter when operating in RS485 mode.

Testing RS485 with an ESP32

For a practical test, we can connect the UTS-T02 to an ESP32 through a 3.3 V-compatible RS485 transceiver such as the MAX3485.

On the microcontroller side:

The following Arduino sketch receives a line from the computer and sends a response back over RS485:

#define RS485_RX     16
#define RS485_TX     17
#define RS485_ENABLE 4

HardwareSerial RS485(2);

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

  RS485.begin(9600, SERIAL_8N1, RS485_RX, RS485_TX);

  pinMode(RS485_ENABLE, OUTPUT);

  // Start in receive mode
  digitalWrite(RS485_ENABLE, LOW);

  Serial.println("RS485 test ready");
}

void sendRS485(String message) {
  // Enable transmitter
  digitalWrite(RS485_ENABLE, HIGH);
  delayMicroseconds(50);

  RS485.println(message);
  RS485.flush();

  delayMicroseconds(50);

  // Return to receive mode
  digitalWrite(RS485_ENABLE, LOW);
}

void loop() {
  if (RS485.available()) {
    String message = RS485.readStringUntil('\n');
    message.trim();

    Serial.print("Received: ");
    Serial.println(message);

    sendRS485("ESP32 received: " + message);
  }
}

After uploading the sketch, set the UTS-T02 switch to RS485 mode. Open the converter's COM port using a serial terminal configured for 9600 baud.

Send:

Hello ESP32

The response should be:

ESP32 received: Hello ESP32

This is already enough to make the converter useful for developing custom RS485 protocols. It can also be used with protocols such as Modbus RTU, where the converter provides the physical RS485 interface while software on the PC handles the protocol.

What About the Advertised 1200-Meter RS485 Range?

The product material advertises RS485 communication distances of up to 1.2 kilometers.

That shouldn't be interpreted as meaning that every setup will communicate reliably over a 1200-meter cable. RS485 cable length and data rate are related: higher communication speeds generally require shorter cables. Cable type, topology, termination, electrical noise, transceiver characteristics, and other factors also affect the maximum usable distance. Texas Instruments similarly lists 1200 meters as a theoretical RS485 cable length while emphasizing the relationship between signaling rate and cable length.

For workbench debugging, this normally doesn't matter. But if the converter is going to be used to diagnose an actual long-distance RS485 installation, proper cabling and termination become important.

RS485 Termination

Long RS485 buses generally require termination at the ends of the transmission line. The terminating resistance is selected to match the characteristic impedance of the cable; around 120 ohms is common for typical twisted-pair RS485 wiring. Proper termination reduces signal reflections on the bus.

I don't see a separate externally accessible termination-resistor switch on this particular converter. Therefore, if termination is required, I would plan on providing it externally unless measurement or inspection of the actual unit confirms that suitable termination is already installed.

TX and RX LEDs Are More Useful Than They Look

The converter has three indicator LEDs:

• PWR — power
• TXD — transmit activity
• RXD — receive activity

These LEDs are useful during debugging because they quickly tell you whether communication is happening at all.

For example, if the TXD LED flashes every time your PC software sends a command but RXD never flashes, you immediately know that the PC is transmitting but nothing is coming back.

That narrows the problem considerably. You can then check the baud rate, wiring, RS232/RS485 selector, device configuration, or A/B polarity rather than wondering whether the application transmitted anything in the first place.

Where This Tool Fits on an Embedded Workbench

I wouldn't consider this a replacement for a normal USB-to-TTL UART adapter. Instead, I see them as complementary tools.

If you regularly work with industrial controllers or embedded devices that communicate with external equipment, having both interfaces available in a single small adapter is convenient.

Things I Would Check Before Using It in the Field

The UTS-T02 works well as a compact bench adapter, but one limitation becomes apparent after opening the enclosure: there is no obvious galvanic isolation between the USB interface and the serial side.

The PCB contains a CH343 USB-to-UART bridge and an SP485EE RS485 transceiver, along with the circuitry used for the RS232 interface. I did not find an obvious optocoupler, digital isolator, isolated DC-DC converter, or isolation barrier on the PCB.

This shouldn't be a problem for most short-distance bench tests where the PC and target hardware share a reasonably common ground. However, it becomes more important when connecting to RS485 equipment installed over long cable runs or powered from different electrical systems.

Differences in ground potential can cause current to flow through the communication ground or even through the PC's USB connection. For installations where this is a concern, an isolated USB-to-RS485 adapter would be the safer choice.

So I would treat the UTS-T02 primarily as a convenient development and debugging tool rather than assume it provides the electrical isolation expected from some industrial RS485 interfaces.

What I Like About the UTS-T02

Limitations

Would I Keep It on My Workbench?

Yes. A USB-to-RS485 adapter by itself is already a useful embedded-development tool, especially when working with Modbus devices, industrial sensors, motor controllers, PLCs, and custom RS485 hardware. Adding RS232 support makes this adapter even more useful without taking up additional space.

More importantly, tools like this let the PC become part of the debugging environment. Instead of waiting for another controller to test an embedded device, you can send commands manually, capture responses, test error conditions, and write PC software that simulates the equipment that will eventually communicate with your board.

That's what makes a simple serial converter more than just another USB dongle. For embedded development, it becomes a convenient way of looking into — and interacting with — the communication interface of the device you're building.

The post Using a 2-in-1 USB to RS232/RS485 Converter for Embedded Debugging appeared first on Teach Me Microcontrollers!.

Linked lists are common in general-purpose software, but using one in a microcontroller requires extra care. Dynamic memory allocation, memory fragmentation, pointer errors, and unpredictable execution time can all become important concerns when RAM is limited.

In this tutorial, I will explain how a linked list works, show how nodes are connected, and build a practical singly linked list in embedded C. You can also use the visualizer below to add, remove, and traverse nodes while watching the pointers change.

Interactive Linked List Visualizer

Use the controls below to add nodes, remove nodes, and move through the list. Each box represents one node. The arrow leaving a node represents its next pointer.

Pay particular attention to the first node, called the head, and to the final node whose next pointer is NULL.

#define LIST_MAX_NODES 6

typedef struct Node
{
    uint8_t value;
    struct Node *next;
} Node;

typedef struct
{
    Node *head;
    Node *tail;
    uint8_t count;
} LinkedList;

bool list_push_front(LinkedList *list, Node *node, uint8_t value)
{
    if (list->count >= LIST_MAX_NODES)
    {
        return false;
    }

    node->value = value;
    node->next = list->head;
    list->head = node;

    if (list->tail == NULL)
    {
        list->tail = node;
    }

    list->count++;
    return true;
}

bool list_push_back(LinkedList *list, Node *node, uint8_t value)
{
    if (list->count >= LIST_MAX_NODES)
    {
        return false;
    }

    node->value = value;
    node->next = NULL;

    if (list->tail != NULL)
    {
        list->tail->next = node;
    }
    else
    {
        list->head = node;
    }

    list->tail = node;
    list->count++;
    return true;
}

bool list_pop_front(LinkedList *list, uint8_t *value)
{
    Node *old_head;

    if (list->head == NULL)
    {
        return false;
    }

    old_head = list->head;
    *value = old_head->value;
    list->head = old_head->next;

    if (list->head == NULL)
    {
        list->tail = NULL;
    }

    list->count--;
    return true;
}

What Is a Linked List?

A linked list is a data structure made from individual elements called nodes. Each node normally contains two parts:

• The data stored by the node
• A pointer to another node

A basic singly linked-list node in C may look like this:

typedef struct Node
{
    uint8_t value;
    struct Node *next;
} Node;

The value member stores the actual information. The next member stores the address of the following node.

Suppose three nodes contain the values 10, 20, and 30. Their relationship can be represented as:

head
  |
  v
[10 | next] -> [20 | next] -> [30 | NULL]

The program starts at head, follows the first node’s next pointer, and continues until it reaches NULL.

The final node points to NULL because there is no node after it.

Linked List Versus Array

An array stores its elements next to one another in memory.

uint8_t values[4] = {10, 20, 30, 40};

The elements occupy consecutive positions:

Address:  0x2000  0x2001  0x2002  0x2003
Value:       10      20      30      40

This makes accessing a specific array element fast. The processor can calculate the address of values[2] directly.

Linked-list nodes may be located in different parts of memory:

Node 1 at 0x2000
Node 2 at 0x2140
Node 3 at 0x2088

The nodes remain connected because each one stores the address of the next node.

A linked list is useful when elements must frequently be inserted or removed without shifting the remaining data. An array is usually better when fast indexed access and compact memory usage are more important.

The Head Pointer

The head pointer identifies the first node in the list.

Node *head = NULL;

When head is NULL, the list is empty.

After adding a node:

Node first_node;

first_node.value = 10;
first_node.next = NULL;

head = &first_node;

The head now stores the address of first_node.

head -> [10 | NULL]

The head is not a node itself. It is a pointer that tells the program where the list begins.

How Linked-List Traversal Works

Unlike an array, a linked list cannot directly jump to an arbitrary element by index. The program must begin at the head and follow each next pointer.

void linked_list_print(const Node *head)
{
    const Node *current = head;

    while (current != NULL)
    {
        printf("%u\n", current->value);
        current = current->next;
    }
}

The temporary pointer current begins at the first node. After processing that node, it becomes the address stored in current->next.

The traversal ends when current becomes NULL.

For a list containing four nodes, reaching the final node may require following three pointers. This means finding an element becomes slower as the list grows.

Creating a Basic Singly Linked List

A singly linked list allows movement in one direction only. Each node points to the node after it.

We can begin with this data structure:

#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>

typedef struct Node
{
    uint8_t value;
    struct Node *next;
} Node;

typedef struct
{
    Node *head;
    uint16_t count;
} LinkedList;

The LinkedList structure stores:

• A pointer to the first node
• The number of nodes currently in the list

Initializing the List

void linked_list_init(LinkedList *list)
{
    list->head = NULL;
    list->count = 0U;
}

An initialized list contains no nodes, so the head is set to NULL.

Adding a Node at the Beginning

Adding a node at the beginning is one of the simplest linked-list operations.

Suppose the current list is:

head -> [20] -> [30] -> NULL

To insert a node containing 10:

1. Make the new node point to the current head.
2. Change the head so it points to the new node.

bool linked_list_push_front(
    LinkedList *list,
    Node *node,
    uint8_t value)
{
    if ((list == NULL) || (node == NULL))
    {
        return false;
    }

    node->value = value;
    node->next = list->head;

    list->head = node;
    list->count++;

    return true;
}

After the operation:

head -> [10] -> [20] -> [30] -> NULL

The existing nodes do not move in memory. Only two pointer values change.

Adding a Node at the End

Adding at the end requires finding the final node unless the list also stores a tail pointer.

bool linked_list_push_back(
    LinkedList *list,
    Node *node,
    uint8_t value)
{
    Node *current;

    if ((list == NULL) || (node == NULL))
    {
        return false;
    }

    node->value = value;
    node->next = NULL;

    if (list->head == NULL)
    {
        list->head = node;
        list->count++;
        return true;
    }

    current = list->head;

    while (current->next != NULL)
    {
        current = current->next;
    }

    current->next = node;
    list->count++;

    return true;
}

If the list is empty, the new node becomes the head. Otherwise, the function traverses the list until it finds the node whose next pointer is NULL.

This operation takes longer as the list grows. Storing a separate tail pointer can make insertion at the end much faster.

Removing the First Node

To remove the first node:

1. Save a pointer to the current head.
2. Move the head to the second node.
3. Disconnect the removed node.

Node *linked_list_pop_front(LinkedList *list)
{
    Node *removed;

    if ((list == NULL) || (list->head == NULL))
    {
        return NULL;
    }

    removed = list->head;
    list->head = removed->next;

    removed->next = NULL;
    list->count--;

    return removed;
}

If the original list is:

head -> [10] -> [20] -> [30] -> NULL

the result becomes:

head -> [20] -> [30] -> NULL

removed -> [10] -> NULL

The function returns the removed node so the application can reuse it or release it through the appropriate memory-management method.

Removing a Node by Value

Removing a node from the middle requires keeping track of both the current node and the node before it.

Node *linked_list_remove(
    LinkedList *list,
    uint8_t value)
{
    Node *current;
    Node *previous = NULL;

    if (list == NULL)
    {
        return NULL;
    }

    current = list->head;

    while (current != NULL)
    {
        if (current->value == value)
        {
            if (previous == NULL)
            {
                list->head = current->next;
            }
            else
            {
                previous->next = current->next;
            }

            current->next = NULL;
            list->count--;

            return current;
        }

        previous = current;
        current = current->next;
    }

    return NULL;
}

If the first node matches, the head changes. If a middle node matches, the previous node is connected directly to the node after the removed one.

For example:

Before:

[10] -> [20] -> [30] -> NULL

Remove 20:

[10] ---------> [30] -> NULL

Finding a Value

Node *linked_list_find(
    LinkedList *list,
    uint8_t value)
{
    Node *current;

    if (list == NULL)
    {
        return NULL;
    }

    current = list->head;

    while (current != NULL)
    {
        if (current->value == value)
        {
            return current;
        }

        current = current->next;
    }

    return NULL;
}

The function returns a pointer to the matching node or NULL when the value is not present.

Searching a linked list requires checking nodes one at a time. For large collections requiring frequent searches, another data structure may be more suitable.

Complete Dynamic Allocation Example

On a desktop computer, linked-list nodes are commonly created using dynamic allocation.

#include <stdbool.h>
#include <stdint.h>
#include <stdlib.h>

typedef struct Node
{
    uint8_t value;
    struct Node *next;
} Node;

typedef struct
{
    Node *head;
    uint16_t count;
} LinkedList;

bool linked_list_add(
    LinkedList *list,
    uint8_t value)
{
    Node *node;

    if (list == NULL)
    {
        return false;
    }

    node = malloc(sizeof(Node));

    if (node == NULL)
    {
        return false;
    }

    node->value = value;
    node->next = list->head;

    list->head = node;
    list->count++;

    return true;
}

bool linked_list_remove_first(
    LinkedList *list,
    uint8_t *value)
{
    Node *removed;

    if ((list == NULL) ||
        (list->head == NULL))
    {
        return false;
    }

    removed = list->head;
    list->head = removed->next;

    if (value != NULL)
    {
        *value = removed->value;
    }

    free(removed);
    list->count--;

    return true;
}

This code works, but using malloc() and free() may not be the best option for every embedded system.

Why Dynamic Allocation Can Be a Problem

Microcontrollers often have limited RAM and may need to operate continuously for months or years. Repeated allocation and release can divide the available heap into small separated areas.

This condition is called memory fragmentation.

Suppose a device has several free memory regions:

Free blocks: 16 bytes, 12 bytes, 20 bytes

The total free memory is 48 bytes, but an attempt to allocate one 32-byte block may fail because no individual free region is large enough.

Dynamic allocation can introduce other concerns:

• Allocation may fail at runtime.
• Execution time may be difficult to predict.
• Memory leaks can slowly consume the heap.
• Double-free errors can corrupt memory.
• Using freed nodes can cause unpredictable behavior.
• Debugging heap corruption on a microcontroller can be difficult.

Dynamic memory is not automatically forbidden in embedded software. It can be acceptable when allocation is controlled, occurs only during initialization, or runs on a system with enough memory and a suitable allocator.

However, a fixed node pool is often a safer choice for small microcontrollers and long-running firmware.

Using a Static Node Pool

A static pool reserves all possible nodes at compile time. The application takes nodes from the pool and returns them when they are no longer needed.

#define NODE_POOL_SIZE 8U

typedef struct Node
{
    uint8_t value;
    struct Node *next;
} Node;

typedef struct
{
    Node nodes[NODE_POOL_SIZE];
    Node *free_list;
} NodePool;

The pool can use a second linked list to track available nodes.

Initializing the Pool

void node_pool_init(NodePool *pool)
{
    uint8_t index;

    if (pool == NULL)
    {
        return;
    }

    for (index = 0U;
         index < NODE_POOL_SIZE - 1U;
         index++)
    {
        pool->nodes[index].next =
            &pool->nodes[index + 1U];
    }

    pool->nodes[NODE_POOL_SIZE - 1U].next =
        NULL;

    pool->free_list = &pool->nodes[0];
}

After initialization, every available node is connected through the pool’s free_list.

Allocating a Node from the Pool

Node *node_pool_allocate(NodePool *pool)
{
    Node *node;

    if ((pool == NULL) ||
        (pool->free_list == NULL))
    {
        return NULL;
    }

    node = pool->free_list;
    pool->free_list = node->next;

    node->next = NULL;

    return node;
}

The first available node is removed from the free list and returned to the caller.

Returning a Node to the Pool

void node_pool_release(
    NodePool *pool,
    Node *node)
{
    if ((pool == NULL) || (node == NULL))
    {
        return;
    }

    node->next = pool->free_list;
    pool->free_list = node;
}

The released node is placed back at the beginning of the free list.

This approach has several useful properties:

• The maximum memory usage is known at compile time.
• Allocation does not depend on the general-purpose heap.
• No external fragmentation occurs inside the pool.
• Allocation and release are fast and predictable.
• Pool exhaustion can be detected when no free nodes remain.

Complete Static Linked List Example

The following example combines a linked list with a fixed node pool.

#include <stdbool.h>
#include <stddef.h>
#include <stdint.h>

#define NODE_POOL_SIZE 8U

typedef struct Node
{
    uint8_t value;
    struct Node *next;
} Node;

typedef struct
{
    Node *head;
    uint16_t count;
} LinkedList;

typedef struct
{
    Node nodes[NODE_POOL_SIZE];
    Node *free_list;
} NodePool;

void node_pool_init(NodePool *pool)
{
    uint8_t index;

    for (index = 0U;
         index < NODE_POOL_SIZE - 1U;
         index++)
    {
        pool->nodes[index].next =
            &pool->nodes[index + 1U];
    }

    pool->nodes[NODE_POOL_SIZE - 1U].next =
        NULL;

    pool->free_list = &pool->nodes[0];
}

Node *node_pool_allocate(NodePool *pool)
{
    Node *node;

    if (pool->free_list == NULL)
    {
        return NULL;
    }

    node = pool->free_list;
    pool->free_list = node->next;

    node->next = NULL;

    return node;
}

void node_pool_release(
    NodePool *pool,
    Node *node)
{
    node->next = pool->free_list;
    pool->free_list = node;
}

void linked_list_init(LinkedList *list)
{
    list->head = NULL;
    list->count = 0U;
}

bool linked_list_add(
    LinkedList *list,
    NodePool *pool,
    uint8_t value)
{
    Node *node;

    node = node_pool_allocate(pool);

    if (node == NULL)
    {
        return false;
    }

    node->value = value;
    node->next = list->head;

    list->head = node;
    list->count++;

    return true;
}

bool linked_list_remove_first(
    LinkedList *list,
    NodePool *pool,
    uint8_t *value)
{
    Node *removed;

    if (list->head == NULL)
    {
        return false;
    }

    removed = list->head;
    list->head = removed->next;

    if (value != NULL)
    {
        *value = removed->value;
    }

    list->count--;
    node_pool_release(pool, removed);

    return true;
}

The maximum number of active nodes is limited to NODE_POOL_SIZE. When all nodes are in use, linked_list_add() returns false.

This fixed limit is often desirable in embedded firmware because the system’s worst-case memory requirement is known before the program runs.

Example Application

LinkedList event_list;
NodePool event_pool;
uint8_t event_value;

int main(void)
{
    node_pool_init(&event_pool);
    linked_list_init(&event_list);

    linked_list_add(
        &event_list,
        &event_pool,
        10U);

    linked_list_add(
        &event_list,
        &event_pool,
        20U);

    linked_list_add(
        &event_list,
        &event_pool,
        30U);

    while (1)
    {
        if (linked_list_remove_first(
                &event_list,
                &event_pool,
                &event_value))
        {
            process_event(event_value);
        }

        run_other_tasks();
    }
}

Because nodes are added at the beginning, the values in this example are removed in reverse order: 30, 20, then 10.

This behavior is a stack, not a FIFO queue. To preserve insertion order, add new nodes at the end or store a tail pointer.

Linked List with Head and Tail Pointers

Adding a tail pointer makes it possible to insert at the end without traversing the entire list.

typedef struct
{
    Node *head;
    Node *tail;
    uint16_t count;
} LinkedList;

Appending a node then becomes:

bool linked_list_push_back(
    LinkedList *list,
    Node *node,
    uint8_t value)
{
    if ((list == NULL) || (node == NULL))
    {
        return false;
    }

    node->value = value;
    node->next = NULL;

    if (list->tail == NULL)
    {
        list->head = node;
        list->tail = node;
    }
    else
    {
        list->tail->next = node;
        list->tail = node;
    }

    list->count++;

    return true;
}

When removing the first node, remember to clear the tail when the final element is removed.

Node *linked_list_pop_front(
    LinkedList *list)
{
    Node *removed;

    if ((list == NULL) ||
        (list->head == NULL))
    {
        return NULL;
    }

    removed = list->head;
    list->head = removed->next;

    if (list->head == NULL)
    {
        list->tail = NULL;
    }

    removed->next = NULL;
    list->count--;

    return removed;
}

This head-and-tail arrangement can be used to build a FIFO event queue.

Where Linked Lists Are Used in Embedded Systems

Linked lists can be useful when the number or ordering of elements changes while the program is running.

Event Queues

Each node can represent an event waiting to be processed.

typedef struct Event
{
    uint16_t event_id;
    uint32_t timestamp;
    struct Event *next;
} Event;

Software Timers

Timer nodes may be sorted by expiration time. The application only needs to check the first timer to find the next event that will expire.

Network Packet Lists

Network stacks may connect packet buffers without copying all packet data into one large contiguous block.

Device and Driver Registration

Drivers, callbacks, or peripheral objects can be registered in a list during system initialization.

Memory Free Lists

A memory allocator can link unused blocks together. The static node pool shown earlier is itself an example of a free list.

RTOS Kernel Objects

Real-time operating systems commonly use linked lists internally for task scheduling, blocked-task lists, timer lists, and queues.

When a Linked List Is Not the Best Choice

A linked list is not automatically better because elements can be inserted and removed easily.

Consider using an array, ring buffer, or another fixed structure when:

• The maximum number of elements is known.
• Fast indexed access is required.
• Memory overhead must be minimized.
• Cache locality matters.
• The data is processed in strict FIFO order.
• Deterministic memory usage is a priority.

For UART bytes, a ring buffer is normally more appropriate than a linked list. Every linked-list node would require a pointer in addition to the byte itself, creating unnecessary memory overhead.

A linked list becomes more attractive when elements are larger, insertions occur at different positions, or nodes already exist as application objects.

Memory Overhead in a Linked List

Each node requires space for at least one pointer.

Consider this structure on a 32-bit microcontroller:

typedef struct Node
{
    uint8_t value;
    struct Node *next;
} Node;

The data uses only one byte, but the pointer requires four bytes. Alignment and padding may increase the total node size to eight bytes.

As a result, storing eight one-byte values may require approximately 64 bytes instead of eight bytes.

This is why linked lists are rarely a good choice for individual UART characters or tiny sensor readings.

They become more memory-efficient when each node contains a larger payload or when the node is embedded inside an existing object.

Intrusive Linked Lists

An intrusive linked list places the pointer directly inside the application object.

typedef struct Sensor
{
    uint8_t address;
    uint16_t sample_rate;
    struct Sensor *next;
} Sensor;

The sensor object itself becomes a list node. No separate wrapper node is required.

This approach is common in embedded systems because it avoids additional allocation and gives the programmer direct control over memory.

The tradeoff is that the object becomes coupled to the list. A single next pointer also allows the object to belong to only one such list at a time unless more link fields are added.

Linked Lists and Interrupts

Modifying a linked list from an interrupt while the main program also modifies it can corrupt the list.

Consider adding a node at the head:

node->next = list->head;
list->head = node;

This operation involves more than one memory access. If another execution context changes the list between those two statements, a node may be lost or connected incorrectly.

Depending on the system, shared-list operations may require:

• A short critical section
• Temporarily disabling the relevant interrupt
• An RTOS mutex
• An RTOS queue
• A carefully designed lock-free algorithm

Adding volatile to a pointer does not make the complete linked-list operation atomic.

For communication between a UART interrupt and a main loop, a single-producer, single-consumer ring buffer is normally simpler and safer than a shared linked list.

Common Linked-List Mistakes

Losing the Head Pointer

Changing the head before saving the old value may make the original node unreachable.

Forgetting to Update the Previous Node

When removing a middle node, the previous node must point to the removed node’s successor.

Dereferencing NULL

Always check whether a pointer is NULL before accessing its members.

if (current != NULL)
{
    value = current->value;
}

Using a Node After It Has Been Freed

A pointer does not automatically become invalid-looking after free(). It may still contain the old address even though that memory no longer belongs to the node.

free(node);
node = NULL;

Setting the local pointer to NULL can help prevent accidental reuse, although other copies of the same pointer must also be handled correctly.

Creating a Cycle Accidentally

If a node points to an earlier node instead of eventually reaching NULL, traversal may never terminate.

[10] -> [20] -> [30]
          ^         |
          |_________|

Returning a Node to the Pool Twice

Releasing the same node twice can corrupt the pool’s free list. The application must clearly define who owns each node.

Using Dynamic Allocation Without Handling Failure

Every allocation can fail. The return value of malloc() or a node-pool allocation function must be checked.

Singly Versus Doubly Linked Lists

A singly linked list stores only a pointer to the next node.

typedef struct Node
{
    uint8_t value;
    struct Node *next;
} Node;

A doubly linked list stores both next and previous pointers.

typedef struct Node
{
    uint8_t value;
    struct Node *next;
    struct Node *previous;
} Node;

A doubly linked list allows traversal in both directions and makes removal easier when the node address is already known. However, it requires another pointer in every node and more pointer updates during insertion and removal.

Frequently Asked Questions

Are linked lists commonly used in embedded systems?

Yes, especially in operating systems, protocol stacks, event systems, driver registration, and memory managers. However, small bare-metal applications often prefer fixed arrays or ring buffers because they use less memory and are easier to analyze.

Should I use malloc for an embedded linked list?

It depends on the project. Dynamic allocation may be acceptable during initialization or on larger systems. For small or safety-sensitive microcontrollers, a fixed node pool usually provides more predictable behavior.

Is a linked list faster than an array?

Not in every operation. Inserting at the head of a linked list is fast, but finding the tenth element requires following the previous nine nodes. Arrays provide much faster indexed access and usually better memory locality.

Can linked-list nodes store structures?

Yes. A node can store sensor records, messages, tasks, timers, network packets, or other application-specific data.

What happens when a static node pool is full?

The allocation function returns NULL. The application must decide whether to reject the new item, report an error, reuse an older node, or increase the configured pool size.

Can I use a linked list inside an interrupt?

It is possible, but shared access must be designed carefully. Pointer updates can be interrupted halfway through, so critical sections or another synchronization method may be required.

Should UART data use a linked list?

Usually not. A fixed ring buffer is more compact and efficient for a stream of bytes. A linked list may be useful when each received item is a larger variable-size message rather than an individual byte.

Conclusion

A linked list connects separate data objects using pointers. The head identifies the first node, each node points to the next one, and the final node points to NULL.

The main linked-list operations are:

• Adding a node
• Removing a node
• Traversing the list
• Searching for a value
• Returning unused nodes to their allocator or static pool

For embedded systems, the pointer logic is only part of the design. You must also consider RAM overhead, allocation failure, fragmentation, interrupt safety, and worst-case execution time.

The visualizer at the beginning of this tutorial shows the logical connections between nodes. In an actual microcontroller, those nodes may be stored at completely different memory addresses. The pointers are what preserve their order.

For small and predictable firmware, I recommend starting with a singly linked list backed by a fixed node pool. It keeps the flexibility of linked nodes while avoiding the uncertainty of repeated heap allocation.

The post Linked List Visualizer for Embedded Systems appeared first on Teach Me Microcontrollers!.

A ring buffer is also called a circular buffer. The memory itself is still an ordinary C array. What makes it circular is the way its indexes return to zero after reaching the final array element.

This tutorial explains how an embedded ring buffer works, how its head and tail pointers move, and how you can implement one in C. You can also use the interactive visualizer below to see each operation happen.

Interactive Embedded Ring Buffer Visualizer

Enter a character, decimal byte, or hexadecimal value and click Write Byte. The value is stored at the current head position. Click Read Byte to remove the oldest value from the tail position.

Watch what happens when either pointer reaches the final slot. Instead of moving outside the array, it wraps around to index zero.

#define BUFFER_SIZE 8

typedef struct
{
    uint8_t data[BUFFER_SIZE];
    volatile uint8_t head;
    volatile uint8_t tail;
    volatile uint8_t count;
} RingBuffer;

bool ring_buffer_write(RingBuffer *rb, uint8_t value)
{
    if (rb->count >= BUFFER_SIZE)
    {
        return false;
    }

    rb->data[rb->head] = value;
    rb->head = (rb->head + 1U) % BUFFER_SIZE;
    rb->count++;

    return true;
}

bool ring_buffer_read(RingBuffer *rb, uint8_t *value)
{
    if (rb->count == 0U)
    {
        return false;
    }

    *value = rb->data[rb->tail];
    rb->tail = (rb->tail + 1U) % BUFFER_SIZE;
    rb->count--;

    return true;
}

What Is a Ring Buffer in Embedded Systems?

A ring buffer is a first-in, first-out or FIFO data structure built using a fixed-size array. The first value written into the buffer is normally the first value read from it.

Consider this eight-byte array:

uint8_t buffer[8];

A normal queue implementation might remove the first value and then shift every remaining value toward index zero. That approach works, but repeatedly moving data wastes processor time.

A ring buffer does not shift its contents. Instead, it keeps track of two indexes:

• Head — the position where the next value will be written
• Tail — the position where the next value will be read

When a value is written, the head advances. When a value is read, the tail advances. The data remains in the same physical array slots until those slots are reused.

This makes ring-buffer writes and reads fast and predictable. Both operations normally take constant time because no existing elements have to be moved.

Why Ring Buffers Are Useful in Embedded Applications

Microcontrollers often deal with events that do not happen at exactly the same speed as the main application.

For example, a UART peripheral may receive a byte while the processor is:

• Updating a display
• Reading a sensor
• Writing data to flash memory
• Processing a communication packet
• Executing another part of the main loop

The UART receive interrupt should not perform a large amount of processing. It should normally retrieve the received byte quickly, store it somewhere safe, and then return.

A ring buffer provides that temporary storage:

UART peripheral → RX interrupt → Ring buffer → Main application

The interrupt acts as the producer because it adds bytes. The main application acts as the consumer because it removes and processes them.

The same idea can be used for:

• UART receive and transmit queues
• ADC sample storage
• Sensor-data collection
• Logging systems
• CAN and SPI message queues
• Audio samples
• Keyboard or keypad input
• Data moving between interrupt handlers and the main loop

How the Head Pointer Works

The head points to the array position where the next byte will be stored.

Suppose the head is initially at index zero:

head = 0;

Writing the character 'A' stores it in buffer[0]. The head then moves to index one.

buffer[head] = 'A';
head++;

If the next value is 'B', it is stored in buffer[1], after which the head moves to index two.

The head always identifies the next available write position. It does not normally point to the most recently written value.

How the Tail Pointer Works

The tail points to the oldest unread value.

If the tail is at index zero, reading from the buffer returns the value stored in buffer[0]. The tail then advances to index one.

value = buffer[tail];
tail++;

The contents do not need to be shifted after the read. The application simply considers that slot available again.

Some implementations clear a slot after reading it because doing so makes debugging and visualization easier. Clearing the slot is not normally required for the ring-buffer algorithm itself.

Pointer Wraparound

The circular behavior appears when a pointer reaches the end of the array.

For an eight-element buffer, the valid indexes are zero through seven. If the head is at index seven, its next position must be index zero.

This can be written using the modulo operator:

head = (head + 1U) % BUFFER_SIZE;

With BUFFER_SIZE equal to eight:

(7 + 1) % 8 = 0

The same operation is used for the tail:

tail = (tail + 1U) % BUFFER_SIZE;

No data is physically moved from the end of the array back to the beginning. Only the index wraps around.

Detecting an Empty or Full Ring Buffer

A ring buffer must be able to determine whether another read or write is allowed.

The interactive visualizer uses a count-based implementation. In addition to the head and tail, it stores the number of elements currently inside the buffer.

uint8_t head;
uint8_t tail;
uint8_t count;

The buffer is empty when:

count == 0

It is full when:

count == BUFFER_SIZE

This method allows every array element to be used. An eight-element array can hold eight values.

Another common method avoids the count variable and reserves one array slot. In that version:

• head == tail means the buffer is empty.
• The buffer is full when advancing the head would make it equal to the tail.

That approach is especially useful for a single-producer, single-consumer ring buffer because the producer can own the head while the consumer owns the tail. I will return to that version later in the tutorial.

Basic Count-Based Ring Buffer in C

The following implementation matches the behavior of the visualizer. It stores eight bytes and rejects new data when the buffer is full.

#include <stdbool.h>
#include <stdint.h>

#define BUFFER_SIZE 8U

typedef struct
{
    uint8_t data[BUFFER_SIZE];
    uint8_t head;
    uint8_t tail;
    uint8_t count;
} RingBuffer;

Initializing the Buffer

Initialization places both pointers at index zero and sets the stored count to zero.

void ring_buffer_init(RingBuffer *rb)
{
    rb->head = 0U;
    rb->tail = 0U;
    rb->count = 0U;
}

The actual data array does not have to be cleared because no slot is considered valid while the count is zero.

Writing a Byte

bool ring_buffer_write(RingBuffer *rb, uint8_t value)
{
    if (rb->count >= BUFFER_SIZE)
    {
        return false;
    }

    rb->data[rb->head] = value;
    rb->head = (rb->head + 1U) % BUFFER_SIZE;
    rb->count++;

    return true;
}

The function first checks whether the buffer is full. If space is available, the value is written at the head position. The head advances, and the element count increases.

The function returns false when no more data can be accepted. The caller can use this result to record an overflow, increment an error counter, or take another appropriate action.

Reading a Byte

bool ring_buffer_read(RingBuffer *rb, uint8_t *value)
{
    if (rb->count == 0U)
    {
        return false;
    }

    *value = rb->data[rb->tail];
    rb->tail = (rb->tail + 1U) % BUFFER_SIZE;
    rb->count--;

    return true;
}

The read function checks for an empty buffer before accessing the array. It returns the oldest byte, advances the tail, and decreases the count.

Checking the Current State

bool ring_buffer_is_empty(const RingBuffer *rb)
{
    return rb->count == 0U;
}

bool ring_buffer_is_full(const RingBuffer *rb)
{
    return rb->count == BUFFER_SIZE;
}

uint8_t ring_buffer_used(const RingBuffer *rb)
{
    return rb->count;
}

uint8_t ring_buffer_free(const RingBuffer *rb)
{
    return BUFFER_SIZE - rb->count;
}

A Simple Ring Buffer Example

Here is how the buffer can be used from a normal C program:

RingBuffer rx_buffer;
uint8_t received_byte;

int main(void)
{
    ring_buffer_init(&rx_buffer);

    ring_buffer_write(&rx_buffer, 'A');
    ring_buffer_write(&rx_buffer, 'B');
    ring_buffer_write(&rx_buffer, 'C');

    if (ring_buffer_read(&rx_buffer, &received_byte))
    {
        /* received_byte contains 'A' */
    }

    if (ring_buffer_read(&rx_buffer, &received_byte))
    {
        /* received_byte contains 'B' */
    }

    while (1)
    {
        /* Main application */
    }
}

Even if the head wraps around while more values are written, the tail continues to return them in FIFO order.

Using a Ring Buffer for UART Reception

A UART receive ring buffer is one of the most common embedded applications.

The general flow is:

1. The UART peripheral receives a byte.
2. The receive interrupt runs.
3. The interrupt reads the UART data register.
4. The byte is written into the ring buffer.
5. The interrupt returns.
6. The main loop later reads and processes the buffered byte.

A simplified interrupt handler might look like this:

void UART_RX_IRQHandler(void)
{
    uint8_t value = uart_read_data_register();

    if (!ring_buffer_write(&rx_buffer, value))
    {
        uart_rx_overflow = true;
    }
}

The main loop can process the data without waiting inside the interrupt:

int main(void)
{
    uint8_t value;

    ring_buffer_init(&rx_buffer);
    uart_init();

    while (1)
    {
        while (ring_buffer_read(&rx_buffer, &value))
        {
            process_received_byte(value);
        }

        run_other_application_tasks();
    }
}

This arrangement lets the interrupt capture incoming data quickly while the main application performs the more time-consuming work.

A Concurrency Warning About the Count Variable

The count-based implementation is easy to understand and works well for the visualizer. However, notice what happens in the UART example:

• The interrupt increases count.
• The main loop decreases count.

Both execution contexts modify the same variable. An interrupt occurring during a read-modify-write operation may produce a race condition, depending on the microcontroller, variable width, compiler, and generated instructions.

Adding volatile prevents the compiler from treating a shared variable as if it never changes unexpectedly. It does not automatically make an operation atomic, and it does not by itself solve every concurrency problem.

You can protect a count-based implementation with a short critical section. Another option is to use a single-producer, single-consumer design where the interrupt modifies only the head and the main loop modifies only the tail.

Single-Producer, Single-Consumer UART Ring Buffer

For a typical UART receive buffer, there is one producer and one consumer:

• The UART RX interrupt is the only code that changes the head.
• The main loop is the only code that changes the tail.

The implementation below reserves one array slot so that head == tail can unambiguously represent an empty buffer.

#include <stdbool.h>
#include <stdint.h>

#define UART_BUFFER_SIZE 16U
#define UART_BUFFER_MASK (UART_BUFFER_SIZE - 1U)

typedef struct
{
    uint8_t data[UART_BUFFER_SIZE];
    volatile uint16_t head;
    volatile uint16_t tail;
} UartRingBuffer;

Because the masking optimization is used here, UART_BUFFER_SIZE must be a power of two.

Writing from the UART Interrupt

bool uart_ring_buffer_write_isr(
    UartRingBuffer *rb,
    uint8_t value)
{
    uint16_t head = rb->head;
    uint16_t next =
        (head + 1U) & UART_BUFFER_MASK;

    if (next == rb->tail)
    {
        return false;
    }

    rb->data[head] = value;
    rb->head = next;

    return true;
}

Reading from the Main Loop

bool uart_ring_buffer_read(
    UartRingBuffer *rb,
    uint8_t *value)
{
    uint16_t tail = rb->tail;

    if (tail == rb->head)
    {
        return false;
    }

    *value = rb->data[tail];
    rb->tail =
        (tail + 1U) & UART_BUFFER_MASK;

    return true;
}

This arrangement avoids a shared count variable. The producer publishes a new head only after writing the byte, while the consumer advances the tail only after retrieving it.

You should still check the requirements of your specific architecture. Index reads and writes should be naturally aligned and atomic for the chosen index type. Systems with multiple cores, DMA, an RTOS, cache coherency concerns, or more than one producer or consumer may require memory barriers, critical sections, or an operating-system synchronization primitive.

Modulo Versus Bit Masking

The general wraparound operation uses modulo:

next = (index + 1U) % BUFFER_SIZE;

This works for any valid buffer size.

If the size is a power of two, the index can instead be wrapped using a mask:

next = (index + 1U) & (BUFFER_SIZE - 1U);

For example, valid indexes for a 16-byte buffer are zero through 15. The value BUFFER_SIZE - 1 is therefore 0x0F.

Modern compilers can often optimize a constant modulo operation automatically. I would therefore prioritize clear and correct code first, then inspect the generated code if performance is critical.

Ring Buffer Overflow and Underflow

Overflow

An overflow occurs when the producer attempts to write while no space is available.

The buffer can respond in different ways:

• Reject the new value
• Overwrite the oldest unread value
• Set an overflow flag
• Increment a lost-byte counter
• Apply flow control when the protocol supports it

The visualizer rejects the new byte because this makes the loss of data obvious. Whether that is the correct behavior in a real project depends on the application.

For a command interface, losing an old or new character may invalidate the entire command. For continuous sensor history, overwriting the oldest sample may be acceptable.

Underflow

An underflow occurs when the consumer attempts to read an empty buffer.

A well-designed read function should detect this before accessing the array. Returning a Boolean result is useful because every possible byte value, including zero, may be valid data.

uint8_t value;

if (ring_buffer_read(&rx_buffer, &value))
{
    process_received_byte(value);
}
else
{
    /* No data currently available */
}

Choosing the Ring Buffer Size

The correct buffer size depends on how quickly data arrives and how long the consumer may be unable to process it.

A useful starting estimate is:

$N_{\min} \ge R_{\text{bytes}}T_{\text{delay}} + M$

Where:

• N_min is the minimum number of required slots.
• R_bytes is the incoming data rate in bytes per second.
• T_delay is the longest expected consumer delay in seconds.
• M is an additional safety margin.

For example, an 8-N-1 UART connection at 115200 baud uses approximately ten transmitted bits for every data byte: one start bit, eight data bits, and one stop bit.

$R_{\text{bytes}} \approx \frac{115200}{10} = 11520\text{ bytes/s}$

If the main application can be delayed for 5 milliseconds:

$N_{\min} \ge 11520 \times 0.005 = 57.6\text{ bytes}$

A 64-byte buffer is the smallest convenient power-of-two choice, but it leaves almost no margin. A 128-byte buffer may be more appropriate if RAM permits and occasional longer delays are possible.

If the implementation reserves one slot, remember that a 64-element array stores only 63 bytes.

Ring Buffer Versus an Ordinary Linear Buffer

Common Ring Buffer Mistakes

Confusing the Head with the Last Written Position

In the implementation used here, the head is the next write position. After writing to index three, the head normally advances to index four.

Failing to Distinguish Full from Empty

If the head and tail can be equal in both states, another piece of information is required. Use a count, reserve one slot, or store a separate full flag.

Using an Index That Is Too Small

The index type must be able to represent every valid buffer position. An eight-bit index is sufficient for buffers up to 256 elements, but larger buffers require a wider type.

Assuming Volatile Makes Everything Thread-Safe

volatile affects compiler optimization. It does not automatically protect a multi-step update from interrupts, multiple tasks, or another processor core.

Doing Too Much Work Inside the Interrupt

The receive interrupt should normally store the byte and return. Packet parsing, command execution, display updates, and other longer operations are better handled outside the ISR.

Ignoring Overflow

Even a correctly implemented ring buffer can overflow. Always decide how the application should detect and respond to lost data.

Frequently Asked Questions

Is a ring buffer the same as a circular queue?

The terms are often used interchangeably. Both normally describe FIFO storage that reuses a fixed array by wrapping its indexes. Ring buffer is particularly common terminology in embedded systems, drivers, communications, and streaming applications.

Does a ring buffer dynamically allocate memory?

It does not have to. Embedded implementations usually use a statically allocated array so memory usage is known at compile time and no heap allocation is required.

Can a ring buffer store structures instead of bytes?

Yes. The array can contain sensor samples, CAN frames, event structures, pointers, or other fixed-size objects.

typedef struct
{
    uint32_t timestamp;
    int16_t temperature;
    uint16_t pressure;
} SensorSample;

SensorSample sample_buffer[16];

Should a full ring buffer reject or overwrite data?

It depends on the application. Communication buffers often reject new data and report an overflow. History buffers may intentionally overwrite the oldest entry so they always contain the most recent samples.

Can DMA use a ring buffer?

Yes, although the design becomes more hardware-specific. Many microcontrollers support circular DMA modes that repeatedly fill a memory region. The application must then track which portion of the region has been written and which portion has already been processed.

Can I use this implementation with an RTOS?

You can, but a ring buffer shared by multiple tasks may require a mutex, critical section, semaphore, or RTOS queue. A lock-free single-producer, single-consumer implementation should not automatically be treated as safe for multiple producers or consumers.

Conclusion

A ring buffer gives embedded applications an efficient way to temporarily store streaming data without shifting array elements or allocating more memory at runtime.

The basic idea is simple:

• The head identifies the next write position.
• The tail identifies the next read position.
• Both pointers return to zero after reaching the end.
• Writes must detect a full buffer.
• Reads must detect an empty buffer.

The count-based approach used by the visualizer is useful for learning because the full and empty conditions are easy to see. For a real UART interrupt and main-loop arrangement, a single-producer, single-consumer implementation with separate head and tail ownership can reduce shared-state problems.

Try filling the visualizer, reading a few bytes, and then writing more values. The most important moment is when the head crosses the final index and returns to zero while the unread values remain in the correct FIFO order. Once that behavior is clear, the C implementation becomes much easier to understand.

The post Ring Buffer Visualizer for Embedded Systems appeared first on Teach Me Microcontrollers!.

(Click to view larger image)

ESP32-CAM Pinout Description

ESP32-CAM Schematic Diagram

The schematic diagram below is a useful reference, together with the pinout, as you make your project.

(Click to view larger image)

The post ESP32 Pinout Diagram | ESP32-CAM appeared first on Teach Me Microcontrollers!.

(Click to view larger image)

ESP32-WROVER Module Variants

ESP32-WROVER / WROVER-I

• The original module with integrated PSRAM (typically 4 MB)
• WROVER-I refers to the version with a U.FL (IPEX) antenna connector (instead of or in addition to PCB trace antenna)

ESP32-WROVER-B / WROVER-IB

• These versions operate their PSRAM at 3.3 V (vs. 1.8 V in earlier WROVER versions)
• The “IB” suffix again implies the variant with an IPEX connector for external antenna

ESP32-WROVER-E / WROVER-IE

• A newer revision, often supporting larger flash or PSRAM variants (for example, 8 MB PSRAM)
• The “IE” version includes the IPEX connector for external antennas

Custom Flash / PSRAM configurations

• Within each of these variants, you will often find options for different flash memory sizes (e.g. 4 MB, 8 MB, 16 MB) and PSRAM sizes
• Also, some modules may include or exclude onboard antenna or use external antenna connectors according to design.

ESP32-WROVER Pinout Description

The ESP32-WROVER has the same pinout as the ESP32-WROOM. The pins are categorized into digital pins, analog pins, and power pins. Refer to the table below for details on pins with secondary functions. Moreover, these secondary pins often serve communication purposes, such as I2C and SPI or as ADC channels.

ESP32 WROVER Schematic Diagram

The schematic diagram below is a useful reference, together with the pinout as you make your project.

(Click to view larger image)

Do you want some ESP32 project ideas? Check out the following tutorials:

• Sensor Display on ESP32 Web Server
• ESP32 Turbidity Sensor
• ESP32 Magnetometer using HMC5883L
• ESP32 MAX7219 WiFi Message Board
• Using Restful APIs with ESP32
• ESP32 Pressure Sensor

... and many more! See our ESP32 Tutorial archive.

The post ESP32 Pinout Diagram | ESP32-WROVER appeared first on Teach Me Microcontrollers!.

Like its predecessor, the ESP-12F is built around the ESP8266EX chip, which features a 32-bit Tensilica L106 processor running at 80 MHz (up to 160 MHz overclocked) and supports Wi-Fi 2.4 GHz (802.11 b/g/n). With 4 MB (32 Mbit) of flash memory, it is well-suited for applications like home automation, smart devices, and wireless sensors.

ESP-12F Pin Description

The ESP-12F has 22 pins, including power, GPIOs, and communication interfaces. Below is a breakdown of the key pin functions:

ESP-12F Pinout Table

Boot Modes

The ESP-12F supports different boot modes based on the state of GPIO0, GPIO2, and GPIO15:

Power Considerations

The ESP-12F requires a stable 3.3V power supply and can draw up to 170 mA during Wi-Fi transmissions. It is recommended to use an LDO voltage regulator or a dedicated power supply for reliable operation.

Applications

Due to its compact size, Wi-Fi capability, and low power consumption, the ESP-12F is commonly used in:

• Smart home devices (e.g., Wi-Fi switches, sensors)
• IoT projects
• Wireless data logging
• Home automation systems

The post ESP12F Pinout Diagram appeared first on Teach Me Microcontrollers!.

I2C (Inter-Integrated Circuit) is a widely used communication protocol in embedded systems, particularly in STM32 microcontrollers. Configuring the correct clock settings for I2C communication is crucial for reliable data transmission. However, calculating the necessary parameters, such as the Clock Control Register (CCR), the Rise Time Register (TRISE), and the Timing Register in newer STM32 versions, can be complex.

To simplify this process, we’ve developed an STM32 I2C Clock Calculator, which allows users to quickly determine the required settings based on the peripheral clock (PCLK) and the target I2C frequency. 

Understanding I2C Clock Configuration

STM32 microcontrollers implement I2C timing configuration through different registers depending on the version:

1. CCR (Clock Control Register): Determines the clock period based on the PCLK and the desired I2C frequency (older STM32 models).
2. TRISE (Rise Time Register): Ensures that the SDA and SCL lines meet the required timing constraints for correct signal transitions.
3. Timing Register: Used in newer STM32 microcontrollers (such as STM32F7, STM32H7, and STM32L4) to configure I2C timing more precisely.

I2C Modes in STM32

STM32 supports two primary I2C speed modes:

• Standard Mode (SM): Operates at a maximum of 100 kHz.
• Fast Mode (FM): Operates up to 400 kHz.

The formulas for computing CCR and TRISE values are as follows:

Standard Mode (≤ 100 kHz)

• CCR = PCLK / (2 * Target Frequency)

• TRISE = (PCLK / 1,000,000) + 1

Fast Mode (≤ 400 kHz)

• CCR = PCLK / (3 * Target Frequency)

• TRISE = (PCLK / 1,000,000) * 300 / 1000 + 1

For newer STM32 models, the Timing Register is used instead, requiring a more detailed calculation based on SCL timing constraints:

Timing Register Calculation (Newer STM32 Versions)

The Timing Register is composed of multiple fields:

• SCLL (Low period of SCL clock):

  (PCLK / (2 * Target Frequency)) - 1

• SCLH (High period of SCL clock):

  (PCLK / (2 * Target Frequency)) - 1

• SDADEL (Data hold time):

  (PCLK / 100,000,000) (Approximate placeholder)

• SCLDEL (Data setup time):

  (PCLK / 50,000,000) (Approximate placeholder)

The final Timing Register Value is calculated as:

TIMING = (SCLDEL << 20) | (SDADEL << 16) | (SCLH << 8) | SCLL

Using the STM32 I2C Clock Calculator

This tool provides a user-friendly interface where you can:

1. Select whether you are using an Older STM32 (CCR/TRISE) or Newer STM32 (Timing Register).
2. Enter the Peripheral Clock (PCLK) in Hz.
3. Specify the Target I2C Frequency in Hz.
4. Click "Calculate" to obtain the necessary timing values.

The post STM32 I2C Calculator appeared first on Teach Me Microcontrollers!.