Frertos Esc Brzil

ESC Brasil 2012
Desenvolvendo com o FreeRTOS Sergio Prado
26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo
Sistemas de Tempo Real (1)
No contexto de desenvolvimento de software, um sistema projetado para receber um estmulo (ou evento), que pode ser interno ou externo, realizar o processamento e produzir uma sada. Alguns sistemas trabalham com eventos que possuem restries de tempo, ou seja, possuem um prazo ou tempo-limite para o estmulo ser processado e gerar a sada correspondente. Estes tipos de sistemas so chamados Sistemas de Tempo Real.
Sistemas de Tempo Real (2)
Portanto, um sistema de tempo real precisa garantir com que todos os eventos sejam atendidos dentro das suas respectivas restries de tempo. por isso que um sistema de tempo real esta relacionado ao determinismo, e no ao tempo de execuo! Existem basicamente dois tipos de sistemas de tempo real, classificados de acordo com a tolerncia s restries de tempo, e as consequncias em no respeitar estas restries.
Classificao
Soft real-time: Uma restrio de tempo no atingida tem como consequncia a percepo de baixa qualidade do sistema. Exemplo: um display com touch que demora para responder ao tocar na tela. Hard real-time: Uma restrio de tempo no atingida pode inutilizar o sistema ou provocar consequncias catastrficas. Exemplo: um sistema de airbag que no responde no tempo correto no momento da coliso de um veculo.
Desenvolvimento
Como desenvolver um sistema com caractersticas de tempo real?
Foreground/Background
Projetos pequenos e de baixa complexidade so desenvolvidos como sistemas foreground/background (tambm chamados de super-loop). A aplicao consiste em um loop infinito que chama algumas funes para realizar as operaes desejadas (background). E rotinas de tratamento de interrupo tratam eventos assncronos (foreground).
O super-loop (1)
Background
intmain(void) { init_hardware(); while(1){ I2C_ReadPkg(); UART_Receive(); USB_GetPacket(); Audio_Play(); ADC_Convert(); LCD_Show(); ... } }
Foreground
voidUSB_ISR(void) { Limpainterrupo; Lpacote; } voidUART_ISR(void) { Limpainterrupo; Tratabyterecebido; }
O super-loop (2)
Foreground (ISR2)
Foreground (ISR1)
Background
----- Funo #1 ------------------------- Funo #2 ----------------Loop infinito Funo #3
Linha de Tempo
Vantagens do super-loop
Fcil e rpido de desenvolver. No requer treinamento ou conhecimento de API's especficas de um sistema operacional. No consome recursos adicionais comparado soluo com um sistema operacional. Soluo tima em projetos pequenos e com requisitos modestos de restries de tempo.
Deficincias do super-loop (1)
Difcil garantir que uma operao ir ser executada dentro das restries de tempo.
Todo o cdigo em background tem a mesma prioridade. Se uma das funes demorar mais do que o esperado, todo o sistema ser impactado.
while(1){ ADC_Read(); UART_Receive(); USB_GetPacket(); ... } void ADC_Read (void) { Initialize ADC; while (conv_rdy == 0) { ; } ... }
Delays e outras rotinas podem impactar todas as funes rodando em background.

