Digital communication only works reliably when both devices understand the same voltage levels. A HIGH signal from one device must be recognized as HIGH by the other device, and the voltage must stay within the safe input range.

Many modern microcontrollers, such as the ESP32, use 3.3 V logic. Some older modules or Arduino-style boards use 5 V logic. Connecting a 5 V output directly to a 3.3 V input can damage the microcontroller pin.

• Check the logic voltage: Confirm whether each device uses 3.3 V or 5 V signals.
• Use level shifting when needed: A logic level shifter can safely connect different voltage systems.
• Share ground: Communication signals need a common ground reference.
• Do not confuse power and signal voltage: A module powered by 5 V may still use 3.3 V logic, or the opposite.

Practical example: If a 5 V sensor sends a digital output to an ESP32 input, check the sensor output voltage first. If it outputs 5 V, use a level shifter or a suitable voltage divider before connecting it to the ESP32.

UART is a simple serial communication method that uses separate transmit and receive lines. One device sends data from TX, and the other device receives it on RX. This is commonly used for debug messages, GPS modules, Bluetooth modules, USB serial adapters, and communication between microcontrollers.

UART does not use a clock line. Both devices must use the same baud rate, such as 9600, 115200, or another configured speed. If the baud rate is wrong, the received text will usually appear as unreadable characters.

• Cross TX and RX: TX from one device usually connects to RX on the other device.
• Match the baud rate: The sender, receiver, and serial monitor must use the same speed.
• Connect ground: A missing common ground can make communication unstable or completely fail.
• Check voltage level: USB serial adapters can be 3.3 V or 5 V logic.

Practical example: In a PC status monitor project, the PC can send live system data over USB serial to an ESP32. If the ESP32 receives unreadable text, first check baud rate, port selection, and the expected message format.

I2C is a two-wire bus that uses SDA for data and SCL for clock. It is often used for sensors, small displays, real-time clocks, I/O expanders, and other low-speed modules. Multiple devices can share the same SDA and SCL lines if every device has a unique address.

I2C lines need pull-up resistors. Some modules already include them, but not all do. If the pull-ups are missing, too weak, or connected to the wrong voltage, the bus may not work correctly.

• Run an I2C scanner: This confirms whether the device responds and shows its address.
• Check SDA and SCL: Swapping the two lines is a common wiring mistake.
• Use pull-ups: Typical values are often around 4.7 kΩ to 10 kΩ, depending on the bus and wiring.
• Keep wiring short: Long jumper wires can make I2C unreliable.
• Watch address conflicts: Two devices with the same fixed address cannot normally share the same bus.

Practical example: A BH1750 light sensor can be connected over I2C. If the sensor is not detected, check power, ground, SDA, SCL, pull-ups, and whether the scanner finds the expected address.

SPI is a fast communication bus often used for TFT displays, LED drivers, memory chips, SD cards, and high-speed sensors. It typically uses a clock line, a data line from controller to device, a data line from device to controller, and one chip-select line per device.

Unlike I2C, SPI does not use addresses. Instead, the controller selects one device at a time using its chip-select pin. If the wrong chip-select pin is configured, the device may stay silent even when all other wires are correct.

• Check pin names: MOSI, MISO, SCK, and CS may be named differently on different boards.
• Use the correct CS pin: Each SPI device usually needs its own chip-select line.
• Check SPI mode and speed: Some devices require specific clock polarity, phase, or maximum frequency.
• Keep wires short: High-speed SPI is sensitive to long jumper wires and poor grounding.
• Confirm display configuration: TFT displays often also need DC, RESET, and backlight pins.

Practical example: If a TFT display stays white or black, check the SPI pin mapping, chip-select pin, display driver type, reset pin, and whether the selected library matches the display controller.

Communication problems are easiest to solve when you check them step by step. Do not start by changing code randomly. First prove that power, ground, wiring, voltage level, and pin configuration are correct.

A multimeter can confirm static voltages and continuity, but it cannot show fast data signals properly. For UART, I2C, SPI, PWM, and clock lines, an oscilloscope or logic analyzer is much more useful.

• Start with power: Confirm the module receives the correct supply voltage.
• Check ground: A missing shared ground is a common cause of failed communication.
• Verify wiring: Use continuity mode from controller pin to module pin.
• Look for activity: A scope or logic analyzer can show whether data is actually present.
• Use known-good examples: Test the module with a simple library example before integrating it into a large project.

Practical example: If an I2C sensor does not respond, first run an I2C scanner. If no address appears, measure the power pins, check SDA/SCL continuity, inspect pull-ups, and then look at the bus with a logic analyzer if needed.