-
-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
LVGL8 isn't compat with LVGL demos #8
Comments
Thanks for the fixes :-) Sorry my code won't work with the latest "hosal" HAL in BL IoT SDK, because the SPI HAL has changed. I'm planning to redo the LVGL app with NuttX instead. NuttX has built-in support for LVGL, so it might be simpler: https://docs.lvgl.io/latest/en/html/get-started/nuttx.html I'll also work on SPI DMA for BL602 NuttX, since we'll be pushing lots of pixel data to the display. BTW: BL MCU SDK also supports LVGL: https://github.com/bouffalolab/bl_mcu_sdk/tree/master/components/lvgl |
TBC, the problem isn't the SPI Hal; it's LVGL.
It's frustrating how external forces can wreck a "hello world."
Since this almost IS my 'hello world' for Nuttx, perhaps I can provide you
with that code. I can model it based approximately on your end results. I'm
not sure if I have that exact display in stock, but we can at least iterate
toward the same example. 7735 and 7789 are pretty close...and if my read of
the doc is correct, we'd just be calling the existing driver in either case.
So if a Hello LVGL on Nuttx 7735 (or 9486) Hello LVGL on BL602 would be a
useful supplement/replacement, just hang on and I'll see what I can come up
with.
…On Sat, Mar 12, 2022 at 9:52 PM Lee Lup Yuen ***@***.***> wrote:
Thanks for the fixes :-) Sorry my code won't work with the latest "hosal"
HAL in BL IoT SDK, because the SPI HAL has changed.
I'm planning to redo the LVGL app with NuttX instead. NuttX has built-in
support for LVGL, so it might be simpler:
https://docs.lvgl.io/latest/en/html/get-started/nuttx.html
I'll also work on SPI DMA for BL602 NuttX, since we'll be pushing lots of
pixel data to the display.
BTW: BL MCU SDK also supports LVGL:
https://github.com/bouffalolab/bl_mcu_sdk/tree/master/components/lvgl
—
Reply to this email directly, view it on GitHub
<#8 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AC3VADYTUUI6ZJIB6NBWCSLU7VQ7TANCNFSM5QSXCDXQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Let's move to NuttX since LVGL works fine with ST7789 thanks :-) |
Hi, and thank you (again). I was about to drive a 7735 from BL602, and thought I'd give your demos a try.
Of course, the resolution is wrong and the chip is wrong, but I thought that would be a few easy #defines to tweak. Of course, it never is that easy.
In section 10.2 of there is a
git submodule add https://github.com/lvgl/lvgl
, which pulls in trunk of LVGL."And that's where the plot sours."
LVGL seems to hold cross-version compatibility is low regard, which is an unfortunate trait for a library. I scoured dozens and dozens of reports and complaints and the general advice for those with existing code is to basically not upgrade. In https://forum.lvgl.io/t/lvgl-v8-is-available-for-testing/4924/68 one of th maintainers says "one either has to rewrite their entire application, or stick with the older major release and patch it."
Your demos seem to be written for LVGL7.something (determining which 7.something isn't trivial) but the LVGL trunk is now 8.2 and they incompatible. I got as far as the changes below and then I ran into dozens of link errors.
Realizing I was drifting further and further from my goal ("easy sanity check of hardware") and needing to change the chip drivers, enter an untested land of LVGL, to ultimately do it all on another OS, and battling Git in wanting to take a submodule from a branch, I realized I was in the Sunk Cost Fallacy and needed to flee. Exactly none of this is your fault and some of it was expected. I merely post this as a cautionary tale (and Google fodder) to those expecting to build these projects.
I post this with absolutely no expectations of fixes. If anything, the smart money for your project is to just pin the module to whatever version of LVGL you were happily using.
Thank you for all the examples.
--- a/customer_app/sdk_app_st7789/sdk_app_st7789/lv_port_disp.c
+++ b/customer_app/sdk_app_st7789/sdk_app_st7789/lv_port_disp.c
@@ -75,9 +75,14 @@ void lv_port_disp_init(void)
/* LVGL requires a buffer where it draws the objects. The buffer's has to b
e greater than 1 display row
* We create ONE buffer with 10 rows. LVGL will draw the display's content
here and writes it to the display
* */
+#if 0
static lv_disp_buf_t disp_buf_1;
lv_disp_buf_init(&disp_buf_1, spi_tx_buf, NULL, LV_HOR_RES_MAX * BUFFER_ROW
S); /Initialize the display buffer/
+#else
static lv_disp_draw_buf_t disp_buf_1;
static lv_color_t buf_1[LV_HOR_RES_MAX * 10]; /A buffer for 10 rows/
lv_disp_draw_buf_init(&disp_buf_1, buf_1, NULL, LV_HOR_RES_MAX * 10); /Initialize the display buffer/
+#endif
/*-----------------------------------
@@ -96,7 +104,9 @@ void lv_port_disp_init(void)
disp_drv.flush_cb = disp_flush;
/Set a display buffer/
+#if 0
disp_drv.buffer = &disp_buf_1;
+#else
// do something
+#endif
#if LV_USE_GPU
/Optionally add functions to access the GPU. (Only in buffered mode, LV_VDB_SIZE != 0)/
index 7f61ba12..9f0a361e 100644
--- a/customer_app/sdk_app_st7789/sdk_app_st7789/lvgl.c
+++ b/customer_app/sdk_app_st7789/sdk_app_st7789/lvgl.c
@@ -54,11 +54,11 @@ int lvgl_create(void) {
lvgl_created = true;
printf("Create LVGL widgets...\r\n");
lv_obj_set_pos(btn, 10, 80); // Set its position
lv_obj_set_size(btn, 220, 80); // Set its size
lv_label_set_text(label, "BL602 LVGL"); // Set the label text
return 0;
}
@@ -88,4 +88,4 @@ int lvgl_render(void) {
// Call LVGL to render the display and flush our display driver
lv_task_handler();
return 0;
-}
\ No newline at end of file
+}
The text was updated successfully, but these errors were encountered: