michallenc commented on PR #18301: URL: https://github.com/apache/nuttx/pull/18301#issuecomment-3896488695
> 2 - Large display already requires a capable MCU by nature (SPI bandwidth, processing power, peripheral complexity). So, any one pairing a 320x480 display with a 20KB MCU (without external ram) would face bigger problems than the framebuffer size the system simply wouldn't work for any meaningful use case. That is good point, however the size of framebuffer of 320x480 takes about 300 kB of RAM - that's an extreme value even if we don't consider really small MCUs with let's say 20 kB RAM (you would probably even have problem running NuttX on it unless you only need shell and one or two peripherals). But a lot of MCUs used in embedded environment don't have mega bytes of RAM, but rather hundreds of kBs - SAM series has up to 384 kBs, the new PIC series from Microchip usually 512 kBs, lot of STM32 chips still have somewhat between 300-500 kBs (some exceptions with 1 MB) and the same goes for ESP32-C series if I remember correctly. I think these are all MCUs that are considered capable, are widely used yet still barely have enough RAM for 300 kBs large framebuffer. I am talking from first hand experience here, we use SAMv7 MCU in our company embedded products and we used to run LVGL with framebuffer API on ST7789. It was quite ok with 135x240 display, but we have one product with 320*240 display as well and that is where we hit the limit. Yes, the frambuffer fits into the memory, but consumes almost half of it (plus LVGL itself is pretty hungry RAM considered). And we switched to LCD chardev instead, that is also supported by LVGL for NuttX (`LV_USE_NUTTX_LCD`), so it was pretty straightforward. > 3 - The lcd_dev_s line-by-line approach on a small MCU with a large display is technically possible but practically useless, because you cannot render anything meaningful on 320x480 without a proper buffer. LVGL allows you to initialize it's own buffer (`LV_NUTTX_LCD_BUFFER_SIZE` and `LV_NUTTX_LCD_BUFFER_COUNT`),. We set it to cache about 80 or something lines and it gets you the smoother redraw. It's on 320x240 display, not 320x480, but it's pretty good on it. > I can for sure improve it, that's the idea in the end. Work as much as possible to support NuttX to grow, but not only grow (become better). I just need more time and knowledge :) Sure, I don't want to be mean or something like that, you did a really good job with the driver. And I understand it's tiring and time consuming to be stuck on a merge request that you might need to get merged because other development depends on it - I've been there as well. I suppose I don't mind merging it and changing it later, the only nasty thing is the function `st7796_fbinitialize` would probably be removed/changed and that would break board support package API. That still isn't so critical as normal API and it wouldn't affect many people since the driver is new now (likely it would affect just you) so I suppose I am fine with that. This merge request also shown the lack of proper documentation and that's on us. We should probably have driver interface section in the docs as well, because API itself doesn't tell you how to implement the controller itself. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