Tarefas de alta prioridade precisam ser colocadas em foreground (ISR).
ISRs muito longas podem impactar o tempo de resposta do sistema. difcil coordenar a execuo de rotinas em background e em foreground.
while(1){ I2C_ReadPkg(); UART_Receive(); USB_GetPacket(); Audio_Play(); ADC_Convert(); LCD_Show(); ... } voidUSB_ISR(void){ Clearinterrupt; Readpacket; }
Se um pacote USB recebido logo aps a chamada desta funo, o tempo de resposta ser menor.
Qualquer alterao em determinada parte do cdigo pode impactar o tempo de resposta de todo o sistema. Difcil de garantir as restries de tempo da aplicao. Sentimento de medo para alterar o cdigo. Problemas podem aparecer quando o cdigo mantido por mltiplos desenvolvedores. Como controlar?
A soluo
Precisamos ento de uma soluo que gerencie corretamente os requisitos de tempo real do sistema.
a que entra o kernel de tempo real!
O kernel de tempo real
Um kernel de tempo real um software que gerencia o tempo e os recursos da CPU, e baseado no conceito de tarefas e prioridades.
Todas as funcionalidades do sistema so divididas em tarefas (tasks ou threads). O kernel decide quando uma tarefa deve ser executada baseada na sua prioridade. Fica sob responsabilidade do desenvolvedor dividir o sistema em tarefas e definir as prioridades de acordo com as caractersticas de tempo real de cada uma delas.
Multitarefa (1)
Em um sistema multitarefa, temos a impresso de que todas as tarefas esto sendo executadas ao mesmo tempo.
TAREFA 1 TAREFA 2 TAREFA 3
t1
t2
Tempo
tn
Multitarefa (2)
Mas como o processador s pode executar uma tarefa de cada vez (considerando-se uma CPU com apenas um ncleo), realizado um chaveamento entre as tarefas:
TAREFA 1 TAREFA 2 TAREFA 3
t1
t2
Tempo
tn
Multitarefa (3)
Este chaveamento ou troca de tarefas pode acontecer em diferentes situaes:
Uma tarefa pode bloquear esperando um recurso (Ex: porta serial) estar disponvel ou um evento acontecer (Ex: receber um pacote da interface USB). Uma tarefa pode dormir por um tempo. Uma tarefa pode ser suspensa involuntariamente pelo kernel. Neste caso, chamamos o kernel de preemptivo.
Esta troca de tarefas tambm chamada de mudana de contexto (context switching).
Mudana de contexto
Enquanto uma tarefa esta em execuo, ela possui determinado contexto (variveis no stack, valores salvos nos registradores, etc). Ao mudar a tarefa em execuo, o kernel salva o contexto da tarefa a ser suspensa, e recupera o contexto da prxima tarefa a ser executada. Estas informaes de contexto de cada uma das tarefa so mantidas em uma estrutura chamada de TCB (Task Control Block).
O escalonador
O escalonador de tarefas entra em ao durante as mudanas de contexto. Ele a parte do kernel responsvel por decidir qual a prxima tarefa a ser executada em determinado momento. O algoritmo responsvel por decidir qual a prxima tarefa a ser executada chamado de poltica de escalonamento.
RTOS e kernel de tempo real
Alm do escalonador, um kernel de tempo real possui normalmente outras responsabilidades, dentre elas:
Gerenciar a comunicao entre as tarefas. Gerenciar o uso de memria.
Um RTOS (Real-Time Operational System), ou sistema operacional de tempo real, composto de um kernel de tempo real, e pode incluir outros servios de alto nvel como gerenciamento de arquivos, pilhas de protocolo, interface grfica, etc.
As vantagens de um RTOS (1)
A vantagem mais clara a possibilidade de priorizar tarefas para garantir que as restries de tempo da aplicao sejam atendidas. O uso de um RTOS permite que voc trabalhe orientado eventos, evitando por exemplo rotinas de pooling, e melhorando a eficincia do sistema. Como voc precisa dividir a aplicao em tarefas, incentiva uma melhor arquitetura e modularidade do sistema.
As vantagens de um RTOS (2)
Com um sistema modular, fica mais fcil dar manuteno. Facilita os testes, j que cada tarefa uma entidade independente. Como cada tarefa tem uma interface bem definida, facilita o desenvolvimento em equipes com mltiplos desenvolvedores. Incentiva o reuso de cdigo.
As desvantagens
Um RTOS facilita bastante o desenvolvimento de sistemas de tempo real, mas ele possui algumas desvantagens que precisamos levar em considerao:
Os servios providos pelo kernel adicionam um overhead de execuo, que pode variar entre 2% e 5% do uso da CPU, dependendo do RTOS. Um RTOS precisa de um espao extra de ROM para armazenar o cdigo, que pode variar de 4KB at algumas centenas de kilobytes. Um RTOS consome RAM para armazenar o contexto e o stack de cada tarefa, que pode variar de algumas centenas de bytes at algumas dezenas de kilobytes.
FreeRTOS - Histrico
Criado nos idos do ano 2000 por Richard Barry. o sistema operacional de tempo real de cdigo aberto mais utilizado no mundo. simples, pequeno e extremamente portvel. Site do projeto, com muita documentao disponvel: http://www.freertos.org/ Cdigo-fonte pode ser baixado em: http://sourceforge.net/projects/freertos/files/
Caractersticas (1)
Projetado para ser pequeno, simples e fcil de usar. Escrito em C, extremamente portvel. Suporta mais de 30 arquiteturas diferentes. Em uma configurao tpica, uma imagem do FreeRTOS pode ocupar de 4KB a 9KB de cdigo (ROM) e em torno de 200 bytes de dados (RAM). Kernel pode trabalhar de forma preemptiva ou colaborativa. Mutex com suporte herana de prioridade. Capacidades de trace e deteco de stack overflow.
Caractersticas (2)
Sem restrio da quantidade de tarefas que podem ser criadas, ou da quantidade de prioridades que podem ser usadas. Diversos projetos e aplicaes de demonstrao para facilitar o aprendizado. Cdigo aberto, sem royalty e com frum gratuito disponvel. Ferramentas de desenvolvimento abertas e gratuitas. Comunidade grande de usurios. Suporte e licena comercial se necessrio.
Licena
O FreeRTOS licenciado sob uma verso modificada da GPL, tem cdigo fonte aberto, no precisa pagar royalties e pode ser usado livremente em aplicaes comerciais. No precisa liberar os fontes da sua aplicao, desde que voc no crie nenhuma funcionalidade j fornecida pelo FreeRTOS. Precisa indicar que usa o FreeRTOS (um link para o site suficiente). Qualquer alterao no kernel precisa ser liberada de forma open-source.
OpenRTOS
http://www.openrtos.com/rtos/openrtos/
Verso comercial do FreeRTOS, com o mesmo cdigo-fonte, mas sem nenhuma referncia GPL. Liberdade para alterar o kernel sem precisar liberar os fontes. Acesso suporte tcnico e desenvolvimento. Proteo legal e garantia.
SafeRTOS
http://www.openrtos.com/rtos/safertos/
Verso comercial e modificada projetada para aplicaes crticas.
do
FreeRTOS,
Todas as vantagens da verso comercial (suporte, garantia, etc). Certificado para aplicaes industriais e mdicas.
Hands-on 1
Estudando os fontes do FreeRTOS
Gerenciamento de tarefas
Cada tarefa se comporta como um programa isolado.
Tem um ponto de entrada. implementada normalmente por um loop infinito. Nunca retorna! Se uma tarefa finalizar, responsabilidade do desenvolvedor remov-la da lista de tarefas do kernel.
Prottipo de uma tarefa: voidATaskFunction(void*pvParameters);
Esqueleto de uma tarefa

