基于 32G12K128 实验箱 V9.62_实验之TFT彩屏驱动+LCM+DMA

浦江***

"2.4寸彩屏" 搜索一下, 有好几家的...
比如: 轩特佳电子...
https://item.taobao.com/item.htm ... NECKjMGMY_SLyLPajHm
(这是答坛友问,不是做广告,不宜则删...)

浦江***

tzz1*** 发表于 2024-9-9 07:45
发个链接我看看

用"2.4寸彩屏"关键词,搜索一下,有好几家...  (是无法发链接的)

wa***

横屏显示这种斜纹撕裂现象怎么解决？{:5_324:}

浦江***

wa*** 发表于 2024-9-17 15:08
横屏显示这种斜纹撕裂现象怎么解决？

本实验只是测试一下刷新屏幕的速度，并没有想到刷新过程中会出现什么现象，而需要去解决的。

不管是横屏还是竖屏，估计是一样的。所谓刷屏， 就是把描述整屏色点的数据输入到显示屏的显示屏内存中去。
总会有一个从左到右、从上到下的填色过程的。只是如果速度超越人的视觉暂留时间时，感觉不到而已。
当用录像方式拍摄时，也有一个扫描过程，两者并非绝对同步，可能会产生另外的刷新变色现象。
然后再逐祯去查看，就会看到这种逐行变色的奇怪现象了。
如果称这种现象为“斜纹撕裂现象”，并且认为是一个问题，必须要克服解决之的话，
那么是否可尝试，在刷屏之前，先关闭显示，待整屏数据传输完毕后，再打开显示。
这样就看不到也就捕获不到这种“斜纹撕裂现象”了。
不过会产生一个新的问题： 那就是刷新屏幕时，会出现一个短暂的黑屏现象。
尽管时间短，但还是有可能被捕获的。
如果觉得这黑屏现象也是一个问题，不能接受，而必须要解决之的话，那么只有另辟蹊径了。
或许双显示缓存切换？或选更高速的显示屏？......

浦江***

wa*** 发表于 2024-9-17 15:08
横屏显示这种斜纹撕裂现象怎么解决？

其实在刷屏时, 用一种颜色点逐行扫描变成另一种颜色, 本身并不会产生所谓"斜纹撕裂现象", 而之所以产生上述图示现象, 是因为拍摄录像时的"再创作"...(随感光度的变化和和迟滞的效应)

jove***

能够把TFT屏修改为320x480的吗？
最好是9488 驱动 IC

浦江***

jove*** 发表于 2024-11-1 10:16
能够把TFT屏修改为320x480的吗？
最好是9488 驱动 IC

谢谢你的关注和参与回复.
从理论上讲,用32G12K128芯片来驱动320*480的TFT显示屏当然是可以的.
在基于V9.62实验箱的条件下,
这个问题先要从硬软件两方面来考虑的.
不知你说的9488驱动屏是什么接口.
一般而言320*480这样的并口屏都是16位数据线的.
而实验箱的TFT屏是8位数据线驱动的,是针对2.4寸原Arduino标准设计的.
因此硬件和软件都要大幅度的改动了, 估计, 比较费心.

补充:
在某宝上看到有3.5寸320*480TFT显示屏模块,是ILI9488驱动的,SPI八针接口,商家给DEMO链接,例程可参考.

神***

浦江*** 发表于 2024-8-30 10:10
神管所言极是!  共同心声，学用DMA的初衷就是要"解放CPU,让CPU去干更重要的事".

只是目前所看到的Demo “ ...

38ms，DMA-i8080并口 8位刷TFT320*240彩屏@ILI9341, AI8051U 实验箱 - TFT/LCD12864/LCD1602/红外遥控 国芯技术交流网站 - AI32位8051交流社区 (stcaimcu.com)

浦江***

首先感谢神管的留言指点。

近来对AI8051U的DMA方面的学习实验，有了一点点了解，谈谈粗浅体会：

1，AI8051U的DMA相对STM32系列单片机的DMA，并不逊色，其架构的复杂性（多通道途径）和寄存器的众多，不是初学者短时间内能完全领悟吃透的。
    还有待化时间多学习、理解和运用，关键还是要多实验，光看资料例程是不够的。
2，官方例程或在坛里能看到的一些例程代码中，在DMA触发传输启动后确实加有等待完成的语句（这是有据可查的），
    对此，初学者容易误解，容易懵，容易问“为什么要等呢？这不占用了CPU时间吗"？ 至少初学者已有一个“DMA不应该让CPU等待”的概念了。
    其实代码中有等待语句，是编程者在做某针对性的例程时，认为此时CPU无需干其它事，并不是在说，这种芯片的DMA就必须等待。
    事实上，完全可以不等待，CPU立马就可干其它事，只是要把控好，在这一次DMA传输没有完成之前，不要再启动这DMA的新传输就行。
    当然，对DMA传输期间的这段时间把控和充分利用，是需要技巧的。
3，在用DMA驱动彩屏，以及实现显示屏刷新快慢速度的问题上，不同方案存在差异。
     其实, DMA的数据传输的速度，是由CPU的主频、指令周期的特性、以及显示屏接口特性等因素决定的，理论上应该可计算出来。
     这与是否裸机或加什么操作系统，是没有关系的。
     之所以有所差异，是由于编程思路、方案上的差异，看你是否能真正充分利用了DMA功能特性和CPU的空余时间。
4， 就本贴实验具体而言，清屏（用一色填满屏），耗时78ms，这是包括加载数据到缓存和DMA将数据传输的LCM的两部分时间的。
     事实上，传输同样数量的数据，加载缓存Buf的耗时与DMA送LCM的耗时比较，是基本接近的（可以测试下）。
     因此，与称“38ms”（不算加载缓存时间）的结论，是基本相符的。注意，本实验就是裸机。
5，同样用DMA方式，清屏和显示一幅满屏的图片，是不能相提并论的。
     清屏是一次加载缓存数据，后面若干次DMA循环转送，期间不需要加载新数据。
     而显示满屏图片，每次DMA传送前都要加载新数据，因此显示满屏图片耗时比清屏耗时要长。
     显然显示满屏图片比清屏更有实用意义，更值得学习研究。
6，RTOS主要用于多任务系统，可以更充分地利用CPU的空余时间。
     如果用RTOS做一个单任务的实验，犹如杀鸡用牛刀，其实际效果应该与裸机相似，而裸机代码量更少，效率更高。
     裸机并不限制DMA的性能，RTOS也并不提升DMA的性能。
     DMA是CUP功能性能的一部分，DMA的数据传输能力，本身就是CPU数据传输能力的体现。

上述体会认知，粗浅，谬误，见笑了。

胡***

这个好玩哎