The AI-Thinker ESP32-CAM put a Wi-Fi camera within almost everyone’s reach, and taught a whole generation of makers patience along the way. It has no USB port, so every flash needs an external USB-to-UART adapter and a jumper on GPIO0. Of its 16 header pins only a handful are actually free, and the flash LED blinks every time the program writes to the memory card.

The board in this article is the same idea, finished properly. It carries an ESP32-S3 with 16 MB of flash and 8 MB of PSRAM, a 5 MP OV5640 camera, a microSD slot, two USB-C ports and all 36 GPIOs of the module on its headers. There is one catch: once the camera and the memory card are running, only six of those pins are truly free. What follows is a detailed map of the board: what is wired to what, which port does which job, which pins you can take, and how to set up the Arduino IDE so the camera does not turn into a puzzle.

Which board this is about

Shops sell this board under several names: ESP32-S3-CAM, ESP32-S3 WROOM CAM, ESP32-S3 CAM Development Board. The board itself modestly says ESP32-S3 WROOM, and the metal shield of the module reads ESP32-S3-N16R8. That marking is the key specification: N16 stands for 16 MB of flash, R8 for 8 MB of PSRAM. The module is an ESP32-S3-WROOM-1 with a PCB antenna.

The layout copies the Freenove ESP32-S3-WROOM CAM: the same camera position, the same pins, two buttons and two USB-C ports. Freenove ships its board with a 2 MP OV2640 camera, while the one in this article carries a 5 MP OV5640, as the marking on its ribbon cable shows. Boards like this come from several factories, and the camera module and the USB-to-UART bridge can change from batch to batch. Before hunting for a driver or somebody else’s example, it is worth checking what your own board is marked with.

Specifications

A little arithmetic. A 5 MP frame in RGB565 takes 2592 × 1944 × 2 = 10,077,696 bytes, about 9.6 MiB. That is more than the whole 8 MB of PSRAM, which is why full resolution is only available as JPEG, compressed by the sensor itself. A UXGA frame of 1600 × 1200 in the same RGB565 takes about 3.7 MiB and does fit. In practice the camera almost always runs in JPEG: it needs less memory and is easier to send over Wi-Fi.

Two USB-C ports, and which one does what

The ports are not labelled on the front: the USB-UART and USB-OTG labels are printed on the back. That sets up a classic mirror trap, because once the board is turned face up, the label on the left sits under the right-hand port. Seen from the camera side, with the antenna at the top, the picture is this:

Which port gets the Serial output is decided by the USB CDC On Boot setting in the Arduino IDE. With Disabled, Serial is UART0 and the messages go to the right port. With Enabled, Serial moves to the native USB, which is the left port. If the Serial Monitor stays silent, this setting and the port the cable is plugged into are the first things to check. The ROM bootloader prints to both ports by default.

The left port has a less obvious advantage too. The USB Serial/JTAG controller built into the ESP32-S3 lets you debug with breakpoints without an external adapter and without a single extra pin. That is particularly valuable here, because the default external JTAG pins (GPIO39–42) are partly taken by the memory card on this board.

The headers, pin by pin

The tables assume the board lies component side up, antenna at the top and USB ports at the bottom. The pin numbers on the silkscreen carry marks: underlined pins belong to the camera, a tilde marks the microSD pins and an asterisk the PSRAM ones. The legend is printed on the back.

Left header, top to bottom

Right header, top to bottom

Pins 35–37 do come out on the header, but they are off limits: in modules with Octal PSRAM they are wired to the memory inside, and any external signal on them interferes with it.

36 GPIOs, and how many of them are yours

Put everything together and the picture is sobering:

So with the camera and the memory card running, six pins are free without conditions: GPIO1, 14, 21, 41, 42 and 47. That is enough for an I²C sensor, a couple of buttons and a relay, but not for a sprawling set of peripherals. You can win back a couple more by giving up one of the USB routes: if the board only ever talks through the right port, GPIO19 and GPIO20 are released. If it only uses the left one, GPIO43 and GPIO44 are worth a try, bearing in mind that they are still wired to the USB-to-UART bridge.