voidATaskFunction(void*pvParameters) { intvar; for(;;) { /*taskcodehere*/ } /*optional,onlyiftasksexitloop*/ vTaskDelete(NULL); }
Trabalhando com tarefas
Uma aplicao pode conter diversas tarefas. Em um microcontrolador com apenas um core, apenas uma tarefa esta em execuo. Portanto, isso significa que uma tarefa pode estar em dois estados: Running (executando) ou Not running (no executando, parada). Veremos mais para frente que o estado Not running possui alguns sub-estados. Esta troca de estados realizada pelo scheduler ou escalonador de tarefas.
Criando uma tarefa
portBASE_TYPExTaskCreate( pdTASK_CODEpvTaskCode, constchar*constpcName, unsignedshortusStackDepth, void*pvParameters, unsignedportBASE_TYPEuxPriority, xTaskHandle*pvCreatedTask );
Hands-on 2
Implementando tarefas
Tarefas em execuo...
TAREFA 1
TAREFA 2
t1
t2
Tempo
tn
Hands-on 3
Tarefas compartilhando cdigo
TAREFA 1
TAREFA 2
t1
t2
Tempo
tn
Prioridades
A prioridade da tarefa passada no parmetro uxPriority da funo xTaskCreate(). As prioridades vo de configMAX_PRIORITIES FreeRTOSConfig.h. 0 (menor definida prioridade) at no arquivo
Quanto maior o valor mximo, maior o consumo de RAM! As tarefas podem compartilhar a mesma prioridade. O scheduler vai garantir que a tarefa com maior prioridade pronta para execuo ser sempre executada!
Fatia de tempo
Cada tarefa tem uma fatia do tempo (time slice) para execuo. No fim desta fatia do tempo, ela ser interrompida, e o escalonador selecionar a prxima tarefa para execuo.
Tick interrupt
Para interromper uma tarefa em execuo, usada uma interrupo. Esta interrupo chamada de tick interrupt (system tick ou clock tick). uma interrupo peridica cuja frequncia esta definida em configTICK_RATE_HZ no arquivo FreeRTOSConfig.h Por exemplo, se estiver definida como 100 (Hz), significa que a fatia de tempo ser de 10ms.
Escalonador e tick interrupt

