2-把缓冲定义到内部区域:
在全局区域定义:
uint16_t my_buf1[LCD_WIDTH * LCD_HEIGHT];
uint16_t my_buf1[LCD_WIDTH * LCD_HEIGHT];
3-修改图像缓冲
static lv_disp_buf_t disp_buf2;
lv_disp_buf_init(&disp_buf2, my_buf1, my_buf2, LCD_WIDTH * LCD_HEIGHT * 2);
disp_drv.buffer = &disp_buf2;
4-修改初始化 LCDIF 时的缓冲区
BOARD_LCDIF_rgbConfig.bufferAddr = my_buf2;
但是,显示效果跟DEMO效果一样,那可以断定时SDRAM有问题。
经过各种测试之后,发现将 dqsMode 定义为 kSEMC_Loopbackinternal 并增加 SEMC时钟的分频,拉到最大的/8之后显示效果就跟在内部RAM里面的效果一致了。
这么看果然还是由于SDRAM读写太快跟不上导致的。
但是这里还存在一个花屏的问题
又是经过一番测试,终于发现可以通过在 DEMO_FlushDisplay 这个刷新函数里面添加块处理函数解决:
DCACHE_CleanInvalidateByRange((uint32_t)color_p, BOARD_LCDIF_PANEL_WIDTH * BOARD_LCDIF_PANEL_HEIGHT *2);
(二)不同版本IDE之间的坑
由于在一次偶然的折腾中发现在同一台物理机上的双系统,linux下编译只需要15s,但双系统的windows下同样的程序却需要1分30秒,,足足慢了6倍,于是决定用linux开发。
但因为linux用的是一个全新的环境,所以安装了一个最新的linux下的mcuxpresso IDE,结果好好的一个程序无法运行了,一番折腾下,发现原来是最新的IDE配置SEMC 存储空间竟然是按M来算的,在V11.1.0版本里是按k算的,所以没有初始化足够多的空间,一访问就硬件错误了。
`