求助各位靓仔，8 bit dma xmc lvgl问题

只看该作者 · 2023-10-29 16:36

本帖最后由万能的互联网于 2023-11-18 18:06 编辑

芯片是AT32F403ARGT7 64Pin 显示屏st7789 屏幕驱动代码是BSP里的 8bit xmc 引脚一样，屏幕ic也一样，
lvgl测试代码用的是SC0077_SourceCode_V2.0.1

xmc屏幕驱动这块的代码应该没问题吧，官方示例demo可以正常跑

乱改后的8bit dma xmc lvgl 下载进去就成这样了，能跑，但是不多，只能跑一点点

搞不明白的部分代码截图

自己菜鸟一顿乱改，折腾了几天很明显失败了。全网都找不到at32的8bit dma xmc lvgl的参考代码，官方的5个demo都是16bit的，
github上的at32项目也是少的可怜，求助各位大佬！
也**官方把8bit dma xmc lvgl demo也补齐，方便他人移植。

问题代码链接: https://pan.baidu.com/s/12a7wByLk9ElvqRf50GeclQ?pwd=AT32

问题代码链接.zip (328 Bytes)

进度更新：
231030；经过各位靓仔的帮忙，问题向着好的方向发展了！只剩下拖影残影这一问题。
231031；现在只剩下颜色的问题

最后的样子

虽然鸽了一段时间，我还是没能解决问题。但我觉得有必要把，搜寻到的相关线索整理一下，也许说不定以后，也有人遇到类似的问题。

先来看一下LVGL中对16位颜色的相关定义，首先是RGB的16位颜色分配，这是一个共用体。

当LV_COLOR_16_SWAP 为1时，green好像分为高3位和低3位。
在项目中搜索 LV_COLOR_DEPTH == 16 和 LV_COLOR_16_SWAP == 0 ，能找到更多关于颜色的配置代码。

很显然，要弄懂这些代码，还要学习更多关于16位颜色的知识。

硬件方面，我用的是可视角度更高的IPS屏幕。显示屏可以设置RGB和BGR模式，尝试将显示屏配置为BGR模式，问题依旧。

再经过了解，TN屏幕和IPS屏幕也是不同，在TN屏幕中颜色正常，换到IPS可能就遇到反色了。

可能的解决思路：如果是并口的颜色高低位问题，那么换到100pin的16位并口，也许能解决问题。
如果还是有问题，那么也许只能无奈的放弃DMA刷屏。
最后，也许换个更差劲的TN屏就。。。

只看该作者 · 2023-10-29 16:40

xi wang怎么成了屏蔽词？

只看该作者 · 2023-10-30 09:08

dma改半字传输 size直接默认不x2

只看该作者 · 2023-10-30 11:23

楼上正解，既然都是byte传送，size不应该x2了。
另外，因为你是竖屏显示，如下的
#define MY_DISP_HOR_RES 320
#define MY_DISP_VER_RES 240
是否应修改为
define MY_DISP_HOR_RES 240
#define MY_DISP_VER_RES 320

只看该作者 · 2023-10-30 14:21

先验证DMA + XMC能不能正常显示，如果正常显示那就把LVGL加上在测试

只看该作者 · 2023-10-30 14:46

muyichuan2012 发表于 2023-10-30 11:23
楼上正解，既然都是byte传送，size不应该x2了。
另外，因为你是竖屏显示，如下的
#define MY_DISP_HOR_RES ...

为啥DMA设置那里目标地址和源地址都是同样的：(__IO uint32_t)XMC_LCD_DATA；就算是从M->M也应该是不同的地址吧

只看该作者 · 2023-10-30 19:07

本帖最后由万能的互联网于 2023-10-30 19:08 编辑

万能的互联网发表于 2023-10-29 16:40
xi wang怎么成了屏蔽词？

回复错了，尴尬！

只看该作者 · 2023-10-30 19:13

万能的互联网发表于 2023-10-29 16:40
xi wang怎么成了屏蔽词？

如何可以了吗

只看该作者 · 2023-10-30 19:20

Addition 发表于 2023-10-30 14:21
先验证DMA + XMC能不能正常显示，如果正常显示那就把LVGL加上在测试

只玩过有手就行的ESP32 Arduino环境下的LVGL, arm的32还是第一次玩。DMA一窍不通，没有示例demo实在耍不来

只看该作者 · 2023-10-30 19:22

如下函数参数配置为0可以加速XMC访问速度，或许有所帮助。
修改前
  /* bus turnaround phase for consecutive read duration and consecutive write duration */
  xmc_ext_timing_config(XMC_BANK1_NOR_SRAM4, 0x08, 0x08);
修改后
  /* bus turnaround phase for consecutive read duration and consecutive write duration */
  xmc_ext_timing_config(XMC_BANK1_NOR_SRAM4, 0x0, 0x0);

只看该作者 · 2023-10-30 19:28

回忆酱发表于 2023-10-30 19:13
如何可以了吗

还差一点点，拖影、残影严重！

只看该作者 · 2023-10-30 19:59

从你的图像来看，感觉颜色不正常，有点像RGB高低字节反了，再修改以下宏定义试试
修改前
#define LV_COLOR_16_SWAP 1
修改后
#define LV_COLOR_16_SWAP 0

只看该作者 · 2023-10-30 21:12

xuexu

只看该作者 · 2023-10-31 08:50

万能的互联网发表于 2023-10-30 19:28
还差一点点，拖影、残影严重！

检查开窗函数缓冲区给大点

只看该作者 · 2023-10-31 13:53

本帖最后由万能的互联网于 2023-10-31 14:10 编辑

muyichuan2012 发表于 2023-10-30 19:59
从你的图像来看，感觉颜色不正常，有点像RGB高低字节反了，再修改以下宏定义试试
修改前
#define LV_COLOR_ ...

这个宏不打开，就会全部糊掉。
//看看头文件内容，感觉没啥问题
#if LV_COLOR_16_SWAP == 0
# define _LV_COLOR_ZERO_INITIALIZER16 {{0x00, 0x00, 0x00}}
# define LV_COLOR_MAKE16(r8, g8, b8) {{(uint8_t)((b8 >> 3) & 0x1FU), (uint8_t)((g8 >> 2) & 0x3FU), (uint8_t)((r8 >> 3) & 0x1FU)}}
#else
# define _LV_COLOR_ZERO_INITIALIZER16 {{0x00, 0x00, 0x00, 0x00}}
# define LV_COLOR_MAKE16(r8, g8, b8) {{(uint8_t)((g8 >> 5) & 0x7U), (uint8_t)((r8 >> 3) & 0x1FU), (uint8_t)((b8 >> 3) & 0x1FU), (uint8_t)((g8 >> 2) & 0x7U)}}

我也觉得是RGB高低字节的问题，8bit和16bit画点函数的差异

//8bit
void lcd_write_one_point(uint16_t color)
{
  lcd_wr_data(~(color) >> 8);
  lcd_wr_data(~color);
}

//16 bit
void lcd_write_one_point(uint16_t color)
{
  lcd_wr_data(color);
}

但是在dma中，已经用不到  lcd_write_one_point  这个画点函数

//现在怀疑最有可能的突破口，这一句
DMA1_CHANNEL5->paddr  = (uint32_t)color_p;

keil5打不开这个结构体指针的定义，我想能不能在这里，对color的高低字节进行处理。或者，有其他更好的办法。
没想到整个问题，最后的重点还是color