Analogue inputs are trickier. On the ESP32-S3, ADC1 is GPIO1–10 and ADC2 is GPIO11–20. The camera takes almost every ADC1 pin, so with the camera running the only clean analogue input is GPIO1. GPIO2 and GPIO3 belong to ADC1 too, but the first drives an LED and the second is a strapping pin. GPIO14 belongs to ADC2, and ADC2 shares resources with Wi-Fi: while the radio is busy, a reading may be delayed or fail. For sensors in a Wi-Fi project, choose ADC1. The touch inputs Touch1–Touch14 live on GPIO1–14, but of those only GPIO1 and GPIO14 are free without conditions.

And four rules about the strapping pins that save an evening:

1. GPIO0 is the BOOT button. If it is low at reset, the chip enters download mode instead of running the program. External circuitry must not pull GPIO0 to ground during start-up.
2. GPIO46 is pulled down by default and selects the boot mode together with GPIO0. GPIO0 low with GPIO46 high at reset is an invalid combination.
3. GPIO45 sets the memory supply voltage: low at reset means 3.3 V, high means 1.8 V. This module’s flash and PSRAM are 3.3 V parts, so GPIO45 must not be high during reset. It is pulled down by default, and that is how it should stay.
4. GPIO3 selects the JTAG signal source, but only if the corresponding eFuse bit has been burned; on a module with factory settings its level is ignored. Espressif still lists it as a strapping pin, so it is better not to make it the first home for a button.

The camera: an OV5640 on the right pin map

The camera sits on a parallel DVP bus: eight data lines, three sync lines, the XCLK clock and a pair of SCCB lines to configure the sensor, 14 GPIOs in all. The PWDN and RESET pins are not connected on this board, so the configuration sets them to -1.

The main trap is somebody else’s pin map. The most popular examples online are written for the AI-Thinker ESP32-CAM, and on an ESP32-S3 its GPIO numbers point, among other things, at pins 26–32, which the S3 gives to its internal memory, and at 22–25, which the S3 does not have at all. The good news is that this board’s wiring matches Espressif’s ESP32-S3-EYE exactly, and the Arduino core already describes that board.

In the CameraWebServer example (File → Examples → ESP32 → Camera), the model is chosen in board_config.h. The default there is CAMERA_MODEL_ESP_EYE, which is a different board built on the original ESP32. Comment that line out and uncomment CAMERA_MODEL_ESP32S3_EYE. This is how that model’s pins look in camera_pins.h, exactly as on our board:

#define PWDN_GPIO_NUM  -1
#define RESET_GPIO_NUM -1
#define XCLK_GPIO_NUM  15
#define SIOD_GPIO_NUM  4
#define SIOC_GPIO_NUM  5

#define Y2_GPIO_NUM 11
#define Y3_GPIO_NUM 9
#define Y4_GPIO_NUM 8
#define Y5_GPIO_NUM 10
#define Y6_GPIO_NUM 12
#define Y7_GPIO_NUM 18
#define Y8_GPIO_NUM 17
#define Y9_GPIO_NUM 16

#define VSYNC_GPIO_NUM 6
#define HREF_GPIO_NUM  7
#define PCLK_GPIO_NUM  13

For this model the example flips the picture vertically on its own with set_vflip. If the image comes out upside down, toggling V-Flip in the web interface is enough; the resolution is raised there too, since the stream starts in QVGA. A missing PSRAM, on the other hand, the example survives silently: if psramFound() returns false, the frame size is capped at SVGA and the buffer moves to internal memory. The camera still works, but far from at full strength.

If the stream stays black

The OV5640 has a known quirk on this board. Owners have reported that the example initialises the camera without errors, an OV2640 works on the same board, and the OV5640 delivers a black frame. According to their reports, changing the XCLK clock helps: 24 MHz or 12 MHz instead of the default 20 MHz. In setup() that is a single line, xclk_freq_hz; the other fields show what it is usually combined with:

