核心内容摘要
亲测好用的5款低代码平台，新手也能上手
ST7789在高刷新穿戴设备中“卡顿”的真相：不是驱动写得差，是芯片根本没打算跑60Hz你有没有遇到过这样的场景？
心率波形刚画到一半，屏幕突然横着撕开一道白线；手表表盘切换动画明明写了60fps，实际拖成幻灯片；DMA配置调了三天，TXE标志还是隔三差五被覆盖，SPI overrun中断满屏飘……最后发现——问题不在代码，也不在PCB布线，甚至不是MCU性能不够。
是ST7789，从出生那天起，就没被设计用来干这事。
这不是一句吐槽，而是数据手册第3页就埋下的伏笔：“For high-speed animation, use parallel interface with 16-bit bus”。
它没说“别用SPI跑60Hz”，但这句话的潜台词，比任何警告都更直白。
它到底能跑多快？
先撕掉“16MHz SPI”的滤镜很多工程师看到数据手册里写着“SPI max 16MHz”，第一反应是：“16MHz ÷ 8 = 2MB/s，240×240@16bpp才115KB/帧 → 理论轻松撑60Hz！
”错。
这个算法，漏掉了ST7789最致命的三个“隐性周期税”。
第一笔税：命令不是免费的每帧开始前，你必须发：-0x2C（写GRAM指令）→ 至少8个SCLK-0x2A+0x2B（设窗口X/Y）→ 各8~12 SCLK，共约20+- CS拉高再拉低建立时间 → 每次至少4 SCLK这些加起来，一帧光“打招呼”就要≈35个SCLK。
对240×240屏来说，占比微乎其微；但对只刷10×10脏区域的小动效，它直接吃掉30%有效带宽。
第二笔税：它不认“连续流”，只认“字节包”