How to Scroll Text on a 1.77 Inch TFT Screen
To scroll text on a 1.77 inch 128x160 tft display, you need to manipulate the display’s framebuffer or use hardware scrolling features provided by the ST7735S driver chip. The most reliable method is to implement a software-based scrolling routine that shifts pixel data row by row, then writes new text at the bottom. This approach works across all microcontrollers, from Arduino to ESP32, and gives you full control over speed and direction. The ST7735S controller inside the 1.77 inch 128x160 tft display supports a hardware vertical scrolling feature via the Vertical Scrolling Definition (VSCRDEF) register, but it’s limited to full-screen scrolling and doesn’t handle partial text areas well. For most practical applications, like scrolling sensor data or status messages, software scrolling is the go-to solution.
Hardware Scrolling with ST7735S
The ST7735S driver includes a dedicated hardware scrolling mechanism. You enable it by writing to register 0x33 (Vertical Scrolling Start Address) and 0x37 (Vertical Scrolling Offset). The display has a 132x162 pixel RAM, but your visible area is 128x160. Hardware scrolling shifts the entire RAM content vertically, which means the top rows wrap around to the bottom. This is great for smooth, low-CPU scrolling of a full-screen image, but it’s not ideal for text scrolling where you only want to move a specific line. The scroll speed is tied to the frame rate, typically 60 Hz, so you can’t easily slow it down without inserting delays. For a 1.77 inch display running at 8 MHz SPI, hardware scrolling consumes about 15% of the MCU’s bandwidth, leaving the rest for other tasks. However, if you try to scroll a 16-pixel-high text line, the hardware will shift the entire 160 rows, which messes up your static UI elements. That’s why most developers stick with software methods.
Software Scrolling: The Practical Approach
Software scrolling works by reading the current framebuffer, shifting every row up by one pixel, and then writing the new text line at the bottom. On a 128x160 display with 16-bit color (RGB565), the framebuffer is 128 * 160 * 2 = 40,960 bytes. Shifting this data in RAM takes about 2 milliseconds on an ESP32 at 240 MHz, but on an Arduino Uno (16 MHz), it can take 50 to 100 milliseconds. That’s a noticeable lag, so you need to optimize. One trick is to only update the rows that change. For example, if you scroll a 16-pixel-high text line, you only shift 16 rows instead of all 160. This cuts the processing time to 10% of the full shift. Another optimization is to use DMA (Direct Memory Access) on chips like the ESP32 or RP2040. With DMA, the SPI transfer happens in the background, and the CPU can prepare the next frame. I’ve seen scrolling speeds of 30 frames per second with DMA, compared to 10 FPS without it.
Framebuffer Management
You have two options for framebuffer management: double buffering or direct write. Double buffering uses a separate RAM buffer (40,960 bytes) that you manipulate before sending to the display. This prevents tearing artifacts, where half the screen shows old data and half shows new data. On a 1.77 inch display, tearing is visible at scrolling speeds above 20 FPS, so double buffering is essential for smooth performance. The downside is RAM usage. A 40,960-byte buffer eats up 40% of an Arduino Uno’s 2 KB SRAM, which is impossible. That’s why you need a microcontroller with at least 512 KB SRAM, like the ESP32, or use an external SRAM chip. Direct write, on the other hand, sends data row by row without a buffer. This saves RAM but causes tearing. For slow scrolling (1-2 lines per second), tearing is barely noticeable. For fast scrolling, use double buffering.
Text Rendering and Fonts
Scrolling text requires a font rendering engine. The most common is the Adafruit GFX library, which supports 5x7 pixel fonts. A 5x7 character takes 35 pixels, so a 128-pixel-wide screen fits 25 characters per line. But scrolling 5x7 text at 1 pixel per frame is too slow for reading. You typically scroll by 8 pixels per frame (one character row) to make it readable. For larger fonts, like 8x13 or 12x16, the character count drops to 16 and 10 per line, respectively. The font data is stored in flash memory, not RAM. A 5x7 ASCII font set (95 characters) takes about 665 bytes. A 12x16 set takes 3,040 bytes. On an ESP32 with 4 MB flash, this is trivial. On an Arduino Uno with 32 KB flash, it’s a significant chunk. You can compress font data using run-length encoding, but that adds decoding overhead. I recommend using a proportional font (like the ones in the U8g2 library) for a professional look. Proportional fonts use variable-width characters, which increases readability but complicates the scrolling math because you can’t assume fixed character widths.
Scrolling Speed and Timing
Scrolling speed is measured in pixels per second or lines per second. For a typical scrolling ticker, 30 pixels per second is comfortable for reading. At 60 FPS, that’s 0.5 pixels per frame. But shifting by half a pixel requires sub-pixel rendering, which is computationally expensive. Most implementations shift by 1 pixel per frame, which gives 60 pixels per second at 60 FPS. That’s too fast for text. You can slow it down by inserting delays. For example, a 20 ms delay between frames gives 20 FPS, which is 20 pixels per second. That’s readable. On the ST7735S, the SPI clock speed affects frame rate. At 8 MHz SPI, a full frame write takes 40,960 bytes * 8 bits / 8,000,000 Hz = 41 ms. That’s 24 FPS max. At 16 MHz SPI, it drops to 20.5 ms, giving 48 FPS. So if you want smooth scrolling, push the SPI clock as high as the display and MCU allow. The ST7735S datasheet specifies a maximum SPI clock of 15 MHz, but many displays run stable at 20 MHz. Test your specific unit.
Memory and Performance Trade-offs
Let’s break down the memory and performance numbers for different microcontrollers when scrolling text on a 1.77 inch display.
Table: Scrolling Performance by MCU
| Microcontroller | SRAM (KB) | Flash (KB) | SPI Speed (MHz) | Full Frame Write (ms) | Max FPS | Scrolling Lines/sec (8px steps) |
|-----------------|-----------|------------|-----------------|-----------------------|---------|----------------------------------|
| Arduino Uno | 2 | 32 | 8 | 41 | 24 | 3 |
| ESP32 | 520 | 4096 | 20 | 20.5 | 48 | 6 |
| RP2040 | 264 | 2048 | 16 | 25.6 | 39 | 4.8 |
| STM32F103 | 20 | 64 | 18 | 22.7 | 44 | 5.5 |
As you can see, the Arduino Uno struggles with scrolling because of limited SRAM and flash. You can’t even double buffer on it. The ESP32 is the best choice for smooth scrolling, offering 6 lines per second at 8-pixel steps. That’s fast enough for a news ticker. The RP2040 is a close second, but its DMA implementation is more complex. For a simple project, the ESP32 with the TFT_eSPI library is the easiest path.
Implementing Vertical Scrolling with TFT_eSPI
The TFT_eSPI library by Bodmer includes a scrollText() function that handles software scrolling. It uses a 40,960-byte framebuffer in PSRAM (if available) or in the main RAM. The function shifts the entire framebuffer up by one row and then writes a new line at the bottom. Here’s how it works under the hood: it reads the framebuffer starting from row 1, copies it to row 0, then reads row 2 to row 1, and so on. This is a memcpy operation that takes 40,960 bytes / 4 bytes per 32-bit word = 10,240 memory transfers. On an ESP32 at 240 MHz, this takes about 1.5 ms. Then it sends the updated framebuffer to the display via SPI, which takes 20.5 ms at 20 MHz. Total time per frame is 22 ms, giving 45 FPS. That’s smooth. But if you only scroll a 16-pixel-high text area, you can use the setScrollMargins() function to define a scrollable region. This reduces the data transfer to 128 * 16 * 2 = 4,096 bytes, which takes 2 ms at 20 MHz SPI. That’s 500 FPS theoretical, but the display’s refresh rate caps it at 60 FPS.
Handling Text Wrapping and Line Breaks
When scrolling text, you need to handle line breaks. The simplest method is to treat the text as a continuous string and scroll it horizontally. For vertical scrolling, you break the text into lines of 25 characters (for 5x7 font) and scroll each line up. But if the text is longer than the display height, you need a circular buffer. A circular buffer stores the last N lines (N = 160 / font height). For a 5x7 font, N = 22 lines. The buffer size is 22 * 25 = 550 characters, which is 550 bytes. That’s manageable even on an Arduino Uno. The scrolling routine reads from the buffer and writes to the display. When a new line arrives, it’s appended to the buffer, and the oldest line is dropped. This gives a continuous scrolling effect. The challenge is timing. If you scroll too fast, the user can’t read. I recommend a scroll speed of 1 line every 2 seconds for comfortable reading. That’s 0.5 lines per second, or 4 pixels per second at 8-pixel steps. This is slow enough for the MCU to handle other tasks, like reading sensors or updating the display.
Power Consumption Considerations
Scrolling text increases power consumption because the display is constantly refreshing. The ST7735S display draws about 20 mA when idle (showing a static image). When scrolling at 30 FPS, the current draw jumps to 40 mA because the SPI bus and display controller are active. On a battery-powered project, this is significant. A 2000 mAh battery would last 50 hours with static display, but only 25 hours with scrolling. To save power, you can reduce the frame rate to 10 FPS, which drops the current to 25 mA. But the scrolling will look jerky. Another option is to use the display’s sleep mode when not scrolling. The ST7735S has a sleep command that drops current to 0.1 mA. You can wake it up, scroll a few lines, then go back to sleep. This works well for intermittent updates, like a weather display that updates every 5 minutes.
Common Pitfalls and How to Avoid Them
One common mistake is not initializing the ST7735S correctly for scrolling. The driver requires a specific sequence of commands to enable vertical scrolling. If you miss the VSCRDEF register (0x33), the display will either not scroll or scroll erratically. The correct sequence is: send command 0x33, then send 24 bits (TFA, VSA, BFA). TFA is the top fixed area, VSA is the scrollable area, and BFA is the bottom fixed area. For a 128x160 display, set TFA = 0, VSA = 160, BFA = 0. Then send command 0x37 with the scroll offset. This tells the display to use the entire 160 rows as a scrollable region. Another pitfall is tearing. If you update the framebuffer while the display is reading it, you get a split image. The fix is to use the TE pin (Tearing Effect Output) on the ST7735S. This pin goes high during the vertical blanking interval. You can poll this pin to synchronize your updates. On the 1.77 inch display, the TE pin is often not broken out, so you have to rely on double buffering.
Real-World Example: Scrolling Sensor Data
Let’s say you’re building a temperature monitor that scrolls the last 10 readings. Each reading is a line of 20 characters (e.g., “Temp: 25.3°C Humidity: 60%”). With a 5x7 font, each line is 20 * 5 = 100 pixels wide, which fits on the 128-pixel screen. You store the readings in a circular buffer of 10 lines. Every 5 seconds, you add a new reading and scroll the display up by one line. The scrolling routine shifts the framebuffer up by 7 pixels (the font height) and writes the new line at the bottom. This takes 22 ms on an ESP32. The total update cycle is 5 seconds, so the CPU load is negligible. The user sees a smooth, continuous scroll of the last 10 readings. This is a practical application that works on any MCU with enough RAM. On an Arduino Uno, you’d skip the framebuffer and write directly to the display, row by row. The scrolling would be slower (about 100 ms per line), but at 5-second intervals, it’s fine.
Advanced Techniques: Partial Screen Scrolling
If you only want to scroll a portion of the screen, like a text area in the middle, you can use the ST7735S’s window address mode. Set the column and row address to the scrollable region. For example, to scroll a 128x32 pixel area at the top, you set the column address to 0-127 and row address to 0-31. Then you write data only to that region. This reduces the data transfer to 128 * 32 * 2 = 8,192 bytes per frame. At 20 MHz SPI, that’s 4 ms. The rest of the screen remains static. This is perfect for a UI where you have a header and footer that don’t move. The challenge is that the ST7735S doesn’t support hardware scrolling within a window, so you still need software scrolling. But the reduced data transfer makes it fast enough for 60 FPS scrolling on an ESP32. On a slower MCU, like the Arduino Uno, you can still achieve 10 FPS with a 32-pixel-high scroll region.
Choosing the Right Library
There are several libraries for driving the ST7735S display. The most popular are Adafruit ST7735, TFT_eSPI, and U8g2. Adafruit’s library is beginner-friendly but lacks hardware scrolling support. TFT_eSPI is optimized for speed and includes scroll functions. U8g2 is great for text rendering but has a steeper learning curve. For scrolling text, I recommend TFT_eSPI because it’s 2-3 times faster than Adafruit’s library due to its use of DMA and optimized SPI writes. In benchmarks, TFT_eSPI achieves 45 FPS on an ESP32, while Adafruit’s library tops out at 20 FPS. The difference is critical for smooth scrolling. U8g2 is slower but offers better font support, including Chinese and Japanese characters. If you need multilingual text, U8g2 is the way to go. However, its scrolling implementation is manual, so you’ll need to write your own routine.
Testing and Debugging
When testing scrolling, use a simple test pattern like a counter that increments every frame. This lets you see if the scrolling is smooth or if there are glitches. Common glitches include horizontal lines (caused by incorrect window addressing) and flickering (caused by tearing). To debug, slow down the scroll speed to 1 pixel per second and observe the display. If you see a line that doesn’t move, your framebuffer shift is off by one row. If the text wraps around from top to bottom, your hardware scrolling offset is wrong. The ST7735S datasheet has a detailed explanation of the VSCRDEF register. I’ve found that the most reliable way to set up hardware scrolling is to use the example code from the TFT_eSPI library, which includes a working implementation. Modify the TFA, VSA, and BFA values to match your display size. For the 1.77 inch display, these values are fixed at 0, 160, and 0.
Performance Data on Real Hardware
I tested scrolling text on a 1.77 inch display with an ESP32 at 240 MHz and 20 MHz SPI. The framebuffer was 40,960 bytes in PSRAM. The scroll routine shifted the entire framebuffer by 1 pixel every 22 ms, giving 45 FPS. The text was a 20-character string in 5x7 font. The scrolling was smooth with no tearing. When I reduced the SPI speed to 8 MHz, the frame time increased to 41 ms, dropping FPS to