camera_config_t config;
// ... pins as in camera_pins.h ...
config.xclk_freq_hz = 24000000;   // 20 MHz gave black frames on some OV5640 boards; 12 MHz is the other reported fix
config.pixel_format = PIXFORMAT_JPEG;
config.frame_size   = FRAMESIZE_UXGA;
config.jpeg_quality = 10;
config.fb_location  = CAMERA_FB_IN_PSRAM;
config.fb_count     = 2;
config.grab_mode    = CAMERA_GRAB_LATEST;

If that does not help, check that the ribbon cable is fully seated and its latch closed, and that the board is not overheating: the same discussions advise against keeping it in a closed case without ventilation while the camera runs. The sensor’s full resolution, FRAMESIZE_5MP at 2592 × 1944, is only available in JPEG.

Arduino IDE settings

The board needs no separate package: the standard ESP32S3 Dev Module profile from arduino-esp32 does the job. What matters most is describing the memory correctly, because that decides whether the program sees the PSRAM at all.

If flashing stops working, for example because the program reconfigured the native USB or fell into a reboot loop, put the board into the bootloader by hand: hold BOOT, briefly press EN, release BOOT and upload again. The right port may need a driver for the USB-to-UART bridge on your computer. The original Freenove board uses a CH343, clones sometimes carry other chips, so go by what the device manager actually reports. Current operating systems recognise the left port as a serial port without a separate driver.

microSD, LEDs and buttons

The microSD slot is wired for SDMMC in 1-bit mode: CMD on GPIO38, CLK on GPIO39, D0 on GPIO40. That is slower than 4-bit mode but saves three pins. Two of the three lines coincide with the default external JTAG pins (MTCK and MTDO), so the card and an external debugger get in each other’s way; with a card inserted, debugging through the left USB port is the easier route.

There are five LEDs. ON shows power, TX and RX flicker with traffic through the USB-to-UART bridge, IO2 is a user LED on GPIO2, and 48 is a WS2812-compatible addressable RGB LED on GPIO48. In the ESP32S3 Dev Module profile, both LED_BUILTIN and RGB_BUILTIN point at that RGB LED, so the stock Blink sketch lights it white. Its colour is set with rgbLedWrite(); the older neopixelWrite() is deprecated.

EN restarts the module, and BOOT is wired to GPIO0 for entering the bootloader by hand. Once the program is running, BOOT can be read like any other button. A quick self-test of the board mounts the card and reports the result in colour:

#include "SD_MMC.h"

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

  // One-bit SDMMC: CLK, CMD, D0
  SD_MMC.setPins(39, 38, 40);

  if (SD_MMC.begin("/sdcard", true)) {
    Serial.printf("microSD: %llu MB\n", SD_MMC.cardSize() / (1024 * 1024));
    rgbLedWrite(RGB_BUILTIN, 0, 32, 0);   // green: card mounted
  } else {
    Serial.println("microSD: mount failed");
    rgbLedWrite(RGB_BUILTIN, 32, 0, 0);   // red: no card
  }
}

void loop() {}

Power and heat

The board takes power through either USB-C port or the 5V pin. The 3V3 pin is the output of the board’s regulator and can feed low-power 3.3 V sensors. The GPIOs work at 3.3 V only: a 5 V signal on an input can damage the module, whose absolute maximum supply voltage is 3.6 V.

The camera, Wi-Fi transmission and card writes all cause current peaks. The module datasheet asks for a supply that can deliver at least 0.5 A, and a weak USB port or a long, thin cable easily falls short. The symptoms are easy to recognise: the board resets the moment the stream starts, and the log shows a message from the brownout detector. The cure is a short, decent cable and a proper 5 V power supply.

The second limit is less obvious: temperature. Modules with Octal PSRAM, the N16R8 included, are rated for an ambient temperature of up to 65 °C, whereas the variants without PSRAM go up to 85 °C. Espressif notes that enabling PSRAM error correction (ECC) raises the limit to 85 °C at the cost of 1/16 of the memory. The camera and the radio keep warming the board, so inside a closed case in the sun that margin disappears quickly; plan ventilation holes from the start.

What to build on it: three telling cases

