Keep me updated.
At the weekend, I want to clean up the code and to add drivers for other STM discovery boards. Then the same Mbed source code can be used for these. But this Chinese board is still my favorite, it should become a vapor phase controller until Xmas.
OK. That will be cool. Thanks again for your help. I’m going to see what I can do with the other LvGL classes that use the file system.
USB device is also working. But needs also some clean up.
1 Like
Cool. I’m going to play with your file system handling. I can read and write the SD card with mbed, but it looks like LittlevGL doesn’t play nicely with other file system handling according to the documentation. I have tight Flash and RAM constraints, so I’d really like to use the MBED file system handling by itself if possible rather than add an additional layer and more Flash used, but I need to be able to images in my project.
I’ll keep you posted.
I’m happy that it is working.
Have you checked the images tutorial? Mbed has the posix like file functions fopen(), fread(), fclose(), fseek() and more. The tiny wrapper just maps the lvgl functions to the posix functions, that is not much code and not consuming much flash. lvgl image handling is also optimized, the only needlehole is the ram. When you load images from SDC, you need ram for them. So for many images you need to do this on demand. Reading from SDC is pretty fast by using the SDIO interface.
I have ported lvgl with Mbed also to a DISCO_F769NI board, this has a lot more resources, like 2 MB flash and 512 kB Ram + additional 16 MByte SDRAM, plenty of space for graphics. This is working basically, but the driver is yet using the slow DrawPixel(), it can be much faster by using bit block transfer.
While porting to this board, I have noticed that my binary is larger than 600 kB, but code size was about 200k. The extra flash space needed came from LV_DEMO_WALLPAPER, which creates some initialized const array. For a display size of 800 x 472 it is consuming a lot…
OK. I’m glad to learn that there’s not much overhead. I’m still trying to figure out exactly how many I/O pins I need available and I’m afraid that the DISCO board may not have enough. The DISCO board only has one analog output, which concerns me.
The “Black” board has more analog outputs, which I need.
Hi Johannes,
I’m asking this here in case other people need/want to know your answer.
Have you updated your port of Littlevgl to work with LVGL 6.1?
thanks!
Hi,
not yet. Is there any major change? I think the driver should work als with 6.1. I wanted to skip the 6.x versions and start next with 7.0.
It doesn’t work - it crashes on the compile. Apparently some of the structures were changed. I’ll have to try to compile again with 6.1 and get the message to you.