【经验分享】怎样在ESP32平台上实现高效刷图动画

怎样在ESP32上流畅的播放动画

最近有一个预研项目，在ESP32上播放动画，于是来测试一下ESP32刷动态图的极限性能

1. 硬件以及内容描述

图片占用的ROM过大，因此需要使用一些编码方式降低ROM占用，直接刷屏是没办法的，需要:压缩->存储->提取->解压->推图

2. 屏幕驱动以及硬件性能测试

2.1 屏幕驱动

LCD在驱动上都比较简单，idf框架上有自带的历程，就是显示jpg图片的那个例程，仔细看了看idf的从下到上的封装，感觉idf框架写的还是很不错的

需要按照实际连线修改程序，并且修改TFT的背光引脚，背光使能状态等等，都是比较简单的

首先初始化SPI的接口，spi_bus_initialize，在这里可以把DMA打开，SPI的速度可以快很多，并且可以节省一部分CPU资源

然后初始化lcd,使用esp_lcd_new_panel_io_spi接口，初始化屏幕，在进行一系列的屏幕寄存器初始化，理论上就可以控制屏幕显示数据了

初始化完成后，使用推像素相关的函数就可以进行显示了

像屏幕推送数据时，可能存在显示异常的问题，我总结了几点：

• 屏幕黑屏：检查接线，背光是否正常
• 坐标不正常，xy坐标反了：检查LCD_CMD_MADCTL 0x36寄存器配置是否正常
• 图像镜像：检查LCD_CMD_MADCTL 0x36寄存器配置是否正常
• 图盘反色，类似于胶卷拍出来的颜色：检查LCD_CMD_INVON、LCD_CMD_INVOFF相关寄存器配置是否正常
• 颜色不正常，严重偏色等问题：尝试更换图片数据的大小端，修改显示格式为RGB还是BGR

我在测试过程中发现，使用屏幕显示RGB三个颜色，奇怪的是蓝色和绿色是反的，检查后才发现数据大小端和显示格式均有问题，翻转一下后就显示正常了

2.2 硬件性能测试

• 屏幕分辨率为240240，SPI速率为60Mbps，理论单帧的时间长度为1000 （921600/60000000）= 15.36ms
• 由于实际应用中SPI传输中存在间隙，底层分包，其他指令的影响，实际时长会比理论长很多
• 开启DMA刷屏时长：22~23ms
• 关闭DMA时长：41~42ms
• 由此可得硬件最大的帧率只有43FPS
• 如果想要更高的速率，可以使用SPI速率更高的屏幕，或者换一个屏幕通信接口 8bit并口或者QSPI

3. gif解码器测试

3.1 gif解码资源占用

将gif图像放在ESP32的QSPI flash中，占用大小为4.18MB

移植gifdec到esp32（gifdec使用比较简单，就是lvgl三方库中的解码器）

• RAM占用需要7*像素数量bytes，分辨率240的方图的情况下，需要约400KB
• 7份像素，其中三份为用户的RGB888缓存，三份为内部的RGB888缓存，一份为内部的索引缓存
• ESP32S3不支持这么大的RAM，只能降低像素数量然后再尝试

3.2 gif解码实际测试结果

实际测试，在gif解码过程中，由于不同图像帧的复杂度不同，解码时间在80ms~350ms中间跳动，基本上没有可用性

3.3 结论

• RAM占用太大
• 解码时间太慢
• 就算解码时间与内存可以优化，但是差距过大，此路不通

4. jpg

jpg格式是现在用的最多的解码器，广泛应用在在线网站、日常通信软件中。jpg是一种有损压缩格式，通过牺牲人眼不敏感的部分达到降低图片内存占用的效果，压缩率根据质量不同在10:1左右

4.1 idf自带的jpeg解码器

• idf默认的是tiny jpeg解码器，纯C语言实现

• 实际测试中，解码一帧240方图需要48ms左右

  4.1 JPEGDEC解码器

• 实际测试，纯C语言解码一帧需要22ms左右
• 使用基于汇编的SIMD优化，解码时间降低到13ms
• 可以在SPI在DMA传输的过程中进行解码

• 实时解码刷屏测试，显示速率已经达到了43~45帧

  4.2 idf自带的jpeg-new解码器

• 在论坛分享经验，一个大佬分享esp官方自带的新jpeg库，组件名字为 esp_new_jpeg （https://whycan.com/t_11604.html）
• 合入到工程中，实际测试，解码一帧240方图只需要7ms左右，效果很好
• 但是这个库是非开源的，并且每个ESP32的型号实现方式不一样，速度也不一样，S3的速度是最快的

5.结论

在ESP32S3平台下，使用esp_new_jpeg解码器可以实现很快的刷屏速度，并且目前平台的瓶颈为屏幕的SPI速率，更换性能更好一些的屏幕，速率理论可以突破60帧