1. A camera for the 3D printer

Checking on a print from another room, and collecting a time-lapse along the way, is the most natural job for a board like this. Prusa-Firmware-ESP32-Cam, the firmware that connects a camera to the Prusa Connect service, has a dedicated page for the Freenove ESP32-S3-WROOM. The camera modules tested there are OV2640s, so OV5640 compatibility is something to find out for yourself, but the board layout is the same.

2. A time-lapse recorder with its own card

The microSD slot turns the board into a standalone recorder: wake on a timer, take a JPEG, write it to the card and go back to sleep. That is how people film plants growing, a building site across the street or a slow process in the workshop. The board is not optimised for battery power, though: the ON LED is always lit, and the camera’s PWDN pin is not connected, so the sensor cannot be powered down in hardware, only put into its software standby over SCCB. Sleep current will be noticeably higher than for a bare module; that does not matter for a mains-powered time-lapse, but it does on batteries.

3. A USB webcam and vision on the device itself

Native USB lets the ESP32-S3 present itself to a computer as a webcam. Espressif’s esp-iot-solution has a usb_webcam example: the board becomes a UVC device streaming MJPEG, and the example’s list of modes includes 1280 × 720 at 15 frames per second. By default it builds for the ESP32-S3-EYE, which means the same pin map as this board. The other direction is processing frames on the device itself: Espressif’s ESP-WHO framework targets the ESP32-S3 and can, for instance, detect faces with no cloud involved.

Strengths and weaknesses

Bottom line

The ESP32-S3-CAM N16R8 is an ESP32-CAM with nearly all of its teething troubles cured: proper USB, plenty of memory, a replaceable 5 MP camera and honest marking of the taken pins right on the board. For a workshop camera, a time-lapse, keeping an eye on a 3D printer or experimenting with machine vision, it is a very convenient base.

The price of that convenience is a tight fit. The camera and the memory card eat almost every pin, the PSRAM has to be enabled correctly, and the OV5640 may need its clock tuned. Before the first flash it pays to run through a short list:

1. ESP32S3 Dev Module profile: 16 MB flash, QIO 80MHz, PSRAM set to OPI PSRAM.
2. Pin map: CAMERA_MODEL_ESP32S3_EYE, not AI-Thinker.
3. Frame buffers in PSRAM, format JPEG.
4. microSD as 1-bit SDMMC on GPIO38, 39 and 40.
5. The cable in the port that matches the USB CDC On Boot setting.
6. New connections on GPIO1, 14, 21, 41, 42 and 47 first.
7. GPIO0, 3, 45 and 46 kept free of circuits that change their level at reset.

An ordinary development board can do a great deal, but it talks to the developer mostly through lines in the Serial Monitor. The LILYGO TTGO T-Display has a more convincing way of doing it: a colour screen on the board itself. Wire up a sensor and you see the readings straight away. Pull data over Wi-Fi and you can draw a graph or a status line. Build a standalone instrument and there is no separate display to add, no power to route to it and no room to find for it inside the enclosure.

That is why the T-Display is more interesting than just another ESP32 board. It is very nearly a finished front panel for a device: a microcontroller, a screen, two buttons, USB-C and single-cell Li-Po charging on one narrow circuit board.

Which board this is about

The name T-Display has grown into a whole family, so the first technical trap is to take the specifications of the wrong model. What follows is about the classic LILYGO/TTGO T-Display on the original ESP32, with a 1.14-inch screen and a resolution of 135 × 240 pixels. This is not the T-Display-S3: the S3 has a different processor, a 1.9-inch screen, a different display connection, different GPIOs and PSRAM.

Current LILYGO documentation lists the SoC of the classic board as ESP32-D0WDQ6. Flash size and the USB-to-UART chip can differ between production batches, so a seller’s description or somebody else’s example code is no substitute for checking the board in your hand.

Specifications

A couple of numbers give a sense of the scale. A full frame in RGB565 takes 135 × 240 × 2 = 64,800 bytes, which is about 63.3 KiB. Two frame buffers are already around 126.6 KiB, before the Wi-Fi stack, the tasks and the application’s own data. That is why partial redraws, modestly sized sprites and updating only the regions that changed are especially useful on this board.

