求助各位靓仔，8 bit dma xmc lvgl问题
本帖最后由 万能的互联网 于 2023-11-18 18:06 编辑芯片是AT32F403ARGT764Pin显示屏st7789屏幕驱动代码是BSP里的 8bitxmc 引脚一样，屏幕ic也一样，
lvgl测试代码用的是SC0077_SourceCode_V2.0.1
xmc屏幕驱动这块的代码应该没问题吧，官方示例demo可以正常跑
乱改后的8bit dma xmc lvgl下载进去就成这样了，能跑，但是不多，只能跑一点点{:cry:}
搞不明白的部分代码截图
自己菜鸟一顿乱改，折腾了几天很明显失败了。全网都找不到at32的8bit dma xmc lvgl的参考代码，官方的5个demo都是16bit的，
github上的at32项目也是少的可怜，求助各位大佬！
也**官方把8bit dma xmc lvgldemo也补齐，方便他人移植。
问题代码链接: https://pan.baidu.com/s/12a7wByLk9ElvqRf50GeclQ?pwd=AT32
进度更新：
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屏就。。。
xi wang怎么成了屏蔽词？ dma改半字传输size直接默认 不x2 楼上正解，既然都是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
先验证DMA + XMC能不能正常显示，如果正常显示那就把LVGL加上在测试 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:08 编辑
万能的互联网 发表于 2023-10-29 16:40
xi wang怎么成了屏蔽词？
回复错了，尴尬！ 万能的互联网 发表于 2023-10-29 16:40
xi wang怎么成了屏蔽词？
如何 可以了吗 Addition 发表于 2023-10-30 14:21
先验证DMA + XMC能不能正常显示，如果正常显示那就把LVGL加上在测试
只玩过有手就行的ESP32 Arduino环境下的LVGL, arm的32还是第一次玩。DMA一窍不通，没有示例demo实在耍不来 如下函数参数配置为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:13
如何 可以了吗
还差一点点，拖影、残影严重！ 从你的图像来看，感觉颜色不正常，有点像RGB高低字节反了，再修改以下宏定义试试
修改前
#define LV_COLOR_16_SWAP 1
修改后
#define LV_COLOR_16_SWAP 0 xuexu 万能的互联网 发表于 2023-10-30 19:28
还差一点点，拖影、残影严重！
检查开窗函数 缓冲区给大点 本帖最后由 万能的互联网 于 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
本帖最后由 万能的互联网 于 2023-10-31 14:16 编辑
回忆酱 发表于 2023-10-31 08:50
检查开窗函数 缓冲区给大点
这个残影是我粗心大意了，只修改了MY_DISP_HOR_RES，没有同时去修改双缓，双缓数组大小用宏定义能避免这些不必要的错误。大佬有设置横屏方向的代码吗？目前还是竖屏，arduino环境下，写好了2个横屏和2个竖屏的切换函数。换到这个环境一脸懵。 为什么不上M4？ 单片小菜 发表于 2023-11-1 10:06
为什么不上M4？
不明白表达什么，403a不是M4单片机？ 这个真的没有用过的。 lajfda001 发表于 2023-11-2 08:58
这个真的没有用过的。
我也是第一次用并口，之前用spi没有遇到16位颜色和8位并口这个转换问题。这次还把屏幕的并口引脚画错了，屏幕是d8-d15，我以为是d0-d7，后来才知道有两种8bit引脚定义。踩坑，可以得到经验和教训，还是用16bit更保险。只好换大一号的100pin封装，多走几条线。
页:
[1]
2