Tick interrupt e escalonador em ao
KERNEL
TAREFA 1
TAREFA 2
t1
t2
Tempo
tn
Hands-on 4
Duas tarefas com prioridades diferentes
KERNEL
TAREFA 1
TAREFA 2
t1
t2
Tempo
tn
Eventos
Em um RTOS, se criarmos tarefas que monopolizam a CPU, elas devero ter sempre a menor prioridade. Se elas tiverem uma prioridade mais alta, tarefas de menor prioridade nunca sero executadas. Por isso, as tarefas devem ser orientadas eventos, ou seja, devem aguardar um evento para realizar o processamento.
Tarefa orientada eventos

voidATaskFunction(void*pvParameters) { init_task(); for(;;) { wait_event(); process_event(); } }
Estado Blocked
Uma tarefa esperando um evento esta no estado Blocked ou bloqueada. Um tarefa pode estar bloqueada aguardando dois tipos de eventos:
Eventos temporais: evento gerado pelo prprio kernel. Ex: rotinas de delay. Eventos de sincronizao: evento originado por uma outra tarefa ou interrupo. Ex: mecanismos de comunicao entre tarefas como queues e semforos.
Estado Suspended
A nica forma de uma tarefa entrar no estado Suspended atravs da chamada vTaskSuspend(). O scheduler no tem controle sobre o estado Suspended, apenas ignora (no executa) tarefas neste estado. A nica forma de uma tarefa sair no estado Suspended atravs da chamada vTaskResume().
Estado Ready
Tarefas que no esto nos estados Blocked ou Suspended esto no estado Ready. Estas tarefas esto aguardando na fila, prontas para serem selecionadas e executadas pelo escalonador.
Possveis estados das tarefas

Running
vTaskSuspend Blocking API
Ready
vTaskResume Event
Suspended
vTaskSuspend
Blocked
Not running
Hands-on 5
Tarefas baseadas em eventos
TAREFA 1
TAREFA 2
TAREFA IDLE
t1
t2
Tempo
tn
Tarefa Idle
Neste ltimo exemplo, as tarefas esto a maioria do tempo no estado Blocked. Quando as tarefas esto neste estado, no podem ser escolhidas e executadas pelo escalonador. Mas a CPU precisa estar sempre executando alguma coisa! por isso que existe a tarefa Idle! Esta tarefa criada automaticamente quando iniciamos o escalonador ao chamar a funo vTaskStartScheduler(). Esta tarefa tem prioridade 0 (menor prioridade possvel).
Implementao da tarefa Idle