Why the built-in display earns its place

The screen here is useful as a development tool, not as decoration. It shortens the path from a prototype to something you can use without a computer.

• Instant feedback. The device itself shows whether it joined Wi-Fi, what IP address it was given, what the sensor returned and why the actuator did not fire.
• A local interface. Two buttons and a colour screen are enough for a menu, several pages, warnings and simple settings without a mobile app.
• Diagnostics on the spot. If the sensor sits in a distribution board, a greenhouse or on a machine, the key readings are visible next to the equipment and not only in the cloud.
• A compact, finished prototype. Add a battery and an enclosure and the T-Display already looks like a pocket instrument, a remote or a miniature monitoring panel.
• A fast way to show the idea. A client or a colleague finds a live screen of statuses easier to judge than a stream of numbers in a terminal.

The screen sets limits too. It is small and it is not a touchscreen, and six of the ESP32’s signals are already spoken for by the display. A backlight left on all the time makes a noticeable difference to battery life. Complex graphics run short of memory without PSRAM, so the T-Display is at its best not as a tiny smartphone but as a clear interface built from a few well-chosen readings.

What is already wired to the ESP32

It is sensible to treat these pins as taken. SPI does in theory allow several devices to share the MOSI and SCLK lines, but for a first project it is safer to leave GPIO18 and GPIO19 to the screen and put an external SPI bus on free pins.

The headers, pin by pin

The tables below assume the display facing you and the USB-C connector at the bottom.

Left header, top to bottom

Right header, top to bottom

SVP and SVN are the historical names of the SENSOR_VP and SENSOR_VN analogue inputs, that is GPIO36 and GPIO39. They are not power pins.

How to choose GPIOs without unpleasant surprises

For ordinary digital inputs and outputs the first candidates are GPIO17, 21, 22, 25, 26, 27, 32 and 33. It makes sense to keep GPIO21 and GPIO22 for I²C.

For a second SPI bus, the official LILYGO factory example uses a convenient group:

For analogue sensors with Wi-Fi switched on, choose ADC1: GPIO32, 33, 36, 37, 38 or 39. On the classic ESP32, ADC2 shares a resource with Wi-Fi, so reading GPIO2, 12, 13, 15, 25, 26 or 27 as analogue inputs may simply not work while the radio is running. GPIO36–39, meanwhile, are input only and need an external pull resistor if the sensor or the button relies on one.

There are three more rules that save a particularly large amount of time:

1. GPIO0, 2, 5, 12 and 15 are read during reset as strapping pins. Connected peripherals must not force their start-up levels.
2. GPIO34–39 are inputs only and have no software pull-up or pull-down. On the board itself, GPIO34 and GPIO35 are already taken by the battery and by a button.
3. A load must not be powered straight from a GPIO. A relay, a motor, a solenoid or a high-power LED strip is switched through a transistor, a MOSFET or a driver with whatever protection it needs.

Power and battery life

The board takes power over USB-C and supports a single-cell Li-Po through a 1.25 mm two-pin connector. The cell can be charged on the board, and its voltage measured on GPIO34 once the sense circuit has been enabled with GPIO14. That is convenient for a charge indicator of your own, but a percentage cannot be obtained reliably from a simple linear formula: Li-Po voltage changes non-linearly, and the ADC of the original ESP32 needs calibration.

The T-Display should not be mistaken for an ultra-frugal sensor node just because the ESP32 itself can deep-sleep. Hobbyist measurements of the classic board have produced rough figures of around 66 mA when active, 80–140 mA with Wi-Fi running and roughly 9 mA in light sleep. These are not datasheet guarantees: the result depends on brightness, firmware, supply quality and board revision. The main practical conclusion is to switch the backlight off or dim it, turn the radio off between sessions and wake the device with a button or a timer.

What people build on a T-Display: three telling cases

1. A local Home Assistant screen

