The purpose of lcd_bus._pump_main_thread() method ?

[sam0910]

Greetings! I am always thank you for the lvgl micropython.

I am looking into the 'touch_calibration.py' and came across the lcd_bus._pump_main_thread() method, but I'm entirely no idea on its specific purpose and use case.

Please kindly help me understand.

lvgl_micropython/api_drivers/py_api_drivers/frozen/indev/touch_calibration/touch_calibrate.py

Line 94 in 9dbf21f

lcd_bus._pump_main_thread() # NOQA

[kdschlosser]

OK so in Micropython everything is based on some kind of a thread or task. On the ESP32 there are multiple cores and code is able to run parallel. The problem is that MicroPython actually only runs on one of those cores. Any application that gets written needs to have some kind of a loop that keeps the program from exiting before it is time to exit. MicroControllers are no different. The loop in MicroPython occurs in it's own code and that location is where it is checking for input from the REPL.

If you take a look at the code here...

https://github.com/lvgl-micropython/lvgl_micropython/blob/main/api_drivers/common_api_drivers/frozen/other/task_handler.py

you will see that the task handler uses a MicroPython Timer to handle calling lv_task_handler. The timers on the ESP32 are hardware timers and the callback for those timers gets called inside of a hardware interrupt. Because we are not able to allocate memory from inside of an interrupt context we are not able to make the call to lv_task_handler from inside of an ISR context and because LVGL is not thread safe we need to make sure that the call to lv_task_handler gets made in the same task/thread that the user is updating LVGL from. If you look at the task handler code you can see that inside the callback for the timer there is a call that is made that schedules a callback to get called from the main task/thread. You can see that here... How does that mechanism work? Well that main task/thread needs to check to see if there is anything that has been scheduled to run and if there is it needs to run it. If the main task/thread is busy doing other work it could be a while before that check will be made. MicroPython only checks those scheduled tasks in a very small number of places. and the only place where it will get checked often is when MicroPython is looking for input for the REPL.

That causes an issue... If the user has any looping code that keeps MicroPython from being able to check the REPL then guess what? The scheduled tasks never gets checked so lv_task_handler never gets called. In the touchscreen calibration there is looping code that stops MicroPython from checking scheduled tasks. That is the reason why you see that function being called. That function checks to see if there are any tasks that need to be run and it runs them if there are. It's a way to allow stalling the program to wait some something but still have the UI update properly.

[kdschlosser]

If you upload a main.py script to your MCU and in that script is is the following code...

while True:
    pass

and then you connect to the MCU's console you will find that you are never given a REPL prompt and you are not able to interact with the MCU at all from that console.

Now if you run the code below in the main.py script and you connect to the console and restart the MCU

import micropython


def callback(_):

    print('callback called')


micropython.schedule(callback, 0)

you will see the callback gets called.

but of you run this code

import micropython


def callback(_):

    print('callback called')


micropython.schedule(callback, 0)

while True:
    pass

the callback never gets called.

That's because the loop at the bottom stops MicroPython from being able to check the REPL for input which is where a check takes place for scheduled tasks.

[kdschlosser]

checks for tasks also take place when calls are made to time.sleep and time.sleep_ms and this is the reason why you cannot rely on those methods to sleep for the duration that is given. If you have a long running task that is scheduled which in this case lv_task_handler is run and that could take over 20 milliseconds to run if using an RGB display that has a high pixel count. then calling time.sleep_ms(5) is not going to return for 20 milliseconds and not 5 milliseconds.

It's quite a complicated issue to deal with. What really sucks is that when using the sleep functions is a spinning wheels occurs during that time. MicroPython just loops checking to see if the amount of time has expired while checking the scheduled tasks. Any back end tasks that might be scheduled to run using FreeRTOS do not get run while the spinning wheels is occurring. This is the reason why I added a user C module that can be added to the build that exposes the FreeRTOS API to Python. This provides the ability for very advanced management of the tasks that are running. It also allows a user to run Python code on the second core if they wanted to. That module is not finalized and is still a work in progress.

[sam0910]

Now I am clearly understanding the purpose of function.
I found most of 'lcd_bus._pump_main_thread()' is in while or for loop.
I've tested a little example.
This approach outperforms the asyncio coroutine task_handler.

Great thanks!!

[kdschlosser]

asynchio is a slow and bloated thing to use. You are better off using threads. asynchio was intended only to be used with IO and nothing else. and that IO really needs to be some form of data that is being sent or received and not to perform things like reading from a GPIO for a state check.

I never understood why people jumped to using it when Python first released it. In MicroPython it is 100% python code which is why it's going to run slower. Then you also have the extra memory consumption when using it.

In terms of performance with LVGL the best thing to do is to create a thread where you code runs and let the main thread drop to the repl and not use the task handler that is built into this binding.

[asherevan]

But if there is only two cores, and LVGL is running on one and the REPL is running on the other, where will it run?

[kdschlosser]

the REPL and LVGL are both running on the same core. If you are using an RGB display I have offloaded some work over to the second core and I plan on doing the same for the rest of the display drivers.

Each core is able to have more than one "thread" running on it. There is a system called FreeRTOS that manages the threads (tasks) that are run. It handles the context switching between the tasks.