'import asyncio fails' on Unix Port, plus strange Unix task_handler.py Timer behaviour

[StephenDone]

I have built the unix port VARIANT=standard and am running it under WSL2 on windows.
I have the test app running, as listed in the readme.md.

However,

>>> import asyncio
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ImportError: no module named 'asyncio'

>>> help('modules')
__main__          encoder_framework lvgl              sdl_pointer
_asyncio          errno             machine           select
_indev_base       ffi               math              socket
_thread           framebuf          micropython       ssl
argparse          fs_driver         mip/__init__      struct
array             gc                mip/__main__      sys
binascii          hashlib           os                task_handler
btree             heapq             platform          termios
builtins          i2c               pointer_framework time
button_framework  io                random            tls
cmath             io_expander_framework               re                touch_cal_data
collections       json              requests/__init__ touch_calibrate
cryptolib         keypad_framework  rgb_display_framework               uctypes
deflate           lcd_bus           sdl_display       vfs
display_driver_framework            lcd_utils         sdl_keyboard      websocket
Plus any modules on the filesystem

Copying lvgl_micropython/lib/micropython/extmod/asyncio/* to ~/.micropython/lib/asyncio looks like it might work. The import error goes away.

lvgl_micropython/lib/micropython/ports/unix/variants/standard/manifest.py looks as follows...

include("$(PORT_DIR)/variants/manifest.py")

include("$(MPY_DIR)/extmod/asyncio")

and lvgl_micropython/lib/micropython/extmod/asyncio/manifest.py as follows...

# This list of package files doesn't include task.py because that's provided
# by the C module.
package(
    "asyncio",
    (
        "__init__.py",
        "core.py",
        "event.py",
        "funcs.py",
        "lock.py",
        "stream.py",
    ),
    base_path="..",
    opt=3,
)

# Backwards-compatible uasyncio module.
module("uasyncio.py", opt=3)

I am just guessing, as this is not anything I've looked at before, but maybe the asyncio .py files are not being frozen into the build.

[StephenDone]

I'm not sure if this is related, but I am seeing some strange behaviour with asyncio on the unix port...

Obviously you need to setup the lvgl gui, but then your device needs to do other things, hence use of asyncio.

When running my code on an ESP32-S3, I can setup a test lvgl gui, then effectively wait forever using asyncio e.g.

await asyncio.Event().wait()

...and the gui continues to function.

But, if I try this on the unix port, I just get a blank window. Only AFTER the while loop exits do I get a functioning GUI.

If after setting up the gui, I instead try...

    while True:
        print('.')
        await asyncio.sleep(1)

...I get a super sluggish GUI that takes seconds to respond to anything.

Setting the delay to 100ms, the GUI is extremely sluggish. Setting to 50ms and it seems just fine.

When is the lvgl code running? Is it not running during the sleeps? It would appear that it is running anywhere but in the sleeps.

Perhaps I am misunderstanding how this is meant to work. But I am seeing a big difference in behaviour between my embedded port and my unix port. I have seen many examples of setting up the GUI, but I haven't yet found a sample that shows how to create a GUI and then do something with it i.e. an example of the correct way to multitask, so the GUI gets refreshed and the other tasks get to run too.

Any ideas?

from micropython import const  # NOQA
import lcd_bus  # NOQA
import asyncio

_WIDTH = const(480)
_HEIGHT = const(320)

async def main():
    bus = lcd_bus.SDLBus(flags=0)

    buf1 = bus.allocate_framebuffer(_WIDTH * _HEIGHT * 3, 0)

    import lvgl as lv  # NOQA
    import sdl_display  # NOQA

    display = sdl_display.SDLDisplay(
        data_bus=bus,
        display_width=_WIDTH,
        display_height=_HEIGHT,
        frame_buffer1=buf1,
        color_space=lv.COLOR_FORMAT.RGB888
    )
    display.init()

    import sdl_pointer
    # import sdl_keyboard
    import task_handler

    mouse = sdl_pointer.SDLPointer()
    # keyboard = sdl_keyboard.SDLKeyboard()

    # the duration needs to be set to 5 to have a good response from the mouse.
    # There is a thread that runs that facilitates double buffering. 
    th = task_handler.TaskHandler(duration=5)

    scrn = lv.screen_active()
    scrn.set_style_bg_color(lv.color_hex(0x000000), 0)

    slider = lv.slider(scrn)
    slider.set_size(300, 25)
    slider.center()

    while True:
        print('.')
        await asyncio.sleep(1)

asyncio.run(main())

[StephenDone]

@kdschlosser, After sleeping on it, I created a simple test script to see if I could understand what is happening.
So I am just running a Timer and an asyncio sleep loop concurrently.
Results below script.

Hopefully from this, you can tell me if I've done something really stupid, or whether I need to be submitting a bug report for micropython. But I thought I should check with you first, as I don't know if there is something specific about the lvgl_micropython build that could potentially be causing this. I did notice the difference in sys.implementation._thread values, so thought I would highlight that.

import sys
from machine import Timer
import asyncio
import time

timer_id = 0
if sys.platform in ('pyboard', 'rp2'):
    timer_id = -1

duration = 100

last_tick_t = time.ticks_ms()

def timer_cb(timer):
    global last_tick_t
    current_tick_t = time.ticks_ms()
    ticks_diff_t = time.ticks_diff(current_tick_t, last_tick_t)
    last_tick_t = current_tick_t
    print(f'timer_cb: {ticks_diff_t}ms')

async def main():
    print(sys.implementation)

    timer = Timer(timer_id)
    timer.init(
        mode=Timer.PERIODIC,
        period=duration,
        callback=timer_cb
    )
    try:

        last_tick_a = time.ticks_ms()
        while True:
            await asyncio.sleep_ms(1000)
            current_tick_a = time.ticks_ms()
            ticks_diff_a = time.ticks_diff(current_tick_a, last_tick_a)
            last_tick_a = current_tick_a
            print(f'async sleep: {ticks_diff_a}ms')

    finally:
        print('timer.deinit()')
        timer.deinit()

asyncio.run(main())

Here is what it looks like on my ESP32-S3 device, and as I would expect...

>>> 
(name='micropython', version=(1, 27, 0, ''), _machine='Generic ESP32S3 module with Octal-SPIRAM with ESP32S3', _mpy=11014, _build='ESP32_GENERIC_S3-SPIRAM_OCT', _thread='GIL')
timer_cb: 112ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
async sleep: 1010ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
async sleep: 1010ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
...

And here is the result from the Unix port...

>>> import timer_test
(name='micropython', version=(1, 27, 0, ''), _machine='linux [GCC 13.3.0] version', _mpy=2822, _build='standard', _thread='unsafe')
timer_cb: 1016ms
timer_cb: 0ms
timer_cb: 0ms
timer_cb: 0ms
timer_cb: 0ms
timer_cb: 0ms
async sleep: 1016ms
timer_cb: 0ms
timer_cb: 0ms
timer_cb: 1002ms
timer_cb: 0ms
timer_cb: 0ms
timer_cb: 0ms
timer_cb: 0ms
timer_cb: 0ms
async sleep: 1002ms
timer_cb: 0ms
timer_cb: 0ms
timer_cb: 0ms
timer_cb: 1000ms
timer_cb: 1ms
timer_cb: 0ms
timer_cb: 0ms
timer_cb: 0ms
timer_cb: 0ms
async sleep: 1001ms
timer_cb: 0ms
timer_cb: 0ms

No wonder the lvgl gui stutters on Unix when I attempt to use asyncio.

By the way, I tried replacing the asyncio sleep loop with a simple time.sleep(10)...

async def main():
    print(sys.implementation)

    timer = Timer(timer_id)
    timer.init(
        mode=Timer.PERIODIC,
        period=duration,
        callback=timer_cb
    )
    # try:

    #     last_tick_a = time.ticks_ms()
    #     while True:
    #         await asyncio.sleep_ms(1000)
    #         current_tick_a = time.ticks_ms()
    #         ticks_diff_a = time.ticks_diff(current_tick_a, last_tick_a)
    #         last_tick_a = current_tick_a
    #         print(f'async sleep: {ticks_diff_a}ms')

    # finally:
    #     print('timer.deinit()')
    #     timer.deinit()

    time.sleep(10)

ESP32-S3...

(name='micropython', version=(1, 27, 0, ''), _machine='Generic ESP32S3 module with Octal-SPIRAM with ESP32S3', _mpy=11014, _build='ESP32_GENERIC_S3-SPIRAM_OCT', _thread='GIL')
timer_cb: 113ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms
timer_cb: 100ms

... for 10 seconds, as expected

Unix

>>> import timer_test
(name='micropython', version=(1, 27, 0, ''), _machine='linux [GCC 13.3.0] version', _mpy=2822, _build='standard', _thread='unsafe')

<10 seconds of nothing happening>

timer_cb: 10002ms
>>> timer_cb: 0ms
timer_cb: 1ms
timer_cb: 1ms
timer_cb: 2ms
timer_cb: 1ms
timer_cb: 1ms

So this seems to rule out asyncio as a possible culprit for the Timer issue.

[StephenDone]

It could well be this actually...

micropython/micropython#18810

I seem to attract bugs like a magnet! :-)

[kdschlosser]

You shouldn't be using asynchio for LVGL. the data transfer between the display and the MCU is synchronous and asynchronous. asynchio is as the name implies it's for asynchronous data transfers.

You are using something you shouldn't be using.

[kdschlosser]

the unix porr in MicroPython doesn't have timers so I had to roll my own and that might be why you are seeing some oddities in how it is working when using asynchio. But then again you aren't supposed to be using asynchio.

If you are going to use asynchio then you should not be using task_handler.TaskHandler You need to manage calling lv.tick_inc and lv.task_handler when they need to be called.

[kdschlosser]

also making comments in the micropython repository and/or opening issues is not going to help at all. This is a highly modified version of micropython and things you are having issues with they are not going to know anything about.

[StephenDone]

Thanks for replying.
So if I have say Bluetooth code that must execute at regular intervals, what is the recommended way to do this with lvgl_micropython?

All my code is currently written using asyncio, but I could change that if it's the wrong way to do it.

[kdschlosser]

LONG READ AHEAD

You can use threads and use locks to control the context switching. Or you can use what is already in place and not reinvent the wheel.

The way MicroPython is written you cannot and do not want to block the main thread. It really needs to drop back to the repl. This is where MicroPython will check for scheduled tasks that need to be run. While the ESP32S3 is dual core MicroPython only runs on one of those cores. You do not have the ability to access the second core from inside of MicroPython. MicroPython also has the same limitation as C Python with there being a GIL and that GIL (Global Interpreter Lock) is what keeps code from running in parallel so even if you could access the second core the GIL would prevent parallel code execution.

When you use MicroPython's task scheduler the functions that gets registered to the scheduler get called in the main thread context. That means at some point during the execution of the code that is running in the main thread the scheduler must be checked for pending tasks and those tasks must be executed. This is something that can only be done in the main thread context. So when does MicroPython do this? It does it in several places but the most common is when it is checking for input from the repl, and when time.sleep gets called. It does occur in other places like when checking to see if any data has been received from something like bluetooth.

For ease of use I wrote in some convenience code that handles incrementing the tick count in LVGL and takes care of calling lv.task_handler which is what updates the display. You are not forced to use these things and you can do them yourself but care needs to be given when accessing different pieces of LVGL especially if you are using threads so you do not access the same objects at the same time from different threads otherwise you can have data corruption.

Due to the GIL an it limiting code execution so it is unable to be run in parallel I tell people to use the "K.I.S.S." (Keep It Stupid Simple) method when writing their code... Use the mechanics that are available to you and do not try and reinvent the wheel and the outcome will be better than you expect. Most things in MicroPython that require high precision execution times is usually offloaded to the second core and there are callbacks that can be registered to know when it has finished. or a blocking call is made. The ESP32 also will handle a lot of this kind of stuff out of view of the user and they provide buffers to access any data that has been collected. This makes it easy to do polling loops because the polling loop doesn't need to be completed at high speed in order to make sure that things like dropped packets do not occur. The code that actually does the polling to collect the data gets run on the second core outside of the GIL and the collected data gets paced into a buffer. This is how the bluetooth driver works.

So what is available that can be used that will not block the main thread and can be used to check pin states or collect data from a bluetooth buffer? Well when working with GUI applications there is typically some form of either user interaction that would indicate that something needs to be checked or the result of doing a check would either create or update some kind of a GUI element so the user is able to see the data that has been received. The end result being that some for of involvement in the GUI is taking place. The best way to integrate it would be to integrate those checks into the GUI system...

LVGL provides a way to do this and that way is by using lv.Timer. by using the LVGL timers you are able to inject your code into LVGL's task handler so it will get called at the interval that you provided when creating the timer. It is not going to be like a hardware timer that executes where the timing is going to be exact but that is not something that is going to be needed because the precise timing is already handled by the driver for something like bluetooth. All you need to do is to collect any data that may be sitting in a buffer or to send data.

The convenience code that I wrote in the task_handler.TaskHandler task is what keeps the program running in an endless loop. There is no need for you to have any kind of looping code in order for your GUI to run. all you need to do is register the lv.Timers to have your code gets executed when you need it to be executed and to use event callback functions for the GUI elements so that work is able to be done when user interaction occurs.

How the task_handler.TaskHandler class works.....

This class when started creates a hardware timer with the ESP32 that will get triggered every n milliseconds. The purpose of this hardware timer is to increment the tick count (internal clock) in LVGL and to schedule a task with the scheduler in MicroPython so it can update the display by calling lvgl's task handler. The reason why the task handler has to be scheduled is due to not being able to allocate memory inside of an interrupt context which is the context that is used when a hardware timer calls the callback function. To work around that limitation we need to interrupt context to exit an the main loop to continue running again but we need to update LVGL in the main loop runs and that is done via the scheduler built into MicroPython. This is the reason why you do not want to have any looping code is because it will either stall or completely stop the main thread/task from being able to check and run anything that is registered with the scheduler. The location in MicroPython's code that checks for scheduled tasks the most often is going to be where it loops checking for input from the REPL. Remember KISS? Best thing is to let it do what it was written to do.

By default the updating of the screen is going to occur every 33 milliseconds this is also the interval in which the hardware timer is set for. You can change this without issue by specifying the hardware timer duration when you construct the task_handler.TaskHandler instance. Passing a number that is lower than 33 does not mean that the display is going to update faster than the 33 milliseconds it only controls how often the hardware timer is going to execute to update the internal clock in LVGL and how often lv.task_handler is going to get called. This is useful if you have created lv.Timers that have an interval that is less than 33 milliseconds. it will allow those timers to get executed as close as possible to the duration that has been specified.

You can also use the micropython scheduler to inject code that you want to run in a loop. Simply write a function and add it is the micropython scheduler to be executed You will need to add it to the scheduler each time the function runs so it will get run each time MicroPython loops back around to checking the scheduler... This is going to actually be a pretty fast loop and the only place that a slow down is going to occur is when the task to update the display runs and the amount of time it takes for that to execute is going to depend on how much updating of the display is happening.

[kdschlosser]

There are advanced ways to control the flow of an application if you really need to do that. It's quite complicated and you would be responsible for making sure the display gets updated and you will be responsible to keeping track of how much time as passed and updating the clock in LVGL. You will be responsible for making sure that any tasks in LVGL get run when they should be. It adds a lot of additional code to a users application to do this and if not done properly will cause all kinds of glitches and crashes. Put it to you this way it needs to be done 100% perfect in order for it to work properly...

Sometimes a user may not want the REPL to be available.. This could be because whatever it is they built is being sold and they don't want to provide users an easy access to the device. In this situation you would not want a user to be able to plug in a USB and get a ">>>" prompt where they have the ability to enter code that would get run. But you do want to retain the ability to access MicroPython if needs be... The easiest way to go about this is by adding a never ending loop that stops the application from dropping down into the code in MicroPython that looks for input for the REPL. You would add code like this...

while 1:
    pass

at the bottom of your main.py file at the module level.

Well it's not that simple because by doing that you just now stopped the MicroPython scheduler from running. and this is going to stop everything in your program from running.

Yes I even thought about this as a use case..

I added a way to be able to pump the scheduler to run any scheduled task that may be pending.

import lcd_bus

while 1:
    lcd_bus._pump_main_thread()

You are the software writer will retain the ability to access the REPL if needed but block random user access to the REPL by doing this. MicroPython is written in a manner where serial/CDC input is collected in an ISR. only very specific bits of that input gets processed at that step. The bits that are processed is looking for very specific non ascii control code. Once of them being he ability to stop the execution of the currently running program. That is done by sending 2 bytes to the CDC/serial port. the 2 bytes that need to be sent are bytearray([0x03, 0x03]). Once that is done the program will terminate and a REPL prompt will appear allowing access.

[kdschlosser]

I do want to note that the lcd_bus._pump_main_thread function can only be called from the context of the main thread/task. calling it from any other thread/task will cause undefined behavior and/or the application crashing.

[StephenDone]

Hi @kdschlosser,

Thanks for the LONG WRITE BEFORE! :-)
Seriously though, I appreciate you taking the time to write such a lengthy and detailed reply.

First off, I am not trying to rewrite anything and would much prefer to use as-is if working for me. I only go nosing around the code when things go awry for me. Believe me, I am trying to stay on the 'straight and narrow' in order to get the most of my minimal free time for coding.

My test script was purely to watch the interaction between a Unix Timer() and various micropython code loops. It is not indicative of any code that I am trying to directly incorporate into my application - perhaps I should have been clearer about that, sorry. I wrote it to prove to myself (then to show you) that the behaviour of the Unix Timer is not the same as for embedded targets. Regardless of what code is executing, the Timer() on embedded targets produces a regular 100ms event. However the Unix Timer() produces batches of events with no delay in between, then a huge time gap, then another batch of events. This is why (only when using the Unix port) the UI gets really choppy. In all my application testing (Pi Pico 2W and ESP32-S3), the combination of machine.Timer() for lvgl lv_handler() and lv_ticks() on the second core, and asyncio for application code on the first core has worked perfectly. Only for the Unix port does it have issues, which is why from my perspective it is a bug with that port.

I saw mention in one of your readmes that you were using the second core for lvgl to improve performance and that sounds like a great use of resources. I am not using threads and don't intend to. I have no desire to mess with the sensible 'partitioning' you have put in place.

The way MicroPython is written you cannot and do not want to block the main thread. It really needs to drop back to the repl.

That's interesting. I've been doing quite a lot of work with and learning about asyncio over the past few months. I am by no means an expert, but I'm not sure I have seen any asyncio code that drops back to the repl, except for testing. As soon as you drop through the usual `asyncio.run(main)', all the coroutines stop being executed and your app is over. I sanity checked my response here: https://share.google/aimode/LiyjN6KGo22GMd0Cy

It has been a few weeks since I worked on my bluetooth code (and my memory is terrible these days!). On re-examining what I had written, I am using aioble (AsyncIO Bluetooth Low Energy), which is the defacto high level bluetooth library for micropython. So for my project at least, I will have to stay with asyncio. I don't have the coffee bean budget to attempt rewriting using the low level bluetooth library, though I am sure it would improve my depth of knowledge (and bags under my eyes) :-)

Btw, the example project using your bindings that you have listed at the bottom of your project readme.md is using asyncio - https://github.com/fabse-hack/temp_humidity_micropython_lvgl/blob/main/main.py
It never drops back to the repl.

I guess which scenario you consider to be 'the tail wagging the dog' depends on your perspective! I.e. are you a micropython coder who is trying to add an lvgl UI, or an lvgl UI designer trying to add micropython code.

So only for my Unix target, I have created my own task handler...

...
        self.task_handler_task = asyncio.create_task(self.task_handler_job(33))
...

    async def task_handler_job(self, ms):
        last_tick = time.ticks_ms()
        while True:
            current_tick = time.ticks_ms()
            ticks_diff = time.ticks_diff(current_tick, last_tick)
            last_tick = current_tick

            lv.tick_inc(ticks_diff)
            lv.task_handler()

            await asyncio.sleep_ms(ms)

...but I would happily do away with my code tweak if a future update makes the Unix Timer() behave more in line with machine.Timer() for embedded devices. I think that what I have done means that both my lvgl redraws and micropython application code will both be running on one core, which is a shame, given all the work you've done to make use of both cores.

Thanks again for all your explanations.
Steve

[kdschlosser]

ok when using the unix port if you pass a filename to the binary it's a run once and done and the REPL is never seen. However if you launch the binary without a file argument and then import your source file it will drop to a REPL prompt once module has been imported and if there is no looping code in it.

The purpose to asynchio is to handle asynchronous IO. This is for incoming data not outgoing because if it's outgoing to know when something is being sent which means it is synchronous. So it's really for incoming IO...

This is the code that micropython uses for sleeping...

static mp_obj_t mp_time_sleep(mp_obj_t arg) {

    #if MICROPY_PY_BUILTINS_FLOAT
    
        struct timeval tv;
        mp_float_t val = mp_obj_get_float(arg);
        mp_float_t ipart;
        tv.tv_usec = (time_t)MICROPY_FLOAT_C_FUN(round)(MICROPY_FLOAT_C_FUN(modf)(val, &ipart) * MICROPY_FLOAT_CONST(1000000.));
        tv.tv_sec = (suseconds_t)ipart;
        int res;
        while (1) {
            MP_THREAD_GIL_EXIT();
            res = sleep_select(0, NULL, NULL, NULL, &tv);
            MP_THREAD_GIL_ENTER();
            #if MICROPY_SELECT_REMAINING_TIME
                // TODO: This assumes Linux behavior of modifying tv to the remaining
                // time.
                if (res != -1 || errno != EINTR) {
                    break;
                }
                mp_handle_pending(true);
                // printf("select: EINTR: %ld:%ld\n", tv.tv_sec, tv.tv_usec);
            #else
                break;
            #endif
        }
        RAISE_ERRNO(res, errno);
        
    #else
    
        int seconds = mp_obj_get_int(arg);
        for (;;) {
            MP_THREAD_GIL_EXIT();
            seconds = sleep(seconds);
            MP_THREAD_GIL_ENTER();
            if (seconds == 0) {
                break;
            }
            mp_handle_pending(true);
        }
    #endif
    return mp_const_none;
}

as you can see the only way that the scheduler gets pumped when using sleep is when 3 conditions are actually met. Te first one being MICROPY_PY_BUILTINS_FLOAT must be set to1. the second one is MICROPY_SELECT_REMAINING_TIME must also be set to 1 and the last one is this statement if (res != -1 || errno != EINTR) must evaluate to false

There is also a "TODO" in here that makes me think that this is an unfinished but of code so it doesn't actually work correctly. The other way to get it to work is to set MICROPY_PY_BUILTINS_FLOAT to a 0 but if that is done then the call ends up blocking until the sleep is finished and only after the duration of time has past does the scheduler get pumped. So while the sleep is happening the scheduler never gets called.

In the unix port the scheduler never gets pumped at the REPL.

See this code..

static int do_repl(void) {
    #if MICROPY_USE_READLINE == 1

    // use MicroPython supplied readline-based REPL

    int ret = 0;
    for (;;) {
        if (pyexec_mode_kind == PYEXEC_MODE_RAW_REPL) {
            if ((ret = pyexec_raw_repl()) != 0) {
                break;
            }
        } else {
            if ((ret = pyexec_friendly_repl()) != 0) {
                break;
            }
        }
    }
    return ret;

    #else

    // use simple readline

    mp_hal_stdout_tx_str(MICROPY_BANNER_NAME_AND_VERSION);
    mp_hal_stdout_tx_str("; " MICROPY_BANNER_MACHINE);
    mp_hal_stdout_tx_str("\nUse Ctrl-D to exit, Ctrl-E for paste mode\n");

    for (;;) {
        char *line = prompt((char *)mp_repl_get_ps1());
        if (line == NULL) {
            // EOF
            return 0;
        }
        while (mp_repl_continue_with_input(line)) {
            char *line2 = prompt((char *)mp_repl_get_ps2());
            if (line2 == NULL) {
                break;
            }
            char *line3 = strjoin(line, '\n', line2);
            free(line);
            free(line2);
            line = line3;
        }

        int ret = execute_from_lexer(LEX_SRC_STR, line, MP_PARSE_SINGLE_INPUT, true);
        free(line);
        if (ret & FORCED_EXIT) {
            return ret;
        }
    }

    #endif
}

There is no timer that is available in MicroPython for the unix port. I added one to it and it might not be the best solution. I know it does work running on Ubuntu and on MacOS I have not tested it to see if it works on any other OS.

You can look at the code for the timer I wrote in micropy_updates/unix. The timer runs in it's own thread and as such it is not going to be accurate. It is close enough to do the job that is needed to keep the display updating properly.

[StephenDone]

Hi @kdschlosser,
Thanks for the extra explanations.
I will definitely take a look at the timer that you wrote, to get a better picture of how things fit together.

The micropython guys are just in the process of updating time.sleep for what sounds like the problem you are describing... micropython/micropython#18810.

As you say, your Unix timer implementation does work fine if the code drops back to the repl after setting up lvgl. But I don't think it works well when the code does not drop back to the repl, whether that is with time.sleep()s or asyncio - the events get 'bunched up'. I think that's a concise way to describe my testing results.

I think it is probably beyond my current lvgl/micropython experience level to think I am going to be able to offer any code revisions of your timer code! With my current level of experience, the best I can do is describe the issue and how to repeat it.

Before I move on to my next task, I will enable the FPS counter in the build and see how much performance I am losing by using asyncio to trigger lv_handler, thereby limiting all the code to a single core.

Thanks again for your insights and explanations.

[kdschlosser]

It would be nice if they add timers to the unix port. You might want to ask them to do that as that would make life a whole lot easier. Remind them it also needs to work for MacOS as well.

You might be able to get somewhere with that. MacOS is the biggest hurdle because it doesn't use the c stdlib. it takes bits and pieces from it and timers are one of the things it doesn't use from it. MacOS has a completely different way to go about the timers and I was not able to get it to work using their timers. I had thought about using SDL to handle the timers and then I found out about how inaccurate it was. So I came up with the thread idea and I know it's not perfect but it was the best I was able to hobble together and have it with the best accuracy for this projects use case.

There is a lot of code replacement that I had to do in MicroPython in order to get my project to work properly. I had to change how the SPI drivers work so the folks that have displays that use a shared bus for the SDCard and display IC would be able to use it. I had to add in support for dual and quad SPI.

The way MicroPython was written if you have to manage the state of the CS wire yourself an if you\ have 2 SPI devices on a bus and those devices are operating at different speeds you have to tear down and recreate the bus each time you switch devices that are sending and receiving. That adds a very large amount of additional overhead that doesn't need to exist. Another thing is MicroPython doesn't support using DMA memory for things like transmitting. data. There is no way for a user to be able to allocate a buffer in DMA memory.