voididleTask(void*pvParameters) { for(;;) { /*donothing!*/ { } * na verdade, ela tem algumas responsabilidades, como limpar as tarefas removidas e chamar uma funo de callback que pode ser definida pelo usurio.
Idle task hook
possvel configurar uma funo de callback para ser chamada quando a tarefa Idle for executada:
Executar um processamento contnuo em background. Medir a quantidade de processamento livre disponvel. Colocar o processador em modo de baixo consumo.
Habilite a opo configUSE_IDLE_HOOK no arquivo FreeRTOSConfig.h. Implemente a funo: voidvApplicationIdleHook(void);
Hands-on 6
Implementando a tarefa idle hook
Outras funes
vTaskDelay() versus vTaskDelayUntil() xTaskGetTickCount() vTaskDelete() vTaskPrioritySet()/UxTaskPriorityGet() vTaskSuspend()/vTaskResume()/TaskYIELD() uxTaskGetHighWaterMark()
O kernel do FreeRTOS (1)
Uma aplicao composta por uma ou mais tarefas. Cada tarefa tem uma prioridade. Cada tarefa pode estar em um determinado estado (Running, Ready, Blocked, Suspended). Apenas uma tarefa pode estar no estado Running em determinado momento. O escalonador sempre seleciona a tarefa de maior prioridade e no estado Ready para ser executada.
O kernel do FreeRTOS (2)

Fixed Priority Preemptive Scheduling
TAREFA 1 (P3)
TAREFA 2 (P2)
TAREFA 3 (P1)
IDLE (P0)
t1
t2
Tempo
tn
Mais alguns detalhes...
Como regra geral, funes de hard real-time devem ter prioridades maiores que funes de soft real-time. Rate Monotonic Scheduling (RMS): maior prioridade para tarefas com maior frequncia de execuo. Tcnica se mostra bastante eficiente, mas como nem todas as tarefas so peridicas, o calculo fica mais complexo! Cooperative scheduling:
troca de contexto apenas quando a tarefa entra em Blocked ou chama taskYIELD(). Pode-se usar um esquema hbrido onde uma rotina de interrupo pode causar uma troca de contexto. Neste caso temos um sistema preemptivo sem time slicing.
Gerenciamento de queue
Um programa usando o FreeRTOS dividido em diversas tarefas. Provavelmente estas tarefas precisaro conversar entre si. Queue um mecanismo de comunicao (troca de mensagens) entre tarefas ou entre uma tarefa e uma interrupo. Um queue no pertence nenhuma tarefa em especfico. Diversas tarefas e interrupes podem compartilhar o mesmo queue, tanto para ler, quanto para escrever.
O queue
Cada queue armazena um conjunto finito de itens (queue lenght). Cada item pode ter um tamanho fixo de bytes (item size). Ambos "queue lenght" e "item size" so definidos no momento da criao do queue. O FreeRTOS aloca espao no heap para armazenar o queue.
Criado um queue
xQueueHandlexQueueCreate( unsignedportBASE_TYPEuxQueueLength, unsignedportBASE_TYPEuxItemSize);
Escrevendo no queue
portBASE_TYPExQueueSendToFront( xQueueHandlexQueue, constvoid*pvItemToQueue, portTickTypexTicksToWait); portBASE_TYPExQueueSendToBack( xQueueHandlexQueue, constvoid*pvItemToQueue, portTickTypexTicksToWait); xQueueSendToBack()exQueueSend()soequivalentes.
Lendo do queue
portBASE_TYPExQueueReceive( xQueueHandlexQueue, void*pvBuffer, portTickTypexTicksToWait); portBASE_TYPExQueuePeek( xQueueHandlexQueue, void*pvBuffer, portTickTypexTicksToWait);
Hands-on 7
Comunicao entre tarefas com queues
Interrupo
Sistemas embarcados precisam tomar aes baseados em eventos externos. Ex: um pacote chegando em uma interface Ethernet precisa ser recebido e tratado imediatamente. Como monitorar um evento? Interrupo ou pooling? Sempre que possvel, o ideal trabalhar com interrupo. Quando usamos interrupo, devemos manter seu processamento o mais breve possvel para no impactar o tempo de resposta do sistema. Uma ISR deve receber os dados do evento, dar um ACK na interrupo e deferir o trabalho para uma tarefa (handler) do RTOS. Existem alguns mecanismos para uma interrupo deferir trabalho para o handler.
Semforos binrios
Um semforo binrio (ou Binary Semaphores) um mecanismo de sincronizao disponibilizado pelo RTOS. Ele pode ser usado para acordar uma tarefa quando determinada interrupo acontecer, sincronizando a interrupo com a tarefa. Desta forma, apenas o essencial executado na interrupo, o resto deferido para a tarefa correspondente ao tratamento da interrupo.
Criando um semforo
voidvSemaphoreCreateBinary( xSemaphoreHandlexSemaphore);
Pegando um semforo
portBASE_TYPExSemaphoreTake( xSemaphoreHandlexSemaphore, portTickTypexBlockTime);
Liberando um Semforo
portBASE_TYPExSemaphoreGive( xSemaphoreHandlexSemaphore); portBASE_TYPExSemaphoreGiveFromISR( xSemaphoreHandlexSemaphore, signedportBASE_TYPE *pxHigherPriorityTaskWoken);
Hands-on 8
Sincronizando interrupo e tarefa com um semforo
Deferindo trabalho
ISR
TAREFA 2 (P2) HANDLER TAREFA 1 (P1)
IDLE (P0)
t1
t2
Tempo
tn
Counting semaphores
Semforos binrios so teis quando a frequncia de interrupes baixa, mas quando a frequncia de interrupes alta, existe a possibilidade de perdermos interrupes. O problema acontece quando mais de uma interrupo acontece no momento em que a tarefa ainda esta tratando o trabalho deferido da interrupo anterior. Para estes casos podemos usar os counting semaphores no lugar dos binary semaphores, que podem ser usados para:
Contar eventos. Gerenciar o acesso recursos.
Criando Counting Semaphores
xSemaphoreHandlexSemaphoreCreateCounting( unsignedportBASE_TYPEuxMaxCount, unsignedportBASE_TYPEuxInitialCount); O uso idntico ao semforo binrio.
Usando queues em interrupes
Voc tambm pode usar queues para transferir dados e deferir trabalho de uma interrupo para uma tarefa do RTOS. Para usar queues em interrupes, use as funes que terminam com FromISR:
XQueueSendToFrontFromISR() xQueueSendToBackFromISR() xQueueReceiveFromISR()
Hands-on 9
Sincronizando interrupo e tarefa com queue
Gerenciamento de Recursos
Em um sistema multitarefa, existe a possibilidade de uma tarefa ser interrompida durante o acesso um recurso, deixando este recurso em um estado inconsistente, e podendo causar problemas se outra tarefa tentar acessar este mesmo recurso. Exemplos:
Acesso perifricos. Acesso variveis globais. Uso de funes no-reentrantes.
Mutual exclusion
O acesso um recurso que compartilhado entre tarefas, ou entre uma tarefa e uma interrupo, devem ser gerenciados com a tcnica de mutual exclusion, para garantir a consistncia no acesso. A idia garantir que apenas uma tarefa tenha acesso exclusivo ao recurso em determinado momento. O FreeRTOS prov diversos mecanismos para implementar mutual exclusion, mas o melhor mtodo desenvolver a aplicao de forma que recursos no sejam compartilhados, e que cada recurso seja acessado por uma nica tarefa!
Critical sessions
Regies crticas so regies que acessam um recurso compartilhado, e no devem ser acessados concorrentemente por mais de uma tarefa. No FreeRTOS, pode-se usar as funes taskENTER_CRITICAL() e taskEXIT_CRITICAL() para proteger uma regio crtica: taskENTER_CRITICAL() tx_serial(buf,size); taskEXIT_CRITICAL();
Desabilitando interrupes
um mtodo bruto de controlar acesso recursos! Desabilita as interrupes do kernel, desabilitando consequentemente mudanas de contexto para qualquer outra tarefa. Regies crticas devem se manter bem pequenas porque impactam negativamente os tempos de resposta do sistema.
Pausando o escalonador
Sees crticas tambm podem ser controladas pausando o escalonador. Neste caso, as interrupes continuam habilitadas, mas as outras tarefas no so executadas: vTaskSuspendAll() tx_serial(buf,size); vTaskResumeAll();
Pausando o escalonador (2)
Use com cuidado porque resumir a execuo do escalonador pode ser uma tarefa demorada. Funes da API do FreeRTOS no podem ser usadas enquanto o escalonador estiver parado.
MUTEX (MUTual EXclusion)
O mutex um tipo especial de semforo binrio usado para controlar o acesso um recurso compartilhado entre uma ou mais tarefas.
1. Quando uma tarefa quer usar um recurso, ela adquire uma espcie de token. 2. Se outra tarefa quiser usar o mesmo recurso neste perodo, ter de esperar a liberao deste token. 3. Quando a tarefa terminar de usar o recurso, ela dever liberar o token. 4. Agora o recurso pode ser usado por outra tarefa.
Este mecanismo totalmente dependente da disciplina do desenvolvedor!
Trabalhando com Mutex

xSemaphoreHandlevSemaphoreCreateMutex(void); portBASE_TYPExSemaphoreTake( xSemaphoreHandlexSemaphore, portTickTypexBlockTime); portBASE_TYPExSemaphoreGive( xSemaphoreHandlexSemaphore);
Hands-on 10
Controlando o acesso porta serial com mutex
Inverso de prioridade
O que acontece se uma tarefa que tem prioridade 3 tenta acessar um MUTEX que j esta sendo usado por uma tarefa que tem prioridade 1? Ela espera! Pior ainda, o que acontece se neste meio tempo uma tarefa que tem prioridade 2 ficar pronta para execuo? Ela executada, fazendo com que a tarefa com prioridade 3 precise esperar mais ainda! esta situao damos o nome de inverso de prioridade. Para diminuir o impacto, o FreeRTOS usa a tcnica de herana de prioridade. A prioridade da tarefa que contm o MUTEX aumentada momentaneamente para 3 para finalizar o processamento e possibilitar o acesso da tarefa de maior prioridade.
Deadlock
Quando duas tarefas esto simultaneamente aguardando por um recurso que esta sendo ocupado pela outra tarefa.
1. Tarefa A pega recurso X. 2. Escalonador chaveia para tarefa B. 3. Tarefa B pega recurso Y, depois e tenta pegar recurso X. 4. Como recurso X esta com A, tarefa B dorme. 5. Tarefa A tenta pegar recurso Y. 6. Como recurso Y esta com B, tarefa A tambm dorme! 7. Estas tarefas nunca acordaro!
Deadlocks so erros de design da aplicao.
Gatekeeper
Em vez de termos diversas tarefas compartilhando um recurso, criamos uma tarefa com acesso exclusivo ao recurso. Todas as tarefas que querem acessar este recurso, devem enviar uma mensagem a esta tarefa. Isso evita boa parte dos problemas de deadlock e inverso de prioridade. Permite tambm que uma interrupo acesse um recurso mais facilmente!
Hands-on 11
Controlando o acesso porta serial via Gatekeeper
Gerenciamento de memria
O FreeRTOS aloca memria toda vez que um componente do sistema criado (tarefa, queue, semforo). O uso de memria em sistemas embarcados um fator crtico, e diferentes arquiteturas possuem diferentes restries para alocao de memria RAM. Por isso a implementao do FreeRTOS para alocao de memria fica na camada portvel.
Implementaes de alocao
Existem 3 implementaes das rotinas de alocao de memria no FreeRTOS, disponveis em FreeRTOS/Source/portable/MemMang:
heap_1.c: apenas aloca, no libera. Deve ser usado quando tudo criado estaticamente na funo main(). heap_2.c: aloca e desaloca memria, mas no controla fragmentao. Deve ser usada em aplicaes que apenas criam e destroem tarefas dinamicamente. heap_3.c: implementao completa do malloc() e do free(). Trata fragmentao, mas adiciona overhead de processamento e uso de memria para controle!
Dvidas?
Obrigado!
Sergio Prado
Twitter @sergioprado sergio.prado@e-labworks.com
http://e-labworks.com

Frertos Esc Brzil

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Frertos Esc Brzil

Transféré par

Droits d'auteur :

Formats disponibles

ESC Brasil 2012

Desenvolvendo com o FreeRTOS Sergio Prado

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

Sistemas de Tempo Real (1)

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

Sistemas de Tempo Real (2)

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

Como desenvolver um sistema com caractersticas de tempo real?

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

Deficincias do super-loop (1)

Delays e outras rotinas podem impactar todas as funes rodando em background.

Deficincias do super-loop (2)

Tarefas de alta prioridade precisam ser colocadas em foreground (ISR).

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

Deficincias do super-loop (3)

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

a que entra o kernel de tempo real!

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

O kernel de tempo real

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

TAREFA 1 TAREFA 2 TAREFA 3

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

Este chaveamento ou troca de tarefas pode acontecer em diferentes situaes:

Esta troca de tarefas tambm chamada de mudana de contexto (context switching).

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

RTOS e kernel de tempo real

Gerenciar a comunicao entre as tarefas. Gerenciar o uso de memria.

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

As vantagens de um RTOS (1)

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

As vantagens de um RTOS (2)

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

Verso comercial e modificada projetada para aplicaes crticas.

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

Estudando os fontes do FreeRTOS

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

Cada tarefa se comporta como um programa isolado.

Prottipo de uma tarefa: voidATaskFunction(void*pvParameters);

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

Esqueleto de uma tarefa

Trabalhando com tarefas

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

Criando uma tarefa

portBASE_TYPExTaskCreate( pdTASK_CODEpvTaskCode, constchar*constpcName, unsignedshortusStackDepth, void*pvParameters, unsignedportBASE_TYPEuxPriority, xTaskHandle*pvCreatedTask );

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

Tarefas compartilhando cdigo

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

26-27 de Junho/June 2012 Transamerica Expo Center, So Paulo

portBASE_TYPExTaskCreate( pdTASK_CODEpvTaskCode, constcharconstpcName, unsignedshortusStackDepth, voidpvParameters, unsignedportBASE_TYPEuxPriority, xTaskHandle*pvCreatedTask );