标签：#esp32

Remember Tamagotchis? Those little egg-shaped keychains from the 90s with a pixelated pet that got hungry, got sad, and, if you were a negligent eight-year-old like me, got dead during math class. I've been looking for an excuse to play with the Waveshare ESP32-S3 Touch AMOLED 1.8" , a $30 board with a gorgeous 368×448 AMOLED touchscreen, an accelerometer, a microphone, and a speaker. And I found one: I'm building a Tamagotchi. But with a twist that makes it worth a four-article series The pet's body lives on the device. Its brain lives in AWS. The device renders an adorable pet and captures your taps and shakes. But its hunger, mood, and energy are rows in DynamoDB. It gets hungry overnight because EventBridge Scheduler says so. And, my favorite part (and because it's 2026, we can't not have genAI in a project 🤪), every morning it fetches the AWS news, has Amazon Bedrock rewrite them in its own squeaky personality, and reads them to me out loud through Amazon Polly. A Tamagotchi with a job. In this series, I will walk you through the whole build: This article : the architecture, and connecting the ESP32-S3 to AWS IoT Core (the pet's nervous system). Part 2 : giving it a face: animations and touch with LVGL on the AMOLED. Part 3 : the serverless brain: Lambda, DynamoDB, and a pet that gets hungry while you sleep. Part 4 : Bedrock + Polly: my Tamagotchi reads me the AWS news. ⚠️ Reality check before you get too excited (sorry 😅): this is a hobby project, not a product. You'll need the specific Waveshare board (or the patience to adapt the code to yours), an AWS account, and a USB-C cable. The AWS bill for the whole series is well under a dollar a month, but it is not zero, and neither is the time you'll spend staring at idf.py monitor . Worth it, though. All the code lives in this repository . Each article has its own branch. For this one, git checkout article-1 . Why put a pet's brain in the cloud? Fair question. The original Tamagotchi ran on a chip with less power

Modbus RTU over RS-485 is the serial workhorse of industrial field wiring — the variant you'll meet when connecting an ESP32 directly to an energy meter, PLC, VFD, or temperature transmitter over a wired bus. This tutorial walks through wiring the hardware, installing a library, and flashing working RTU master code. What You'll Build A Modbus RTU master on ESP32 that polls holding registers from an RS-485 slave device over a wired bus. An understanding of register types, addressing, and the reliability practices that separate a demo from a production deployment. Prerequisites Arduino IDE (or PlatformIO) with the ESP32 board package installed. An ESP32 dev board, or an industrial ESP32 controller with a built-in RS-485 transceiver such as the NORVI X — this saves you from wiring a separate MAX485 module. A Modbus RTU slave device (energy meter, sensor, or PLC). Basic familiarity with the Arduino C++ syntax and serial monitor debugging. A 60-Second Modbus Primer Modbus is a master–slave protocol dating back to 1979. One master polls up to 247 slave devices, each with a unique address (1–247). Data lives in four register types, and knowing which one you need is half the battle: Register Type Access Width Typical Use Coils (0x) Read/Write 1-bit Relay outputs, digital controls Discrete Inputs (1x) Read only 1-bit Digital sensor inputs, switch states Input Registers (3x) Read only 16-bit Analog sensor values, process data Holding Registers (4x) Read/Write 16-bit Setpoints, configuration parameters Modbus RTU over RS-485 Step 1 — Wire the Hardware The ESP32's UART pins output 3.3V TTL logic, but RS-485 uses a differential voltage signal — so you need a TTL-to-RS-485 transceiver (typically a MAX485 or MAX3485 chip) between the ESP32 and the bus. UART TX → transceiver DI (driver input) UART RX ← transceiver RO (receiver output) A spare GPIO → transceiver DE and RE tied together (direction control) Transceiver A/B terminals → the RS-485 A+/B− pair on your slave device Skip th

Want to turn a small ESP32 board into a mini arcade game you can actually play? This ESP32 OLED Mini Shooter Game uses a 128x64 OLED display and two push buttons to create a simple shooter experience. The player moves left and right, bullets fire upward, and enemies fall from the top of the screen. It is a small project, but it already feels like a real handheld game once the display starts updating. This build is a great next step after basic OLED and button tutorials. Instead of only printing text or drawing one shape, the code manages several moving objects at the same time. It tracks the player, bullets, enemies, collisions, and game-over state. The screen is divided into a simple grid. The 128x64 OLED becomes a 16x8 playfield, where each tile is 8x8 pixels. This makes object movement easier to understand because the player, enemies, and bullets move by grid position instead of raw pixel math. Why build it? This project teaches interactive programming on real hardware. The ESP32 reads button input, updates game objects, checks collisions, and draws the next frame on the OLED. That is much more active than a normal sensor display project. It also teaches timing without blocking the whole game flow. The code uses millis() to control when bullets and enemies update, so they can move at different speeds. This is useful because many embedded projects need timed actions without stopping everything else. What you'll learn ESP32 OLED display control - drawing text, squares, circles, and game objects on an SSD1306 screen. Custom I2C pins - using Wire.begin(5, 19) so the OLED uses GPIO5 for SDA and GPIO19 for SCL. Button input handling - reading two push buttons for left and right movement. Debounce logic - preventing one press from being counted many times. Grid-based game design - turning a 128x64 screen into a simple 16x8 game map. Game object arrays - storing multiple bullets and enemies with active/inactive states. Timer-based updates - using millis() to move bullets