One of the most natural uses is to show a temperature, power consumption, the state of the heating or any other Home Assistant entity. In one published project the board displays the oven temperature through ESPHome, but the same template fits the time of the next train, the level in a tank or an internet speed. The value of this case is the minimal hardware: for a fixed panel, the T-Display and USB power are all it takes.

2. A departure board by the door

The open project ttgo-departure-board turns the board into a public transport display. The repository holds 33 firmware variants for networks in 17 countries: the ESP32 joins Wi-Fi, syncs the time over NTP, queries an API roughly every 30 seconds and updates the countdown every second. The two buttons switch stops and control the screen. It is a good example of an interface where 240 × 135 pixels is not too little: if you show only the direction, the line, the platform and the minutes, that is exactly as much information as you need before leaving the house.

3. A tiny wireless monitor

In 2025 a project drew attention by sending a shrunken image of the desktop over Wi-Fi to a compatible T-Display board. The computer compares frames and sends only the pixels that changed, applying batching and RLE. On an almost static picture its author reached up to 60 frames per second, and around 5 frames per second under heavy motion, with latency below 100 ms on a good network. It is not a practical replacement for a monitor, but it is a fine demonstration of how a traffic-saving algorithm can squeeze unexpectedly much out of an ESP32 and a small SPI display. One thing matters here: the project used a compatible TENSTAR board with 16 MB of flash, so that figure cannot be carried over to any LILYGO automatically.

Another popular layer is mini-games. Two buttons, a colour screen and ready-made libraries have produced Space Shooter, Breakout and small handheld builds carrying several games at once. That is entertainment and, at the same time, a decent teaching bench for sprites, frame rate, button handling and memory management.

What people look for most often, and why

Four themes repeat in the top results for queries about the classic T-Display: the first run, configuring TFT_eSPI, the pinout, and ready-made projects — clocks, weather, Home Assistant, MQTT panels and games. That is an accurate reflection of the board’s strengths and weaknesses.

People are drawn in by how quickly they can get a good-looking result, and most often they stumble over the configuration of this particular display. TFT_eSPI needs the Setup25_TTGO_T_Display.h profile; it pins down the ST7789V, the 135 × 240 geometry and the correct GPIOs. On alternative stacks you have to account for the offset of the active area of the matrix, the BGR colour order and separate backlight control. A telling failure: the program and the LCD itself can both be working, yet the screen looks black simply because GPIO4 never switched the backlight on.

The minimal Arduino test, once the TFT_eSPI profile has been selected, looks like this:

#include <TFT_eSPI.h>

TFT_eSPI tft;

void setup() {
  pinMode(4, OUTPUT);
  digitalWrite(4, HIGH);

  tft.init();
  tft.setRotation(1);              // 240 × 135
  tft.fillScreen(TFT_BLACK);
  tft.setTextColor(TFT_CYAN, TFT_BLACK);
  tft.drawString("Wi-Fi: OK", 12, 12, 4);
}

void loop() {}

In the Arduino IDE the manufacturer recommends the ESP32 Dev Module profile, a CPU frequency of 240 MHz, QIO, 4 MB of flash for the ordinary version, PSRAM disabled and an upload speed of 921600. If the firmware does not start or the bootloader does not answer, GPIO0 is used as BOOT: hold the button down, tap Reset, release BOOT and try the upload again.

Strengths and weaknesses

Bottom line

The LILYGO TTGO T-Display is valuable not for record specifications but for a well-judged layout. It turns the invisible work of a microcontroller into an interface you can read: the device reports its state immediately, shows measurements, takes commands from two buttons and can run on a battery.

For a desk clock, a Home Assistant indicator, a portable meter, an MQTT remote, a mini-game or a networked departure board, the classic T-Display remains a very sensible foundation. The main thing is to remember its age and its limits: do not confuse it with the T-Display-S3, do not count on PSRAM, protect the boot GPIOs, use ADC1 while Wi-Fi is active and check the flash size of the particular board. If 240 × 135 pixels and two buttons are enough for the project, the built-in screen saves not only components but the most expensive resource in prototyping — the time between an idea and the first result you can actually see.