LAB - Mutex

Neste laboratório iremos trabalhar usar mutex no freertos para controlar o acesso ao LVGL entre múltiplas tasks.

Lab

Mutexes

O LVGL não é thread-safe by default, como indicado na página:

• https://docs.lvgl.io/master/porting/os.html

Isso significa que não podemos chamar uma função do LVGL enquanto a anterior não tiver terminado de executar, e caso implementemos o acesso ao LCD em várias partes do nosso programa corremos grande risco disso acontecer (lembrem que o RTOS interrompe uma tarefa para permitir que outra execute, e isso pode ser no meio da função por exemplo de mudar o valor do label).

A documentação do LVGL fala o seguinte:

If you need to use real tasks or threads, you need a mutex which should be invoked before the call of lv_timer_handler and released after it. Also, you have to use the same mutex in other tasks and threads around every LVGL (lv_...) related function call and code. This way you can use LVGL in a real multitasking environment. Just make use of a mutex to avoid the concurrent calling of LVGL functions.

Here is some pseudocode to illustrate the concept:

static mutex_t lvgl_mutex; // (1)

void lvgl_thread(void)
{
    while(1) {
        mutex_lock(&lvgl_mutex); // (2)
        lv_task_handler();
        mutex_unlock(&lvgl_mutex); // (3)
        thread_sleep(10); /* sleep for 10 ms */
    }
}

void other_thread(void)
{
    /* You must always hold the mutex while using LVGL APIs */
    mutex_lock(&lvgl_mutex); 
    lv_obj_t *img = lv_img_create(lv_scr_act());
    mutex_unlock(&lvgl_mutex);

    while(1) {
        mutex_lock(&lvgl_mutex);
        /* change to the next image */
        lv_img_set_src(img, next_image);
        mutex_unlock(&lvgl_mutex);
        thread_sleep(2000);
    }
}

1. Cria mutex, vamos ter que usar o do freertos
2. Indica que o recurso está em uso
3. Indica a liberacão do recurso

Prioridades e Mutex

Imaginem o cenário a seguir: Uma tarefa de baixa prioridade (L) requisita um mutex que está livre, no meio da execução uma tarefa de alta prioridade (H) é colocada para executar pelo escalonador e está tarefa necessita do mesmo mutex que a anterior. O que acontece? Pânico no sistema tudo trava? Não! O escalonador vai permitir que a de baixa execute e a de alta não vai executar pois está esperando o mutex. Isso chama inversão de prioridade.

Inversão de prioridade

Inversão de prioridade é uma "consequência" que acontece quando uma tarefa de alta prioridade está aguardando um recurso que não foi liberado por uma tarefa de menor prioridade, o RTOS vai manter a tarefa de baixa prioridade executando, impedindo a de alta de executar (o que não é muito desejado). O negócio começa a ficar mais complicado quando incluímos uma tarefa de média prioridade na jogada, que pode impedir a de baixa e a de alta de executar, travando o sistema:

• Acesse o link a seguir para entender mais a respeito: https://www.digikey.com.br/en/maker/projects/introduction-to-rtos-solution-to-part-11-priority-inversion/abf4b8f7cd4a4c70bece35678d178321

mutex no freeRtos

O mutex no FreeRTOS é como um semáforo binário, com uma única diferença: implementa herança prioritária (priority inheritance), que tenta minimizar os efeitos da inversão de prioridade. Este mecanismo faz com que a tarefa de baixa prioridade herde temporariamente a prioridade da tarefa de alta que necessita do recurso, ou seja, a tarefa de prioridade baixa, passa a ter alta prioridade até liberar o recurso.

Exemplo

A seguir um exemplo de mutex adaptado do livro do freertos. No caso a task1 necessita utilizar o printf e para isso requisita o mutex, após o uso a task libera o mutex permitindo que outra task utilize o printf.

SemaphoreHandle_t xMutex;


void task1() {

  while(1) {

    /* Attempt to take the mutex, blocking indefinitely to wait for the mutex if
    it is not available straight away. The call to xSemaphoreTake() will only
    return when the mutex has been successfully obtained, so there is no need
    to check the function return value. If any other delay period was used then
    the code must check that xSemaphoreTake() returns pdTRUE before accessing
    the shared resource (which in this case is standard out). As noted earlier
    in this book, indefinite time outs are not recommended for production code. */
    xSemaphoreTake( xMutex, portMAX_DELAY );

    /* The following line will only execute once the mutex has been successfully
    obtained. Standard out can be accessed freely now as only one task can
    have the mutex at any one time. */
    printf( "%s", "Ola 1" ); // (1)
    fflush( stdout );

    /* The mutex MUST be given back! */
    xSemaphoreGive( xMutex );

    vTaskDelay(100);
  }

}

void task2() {

  while(1) {

    xSemaphoreTake( xMutex, portMAX_DELAY );
    printf( "%s", "Ola 2" ); // (2)
    fflush( stdout );
    xSemaphoreGive( xMutex );

    vTaskDelay(100);
  }

}

void main() {

   xMutex = xSemaphoreCreateMutex();

   // ....
}

1. Região crítica de compartilhamento de recursos.
2. Região crítica de compartilhamento de recursos.

void printfMutex(char *s) {
  xSemaphoreTake( xMutex, portMAX_DELAY );
  printf( "%s", pcString );
  fflush( stdout );
  xSemaphoreGive( xMutex );
}

void task1() {
  while(1) {
    printfMutex("olá 1");
    vTaskDelay(100);
  }
}

void task2() {
  while(1) {
    printfMutex("olá 2");
    vTaskDelay(100);
  }
}

Programando

Agora vamos começar a programar, lembrem que a documentação do LVGL fala que: If you need to use real tasks or threads, you need a mutex which should be invoked before the call of lv_timer_handler and released after it..

APS 2

Este laboratório serve para ajudar vocês com a APS2, agora podem ter mais de uma task atualizando partes diferentes do LCD via LVGL, lembrem apenas de requisitar o mutex antes e liberar depois de terem usado.