A primeira parte deste artigo foi responsável por introduzir o sistema operacional de tempo-real FreeRTOS, caminhando um pouco pela sua estrutura de arquivos. Agora, nesta segunda parte, é abordada de forma prática os passos necessários para a migração da aplicação bare-metal para a sua versão baseada nesse sistema operacional. E agora, como começo a minha aplicação?

Pode-se utilizar (aliás, é aconselhado!) um dos projetos de demonstração oferecidos na pasta FreeRTOS/Demo, separados por arquitetura e compilador, como mostrado abaixo. Inicie usando uma aplicação de demonstração para garantir a sua correta compilação e, de forma incremental, substitua os arquivos do projeto exemplo por arquivos da aplicação final.

Para começar a trabalhar minimamente com o FreeRTOS, vamos entender como deve ser feita a migração da aplicação bare-metal que pisca leds no kit STM32F4Discovery, usada nos posts anteriores da série, para a sua versão baseada em RTOS. Esse processo já foi realizado e o novo projeto foi disponibilizado no GitHub. Execute o seguinte comando para obtê-lo:

Obs: Lembre-se que no primeiro post da série GNU ARM Cross-toolchain foi apresentada a organização do ambiente de desenvolvimento para os nossos projetos. Vale a pena seguir seus passos!

O conteúdo da pasta stm32f4-discovery-freertos/hello_world, que contém os arquivos do projeto, é exibido abaixo:

Foram utilizados os mesmos arquivos da versão bare-metal do projeto. No entanto alguns pontos precisaram ser modificados, como é detalhado a seguir.

Anatomia de um projeto com FreeRTOS

Uma aplicação baseada no FreeRTOS é iniciada da mesma forma que uma aplicação bare-metal. Desde o reset até a chamada à função main(), o processo é o mesmo. Deve ser inicializado o ambiente de runtime da biblioteca C, configurada a pilha do sistema e inicializado o hardware utilizado. Em seguida deve ser criada pelo menos uma tarefa e ser chamada a função vTaskStartScheduler(), que entrega o controle da aplicação ao sistema operacional. Em seguida as tarefas são executadas de acordo com as suas prioridades.

Para que essa dinâmica seja possível na aplicação de pisca-leds, são necessárias as seguintes modificações:

• adicionar os arquivos-fonte do FreeRTOS ao projeto;
• informar os diretórios dos arquivos de cabeçalho do FreeRTOS;
• adicionar o arquivo FreeRTOSConfig.h ao projeto;
• configurar a tabela de vetores de exceções/interrupções;
• criar uma tarefa e inicializar o kernel.

Arquivos-fonte

O FreeRTOS, como explicado anteriormente, é composto por alguns arquivos que implementam o kernel e os serviços oferecidos pelo sistema operacional. Esses arquivos, listados abaixo, devem ser adicionados ao projeto, de forma que sejam compilados juntamente com todos os arquivos.

• FreeRTOS/Source/tasks.c;
• FreeRTOS/Source/queue.c;
• FreeRTOS/Source/list.c;
• FreeRTOS/Source/portable/GCC/ARM_CM4F/port.c;
• FreeRTOS/Source/portable/MemMang/heap_2.c.

Caso seja necessário adicionar algum serviço do FreeRTOS à aplicação, seguem as opções oferecidas pelo sistema operacional e seus respectivos arquivos que devem ser adicionados ao projeto:

• Software timer: FreeRTOS/Source/timers.c;
• Event groups: FreeRTOS/Source/event_groups.c;
• Co-routines: FreeRTOS/Source/croutine.c.

Arquivos de cabeçalho

Alguns diretórios devem ser incluídos no caminho de procura de arquivos de cabeçalho do projeto. Dentre esses, pode-se citar:

• FreeRTOS/Source/include;
• FreeRTOS/Source/portable/GCC/ARM_CM4F.

Configuração do FreeRTOS – FreeRTOSConfig.h

Existe um arquivo de configuração do sistema operacional, chamado FreeRTOSConfig.h, que ajusta alguns parâmetros do kernel do FreeRTOS e habilita/desabilita alguns serviços, de acordo com a necessidade da aplicação que está sendo desenvolvida. É possível uma aplicação, por exemplo, fazer uso de event groups e possuir um tamanho de heap igual a 0x4000 bytes, ao passo que em outro projeto sejam utilizadas co-routines e faça uso de um heap de 0x2000 bytes. Também, como exemplo, nesse mesmo arquivo é habilitada ou desabilitada a preempção do scheduler. Como se trata de um arquivo específico da aplicação, ele deve estar localizado fora dos diretórios do sistema operacional. Sendo assim, tal caminho escolhido também deve ser adicionado ao projeto.

Tabela dos vetores de exceções/interrupções

