Best practices for communicating with GUIX from other threads?

TimTTP 40 Reputation points
2023-05-25T09:51:18.3366667+00:00

Hello,

I'm getting up and running with ThreadX and GUIX and have built on the demo_guix_simple project. While the sample and tutorial projects show a lot of GUIX functionality, I couldn't find any examples which have additional threads running and performing arbitrary tasks - e.g collecting input from GPIO/ADC.

On my initial attempt to get this working, I tried running gx_widget_fill_color_set directly from a thread but received status code 0x11 - invalid caller . Eventually I figured out that I could use gx_system_event_send to send event messages to specific widgets and handle these events in the widget event function, from which I could make apply changes such as fill colour, text, etc.

However, this approach is limited to messages which fit in GX_EVENT struct. In a larger project, there can be messages of arbitrary size and format being passed around. I imagine a good approach for GUIX is to have a single thread which listens to a message queue, parses the message and applies GUIX changes as necessary. It is unclear to me how to set up such a thread.

Two approaches come to mind:

  • Use gx_system_timer_start to set up a polling system which checks the message queue
  • When messages are put in the gui message queue, also send a message to the event queue which triggers the event function to process the message queue

Do you have any documentation on best practice for this sort of thing?

A really good demo would involve a separate ThreadX thread waiting for a key/button press which triggers an indicator on the GUIX display.

Hope this makes sense!

Thanks for any help,

Tim

Azure RTOS
Azure RTOS
An Azure embedded development suite including a small but powerful operating system for resource-constrained devices.
331 questions
{count} votes

Accepted answer
  1. Ting Zhu 485 Reputation points Microsoft Employee
    2023-05-29T09:13:47.9266667+00:00

    The restriction is to ensure the timer thread is not blocked as certain GUIX APIs have the potential to block the thread while acquiring a mutex. This can also be problematic if the request originates from an interrupt, as it may lead to protection failure. We'll enhance the documentation to provide clearer guidelines and instructions.


1 additional answer

Sort by: Most helpful
  1. Ting Zhu 485 Reputation points Microsoft Employee
    2023-05-26T03:10:05.91+00:00

    You can explore the Embedded IDE samples available on GitHub at https://github.com/azure-rtos/samples. The IAR / MCUXpresso sample includes a GUIX sample, which features a touch thread that handles touch events.

    Here is a sample code showcasing multi-threading functionality. I hope this helps you. Additionally, we'll provide multi-thread tutorial projects in the future.

    TX_THREAD demo_thread;
    UCHAR     demo_thread_stack[4096];
    TX_THREAD input_thread;
    ULONG     input_thread_stack[1024];
    
    VOID  input_thread_entry(ULONG thread_input)
    {
        /* Check message queue and send event to guix. */
    }
    
    VOID  demo_thread_entry(ULONG thread_input)
    {
        /* Initialize and start GUIX.  */
    }
    
    VOID tx_application_define(void *first_unused_memory)
    {
        /* Create touch thread.  */
        tx_thread_create(&input_thread, "GUIX Touch Thread", input_thread_entry, 0,
            input_thread_stack, sizeof(input_thread_stack),
            GX_SYSTEM_THREAD_PRIORITY + 2, GX_SYSTEM_THREAD_PRIORITY + 2, TX_NO_TIME_SLICE, TX_AUTO_START);
    
        /* Create the main demo thread.  */
        tx_thread_create(&demo_thread, "GUIX Demo Thread", demo_thread_entry,
            0, demo_thread_stack, sizeof(demo_thread_stack),
            GX_SYSTEM_THREAD_PRIORITY + 1, GX_SYSTEM_THREAD_PRIORITY + 1, TX_NO_TIME_SLICE, TX_AUTO_START);
    }
    
    

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.