Hi people, how are you?
I am starting a project using STM32F7g, running NuttX with Lvgl.
I tested the demo version of Lvgl for NuttX and compared to the demo version available at github (can’t post link here because I’m new member)
I noticed that the touch screen doesn’t respond well when running on NuttX but it works perfectly when it’s running without OS or running with FreeRTOS.
I made some videos to demonstrate this issue:
Lvgl & NuttX:
Lvgl & FreeRTOS:
Do you know where I can check in the code to see if the problem might be in the driver or widget?
The problem is very likely to be in the glue code between LittlevGL and the NuttX driver system. I don’t think this is specifically a LittlevGL issue since it works properly on other OSes/without an OS.
I agree with you embeddedt, but in the NuttX forum, they recommended talking directly to Gabor. I tried to talk to him by email but still got no answer, so I decided to write here in the forum
There are a couple of things I can think of in the meantime.
NuttX, as of today, is still using LittlevGL 5.3. That version was released over a year ago at this point. Perhaps there is an undiscovered bug that was never fixed. Are you using the same version of LittlevGL for all your comparisons?
It seems that the graphics are being drawn fast enough; the issue lies with the touchscreen response. I noticed in the NuttX video that you can’t even scroll the list at 0:21. I have the same board that you do so I might take a look at it if I get a chance.
It’s most probable that the NuttX implementation of the touchscreen driver is broken. One common issue that used to be a major stickler among new users (particularly since it was non-obvious) was that you have to still pass valid coordinates even on release. We automatically handle that in newer versions but I can’t remember whether or not 5.3 was one of them.
Just curious, which forum was that on? I follow the NuttX mailing lists periodically so I would probably have noticed a post relating to LittlevGL.
Exactly, the problem is the touch screen response time.
I’m new to NuttX and Lvgl, so any tips are helpful.
I made a public post on the NuttX group on Google, but in a private message a guy told me to talk directly to Gabor.
Not sure which versions of Lvgl are used, I can verify this information later.
Sorry for the late answer. I’m working a lot of new features and unfortunately, I don’t have time to answer questions every day. That’s why we have the forum, to get help from others too!
I’ve just answered your email and saw the topic here too. As I’ve mentioned in the email I suggest printing the events and the coordinates from the touchpad. It’s very strange that horizontal scroll (on the slider) is working but the vertical doesn’t. Hopefully, we will see something from the printed data.
Hi, a little off the record but could someone help me to run lvgldemo on stm32f746g-disco board;
I followed the procedure in LVGL NuttX RTOS Documentation, the buid and flash process went well however when I get connected to the board with picocom -b 115200 /dev/ttyACM0 and reset the board I get “arm_hardfault: PANIC!!! Hard fault:” on the terminal instead of “nsh>” prompt. But the same procedure works well with my nucleo-f103rb board.
In my experience, NuttX demos tend to break over time if there’s no one in the project actively using the board. One thing you can try is unplugging the board from power and then repowering it. Sometimes that has corrected startup problems for me in the past. Otherwise, you’d have to open an issue upstream and mention that NSH no longer starts.
Thanks for your response… Exactly. Today I’ve tested the procedure with my other board NucleoF401RE, the same procedure also works with the other board, I get nsh> prompt without any difficulty, I will open an issue regarding STM32f746g-disco board. BR.
EDIT:
Tested all other configurations such as :fb :nxdemo as well as :lvgl, only :nsh version starts the “nsh>” prompt on USART6 !
./tools/configure.sh stm32f746g-disco:nsh
works as expected, perhaps I am doing something wrong.
My guess then is that the configuration did break in the past, and someone updated the nsh config with a fix, but didn’t apply the fix to the other two configurations. It’s still an upstream bug nonetheless. If you’re comfortable with it, you could try searching the git log to see if there are any recent changes to the nsh config for this board.