Outro detalhe fundamental para o uso do FreeRTOS é a adaptação do vetor de exceções do microcontrolador. O core ARM Cortex-M3/4 contém, dentre muitos outros módulos, um controlador de exceções/interrupções chamado NVIC (Nested Vectored Interrupt Controller). Dentre as suas características, oferece tratamento de exceção/interrupção vetorizado. Isso significa que o processador busca o vetor correspondente à exceção ativa sem a necessidade de algum software calcular o endereço do handler da correspondente exceção. Ao contrário do que acontece com micro-processadores ARM clássicos, o NVIC obtém tal valor por meio de hardware, tendo como dados a posição inicial da tabela de vetores de exceções e o código da exceção. A localização da posição inicial dessa tabela, que é implementada como um array de words de 32 bits, é configurada por padrão no endereço 0x0 do mapa de memória do micro-processador, mas pode ser alterada em runtime. Dessa forma, a cada 4 bytes dentro dessa tabela de vetores é especificado o endereço de um handler para a respectiva exceção.

Algumas exceções do core ARM Cortex-M3/4 são tratadas pelo kernel do FreeRTOS, cujos handlers estão implementados na camada portable do sistema operacional. Veja a seguir quais são essas exceções.

SysTick timer

Todo RTOS faz uso de um timer periódico para gerenciamento do tick do scheduler. O core ARM Cortex-M3/4 oferece um timer dedicado para essa função, chamado de SysTick timer, não sendo necessário utilizar um periférico de timer genérico para essa função. É a partir da exceção causada pelo timeout desse timer que o kernel trata todo o gerenciamento de tempo do sistema, usando o tick do scheduler como parâmetro, e força a troca de contexto. Esse processo é iniciado gerando uma exceção de PendSV via software, como mostrado abaixo.

PendSV

PendSV (Pended Service Call) é um tipo de exceção muito importante para suporte de operações de sistemas operacionais. Setando o bit 28, chamado de PENDSVSET, no registrador ICSR (Interrupt control and state register) do microcontrolador STM32F4xx, é indicado o estado pending da exceção PendSV para o NVIC. Assim que nenhuma exceção de maior prioridade que a PendSV estiver ativa, esta é atendida e seu handler é chamado, xPortPendSVHandler(), indicado na tabela de vetores do micro-processador. Veja abaixo o seu código:

Essa exceção é responsável por realizar a troca de contexto do sistema, fazendo com que o scheduler substitua a tarefa sendo executada no momento pela tarefa de maior prioridade pronta para ser executada.

SVC

Assim como a exceção PendSV, a SVC (Supervisor Call) interpreta um papel fundamental nas implementações de sistemas operacionais. Essa exceção é causada pela instrução SVC, cujo handler é executado logo após esta chamada, a não ser que uma outra exceção de maior prioridade aconteça ao mesmo tempo.

Em muitos sistemas operacionais, o uso de Supervisor Call é utilizado como API para permitir que tarefas acessem recursos do sistema, fazendo uma ligação entre user space e kernel space. O FreeRTOS usa esse mecanismo, mas somente para executar a primeira tarefa do sistema, por meio da função prvPortStartFirstTask(), onde é feita a chamada SVC para o serviço número 0 (zero), como mostrado abaixo.

 Criação de uma tarefa e inicialização do kernel

Agora resta somente mais um passo! Precisa ser criada uma tarefa, por meio da API do FreeRTOS, usando a função xTaskCreate(), e inicializar o kernel com a chamada à função vTaskStartScheduler().

Na aplicação disponibilizada foi criada uma tarefa para executar exatamente a mesma função da aplicação bare-metal estudada até então: acender os leds da placa STM32F4Discovery de forma sequencial. Segue parte do código da aplicação:

Pronto! Agora a aplicação bare-metal está migrada para uma versão com o FreeRTOS. Vamos compilá-la e depurá-la com o que aprendemos até aqui? Conecte a sua placa STM32F4Discovery no seu PC com o cabo USB e execute os seguintes comandos para compilar a aplicação e iniciar o servidor GDB, o OpenOCD:

As mensagens abaixo devem ser exibidas. Neste momento o OpenOCD já iniciou o seu servidor GDB e está aguardando comandos do aplicativo cliente.

O passo seguinte é, em outro prompt do shell, inicializar o cliente GDB, indicar a aplicação a ser depurada e executar comandos de gravação/depuração no prompt do cliente GDB, como mostrado abaixo:

Como esperado, os leds acedem da mesma forma que aconteceu com a aplicação bare-metal. Verificamos que o breakpoint é ativado na primeira e nas seguintes execuções do loop da tarefa leds_blink_task. Agora é só criar mais tarefas para a brincadeira ficar mais divertida. Isso fica a gosto do cliente! E a função main(), não é mais executada? Não! Todo o controle de qual tarefa a ser executada está sob a responsabilidade do scheduler do FreeRTOS. Nos momentos em que não existem tarefas com alguma atividade a ser realizada, como acontece no momento em que a função vTaskDelay() é chamada, a tarefa Idle do RTOS é executada. Mas o que ganhamos com isso? Nos próximos posts explicaremos as diferenças e, principalmente, o que é oferecido de vantagem com essa nova implementação. Aguardem!

Outros artigos da série

<< GNU ARM Cross-toolchain – FreeRTOS + GCC + STM32F4Discovery – Parte 1GNU ARM Cross-toolchain – Eclipse + FreeRTOS + GCC – Parte 1 >>