Post on 19-Feb-2022
1César Ofuchi – ofuchi@utfpr.edu.br
Programação Concorrente e
CMSIS RTOS
César Yutaka Ofuchi
ofuchi@utfpr.edu.br
(adaptado do prof. André Schneider de Oliveira)
2César Ofuchi – ofuchi@utfpr.edu.br
Referências Úteis
• Trevor Martin-The Designer’s Guide to
the Cortex-M Processor Family-Newnes(2016)
– Capítulo 9: Cortex Microcontroller Software
Interface Standard-Real Time Operating
System
• Material Complementar– (site prof. Andre Schneider)
http://dainf.ct.utfpr.edu.br/~andre/doku.php?id=sistemas_embarcados
– (site prof. Carlos Maziero)
http://wiki.inf.ufpr.br/maziero/doku.php
- CMSIS RTOS
https://www.keil.com/pack/doc/CMSIS/RTOS/html/index.html
3César Ofuchi – ofuchi@utfpr.edu.br
Concorrência
• Um programa concorrente descreve diversas
atividades que ocorrem simultaneamente, de
modo diferente de programas comuns, que
descrevem apenas uma atividade (ex: função
main em linguagem C)
4César Ofuchi – ofuchi@utfpr.edu.br
Concorrência
• Um programa concorrente descreve diversas
atividades que ocorrem simultaneamente, de
modo diferente de programas comuns, que
descrevem apenas uma atividade (ex: função
main em linguagem C)
5César Ofuchi – ofuchi@utfpr.edu.br
Prog. Sequencial x Prog. Concorrente
• Analogia indivíduo x equipe
– Indivíduo:
• Responsável por todas as tarefas
– Equipe:
• Ocorre divisão de tarefas entre vários indivíduos
6César Ofuchi – ofuchi@utfpr.edu.br
Vantagens do Trabalho em Equipe
• Em uma equipe é menos complexo definir o
trabalho de cada indivíduo
• Não há necessidade de um indivíduo mudar de
atividade ao longo do tempo
• Há separação entre atividade e controle de
atividade (priorização)
7César Ofuchi – ofuchi@utfpr.edu.br
Implementação de Concorrência
Tarefa
1
Tarefa
2
Tarefa
3
Laço
Interrupção 1
Interrupção 2
Interrupção 3
Tarefa
1
Tarefa
2
Tarefa
3
Int
Int
Sequencial Laço + Interrupções RTOS (Multi-thread)
- Periféricos
- Eventos externos
- Comunicação
8César Ofuchi – ofuchi@utfpr.edu.br
Desafios
• Multi-core
– Sincronização de tarefas: 1 processo dividido em 2 ou
mais threads (ociosidade, paralelismo)
• Mono-core
– Preempção de tarefas: capacidade de interromper o
processo e trocar por outro (troca de contexto, pilha,
prioridade)
• Compartilhamento de recursos
– Processador : chaveamento de contexto
– Regiões de memória :variáveis compartilhadas - conflito
– Periféricos: múltiplos acessos, acessos simultâneos,
conflitos de interrupção
9César Ofuchi – ofuchi@utfpr.edu.br
Multi-threading com RTOS
• Múltiplas “linhas” de execução
P1 P2 ... Pn
Real Time OS
Hardware
Processador
Memória
Periféricos
Múltiplos processos
Memória compartilhada
Periféricos compartilhados
Controle de execução de
tarefas
Gerenciamento de Memória
10César Ofuchi – ofuchi@utfpr.edu.br
Multi-threading com RTOS
• RTOS cria processadores virtuais idênticos– Registradores e pilha individuais
• Sistemas multi-core– Muito mais processadores virtuais do que núcleos
• A soma da capacidade de processamento dos
processadores virtuais é igual à capacidade de
processamento original
11César Ofuchi – ofuchi@utfpr.edu.br
Regiões de Memória
Flash
CODE
RAM
HEAP
STACK
DATA
CPU
Registradores
Programação sequencial
12César Ofuchi – ofuchi@utfpr.edu.br
Regiões de Memória
Programação concorrente com RTOS
FlashCODE
RAMHEAP
DATA
RAMRegs 1
STACK 1
RAMRegs n
STACK n
...
CPURegistradores
13César Ofuchi – ofuchi@utfpr.edu.br
Efeito ao Longo do Tempo
(granularidade grossa)
Uma Thread é iniciada até uma ociosidade (desperdício), nesse
ponto inicia outra thread
segundos
Como as tarefas parecem estar sendo executadas:
14César Ofuchi – ofuchi@utfpr.edu.br
Efeito ao Longo do Tempo
(granularidade fina)
Rodízio aproveitando todos os ciclos de clock, sem ociosidade
milisegundos
Porém, apenas uma tarefa é executada por vez...
15César Ofuchi – ofuchi@utfpr.edu.br
Efeito ao Longo do Tempo
(granularidade)
Thread A
A1 A2 X X A3
Thread B
B1 X X B2 X
Thread C
C1 C2 C3 C4 X
Granularidade grossa
A1 A2 X B1 X C1 C2 C3 C4 X A3 B2
Granularidade fina
A1 B1 C1 A2 B2 C2 A3 C3 C4
ORDEM: A->B->C
16César Ofuchi – ofuchi@utfpr.edu.br
Acesso a Recursos Compartilhados
• Acessos múltiplos a recursos compartilhados, sem modificações de estado, podem ocorrer em paralelo sem conflitos (leitura x atualização)
• Problemas surgem quando acessos aos recursos compartilhados modificam o seu estado– Acesso concorrente a memória
compartilhada
– Acesso concorrente a periférico compartilhado
17César Ofuchi – ofuchi@utfpr.edu.br17
Conceito de Seção Crítica
• Thread pode ser dividida em seção crítica e não-crítica
• A seção crítica está relacionada com a área de código que acessa o recurso compartilhado
18César Ofuchi – ofuchi@utfpr.edu.br18
Conceito de Seção Crítica
• Solução: apenas uma thread pode estar acessando a sua seção crítica
• Um único processo pode estar nesta seção em determinado instante de tempo
• Certificar-se de que no máximo um processo pode entrar na sua seção crítica (exclusão mútua)
19César Ofuchi – ofuchi@utfpr.edu.br
Maiores Preocupações da Programação Concorrente
• Exclusão mútua– Apenas um processo na seção crítica em determinado
instante de tempo (concorrentemente)
• Ausência de impasse (deadlock)– Se dois ou mais tentarem entrar, ao menos um terá sucesso
(disputa pelo acesso à seção crítica)
20César Ofuchi – ofuchi@utfpr.edu.br
Maiores Preocupações da Programação Concorrente
• Ausência de atrasos desnecessários– Se não houver outros processos na seção crítica, um processo
tentando entrar não deve sofrer atrasos
• Garantia de entrada– todas as thread devem ter a oportunidade de acessar a sua
seção crítica
21César Ofuchi – ofuchi@utfpr.edu.br
Real Time Operating System (RTOS)
• Noção de Tempo– Qualitativa (quanto o tempo é
representado por palavras como
antes, depois, alguma hora, etc.)
• Exemplo: Abrir a porta depois de
apertar o botão.
– Quantitativo (noção numérica,
tempo é medido utilizando um
relógio real)
• Exemplo: Sistema air bag deve
funcionar em 1-2 milissegundos.
Sistema Real Time ... Existe tempo não real?
Sistema tem restrições de tempo para funcionar corretamente!
22César Ofuchi – ofuchi@utfpr.edu.br
Tipos de Tempo Real
• Divisão entre 2/3 categorias
Hard Real Time
- Sistema deve cumprir deadline senão resulta em falha.
- Consequências catrastróficasquando falha.
Exemplo:
Airbag
Soft Real Time
- Deadlines são toleráveis mas indesejáveis.
- Atrelado a Qualidade de Serviço (QoS).
Exemplo:
Streaming de vídeo
Botão do teclado
Firm Real Time
- Sistema não cumprir deadline não produz falha.
- Resultado é obsoleto e deve ser descartado.
Exemplo:
Robo que faz a manufatura de uma peça (cuja falha é detectada no setor de qualidade)
23César Ofuchi – ofuchi@utfpr.edu.br
CMSIS
24César Ofuchi – ofuchi@utfpr.edu.br
CMSIS RTOS KEIL RTX
• Segue o padrão CMSIS voltado
para a linha Cortex
Obs: (ARM comprou a KEIL em 2005)
25César Ofuchi – ofuchi@utfpr.edu.br
Outros RTOS
RTOS Empresa Características
FreeRTOS FreeRTOS OpenSouce gratuíto
μC/OS Micrium Sistema pago, com certificação para
indústria (automotivo, aviônica,
ferroviário, etc)
Linux RT Linux OpenSouce, porém ocupa muita
memória e não é próprio para μC de
entrada
TI-RTOS Texas
Instruments
MQX Freescale/N
XP
...
26César Ofuchi – ofuchi@utfpr.edu.br
Estado das Tarefas no CMSIS RTOS
Time^Signal^Message^Mail^Release
Yield
^Scheduling
Scheduling
27César Ofuchi – ofuchi@utfpr.edu.br
Estado das Tarefas
• Pronta (Ready): A tarefa está em memória,
pronta para executar (ou para continuar
sua execução), apenas aguardando a
disponibilidade do processador.
• Executando(Running): O processador está
dedicado à tarefa, executando suas
instruções e fazendo avançar seu estado
• Esperando(Waiting): A tarefa não pode
executar porque esta esperando dados
externos ainda não disponíveis, algum tipo
de sincropnização (fim de outra tarefa
para liberar recurso compartilhado) ou
eventos temporais (como delay).
• Inativa (Inactive): O processamento da
tarefa foi encerrado
28César Ofuchi – ofuchi@utfpr.edu.br
Transições
• Pronta -> Executando: Tarefa escolhida
pelo escalonador.
• Executando->Pronta: Acaba a fatia de
tempo destinada à tarefa; como nesse
momento a tarefa não precisa de outros
recursos além do processador, ela volta
a fila de tarefas prontas.
• Executando->Terminada: Tarefa encerra
execução ou é abortada por algum erro.
• Executando->Esperando: tarefa precisa
de um recurso não disponível, como
dados ou sincronização; ela abandona o
processador e fica esperando o recurso.
• Esperando->Pronta: O recurso solicitado
esta disponível, ela pode executar e
entra na fila ao estado pronta.
29César Ofuchi – ofuchi@utfpr.edu.br
Prioridades
osPriorityIdle = -3,
osPriorityLow = -2,
osPriorityBelowNormal = -1,
osPriorityNormal = 0,
osPriorityAboveNormal = +1,
osPriorityHigh = +2,
osPriorityRealtime = +3,
osPriorityError = 0x84
30César Ofuchi – ofuchi@utfpr.edu.br
Implementação RTX
• Adicionar o arquivo de configuração RTOS no projeto:
RTX_Conf_CM.c
• Adicionar a biblioteca Cortex-M3 no projeto:
RTX_LIB_CM.a
• Incluir o header no programaprincipal:
#include "cmsis_os.h”
31César Ofuchi – ofuchi@utfpr.edu.br
Kernel (Núcleo do SO)
Através do Kernel RTOS é possível
• obter informações do sistema e do Kernel
• obter a versão do CMSIS-RTOS API
• inicializar o Kernel e criar os objetos RTOS
• iniciar a execução do Kernel RTOS e do
gerenciamento das threads
• verificar o status da execução do Kernel RTOS
32César Ofuchi – ofuchi@utfpr.edu.br32
Os elementos do Kernel seguem um ciclo de
vida:
1. Definição
2. Inicialização
3. Operação
4. Término
Ciclo de Vida dos Elementos do Kernel
33César Ofuchi – ofuchi@utfpr.edu.br
Informação e Controle do Kernel
• osKernelInitialize - Inicializa o kernel
• osKernelStart - Ativa o kernel
• osKernelRunning - Consulta se o kernel está ativo
• osKernelSysTick - Obtém o valor do temporizador do
kernel
• osDelay (função de espera genérica) - Espera por um tempo
específico
34César Ofuchi – ofuchi@utfpr.edu.br
Definição e Acesso das Threads
osThreadDef(job1, osPriorityAboveNormal, 1, 0)
•Macro que cria uma instância de uma estrutura do tipoosThreadDef_t, que contém:
– nome da tarefa
– prioridade
– número máximo de instâncias
– tamanho da pilha em bytes
•O nome desta instância é: os_thread_def_job1
osThread(job1)
•Macro que é expandida para: &os_thread_def_job1, ou seja, um
ponteiro para a estrutura criada com osThreadDef
35César Ofuchi – ofuchi@utfpr.edu.br35
Gerenciamento de Tarefas
• osThreadCreate - Ativa a execução de uma tarefa
• osThreadTerminate - Desativa a execução de uma tarefa
• osThreadYield - Passa a execução à próxima tarefa que pronta
• osThreadGetId - Obtém o identificador que referencia a tarefa
• osThreadSetPriority - Altera a prioridade de uma tarefa
• osThreadGetPriority - Obtém a prioridade atual de uma tarefa
36César Ofuchi – ofuchi@utfpr.edu.br
Estrutura Básica
#include "cmsis_os.h"
// definições de tarefas, temporizadores, etc.
// declarações das funções das tarefas e de callback
void main(){
osKernelInitialize();
// inicializações de hardware
// ativação de tarefas, temporizadores, etc.
osKernelStart();
// laço de repetição ou encerramento da tarefa main()
} // main
37César Ofuchi – ofuchi@utfpr.edu.br
Exemplo de Uso (Tarefa)
#include "LPC13xx.h" // CMSIS-Core
#include "gpio.h" // Lib_EABaseBoard
#include "cmsis_os.h" // CMSIS-RTOS
void thread1(void const *argument){
while(1){
GPIOSetValue(0, 7, 0); // apaga LED2
osDelay(500);
GPIOSetValue(0, 7, 1); // acende LED2
osDelay(500);
}
}
osThreadDef(thread1, osPriorityNormal, 1, 0);
38César Ofuchi – ofuchi@utfpr.edu.br
Exemplo de Uso (Tarefa)
void main(){
osKernelInitialize();
SystemInit();
GPIOInit();
GPIOSetDir(0, 7, 1); // LED2 como saída
osThreadCreate(osThread(thread1), NULL);
osKernelStart();
osDelay(osWaitForever);
}
39César Ofuchi – ofuchi@utfpr.edu.br10/19/2017
Exemplo Thread no RTOS LPC1343
40César Ofuchi – ofuchi@utfpr.edu.br
Prática
Fazer o download do novo workspace com CMSIS RTOS na página
• Habilitar exemplo RTOS_1 thread e testar
• Avaliar o arquivo cmsis_os.h
• Avaliar arquivo de configuração RTX_Conf_CM.c
41César Ofuchi – ofuchi@utfpr.edu.br
Projeto e Análise de sistemas concorrentes
• Projeto teórico– Diagrama de estados e transições
• Análise dos resultados– Diagrama de Gantt
10/19/2017
42César Ofuchi – ofuchi@utfpr.edu.br
Diagrama de Estados e Transições
• Realizar a representação gráfica das principais
ações e eventos da solução proposta
• Organizar o estudo do problema e esboço da
solução
• Importante ferramente para agilizar o
desenvolvimento
43César Ofuchi – ofuchi@utfpr.edu.br
43
Principais Entidades
Estado inicial
Estado final
Estado
Transição
Condição
evento [condição] / ação
44César Ofuchi – ofuchi@utfpr.edu.br
Exemplo: Semáforo
• Cruzamento de duas vias de mão única com
dois semáforos S1 e S2
• TVerde = 20 seg
• TAmarelo = 4 seg
• TVermelho = 28 seg
• TSobreposição = 2 seg
S1
S2
45César Ofuchi – ofuchi@utfpr.edu.br
Diagrama de Tempo
S1
S2
Vermelho Verde A Vermelho Verde A
Verde A Vermelho Verde A Vermelho
28 20 4 28 20 4
20 4 28 20 4 28
S1 – Semáforo 1S2 – Semáforo 2
t(s)
46César Ofuchi – ofuchi@utfpr.edu.br
Número de Estados
S1
S2
Vermelho Verde A
Verde A Vermelho
1 2 3 4 5 6 1
48César Ofuchi – ofuchi@utfpr.edu.br
Exemplo: Semáforo Inteligente
• Além dos dois semáforos S1 e S2, existem
também contadores de veículos (c1 e c2)
• Deixar verde > tempo para rua com > carros
• TContagem = 5 min
• c1 ≥ c2 → TVerde1 = 30 seg
→ TVerde2 = 20 seg
• c1 < c2 → TVerde1 = 20 seg
→ TVerde2 = 30 seg S1
S2
c1c2
50César Ofuchi – ofuchi@utfpr.edu.br
Diagrama de Estados e Transições
• Draw.io (ferramenta de desenho na
nuvem)
– https://www.draw.io/
• Yakindu Statechart Tools (desenho +
simulação)
– http://statecharts.org/
51César Ofuchi – ofuchi@utfpr.edu.br10/19/2017
Diagrama de Gantt
• Objetiva descrever a descrição das etapas de um
projeto em relação ao tempo
• Também pode ser aplicado para ilustrar a
execução de um sistema multithread,
– cada etapa representa o estado de uma thread
52César Ofuchi – ofuchi@utfpr.edu.br52
Diagrama de Gantt
53César Ofuchi – ofuchi@utfpr.edu.br53
Tipos de Tarefas
54César Ofuchi – ofuchi@utfpr.edu.br10/19/2017
Diagrama de Gantt
• Mermaid Live Editor
https://knsv.github.io/mermaid/live_editor/
• Documentação Diagrama de Gantt
https://mermaidjs.github.io/gantt.html
55César Ofuchi – ofuchi@utfpr.edu.br10/19/2017
Prática gerar diagramas de Gantt
• Mermaid Live Editor
https://knsv.github.io/mermaid/live_editor/
• Documentação Diagrama de Gantt
https://mermaidjs.github.io/gantt.html
56César Ofuchi – ofuchi@utfpr.edu.br
Prática – Gerar Diagramas de Gantt
• Habilitar exemplo Gantt_diagram e testar
• Abrir a pasta do projeto no diretório “Examples” e copier conteúdo do arquivo “gantt.txt”
• Abrir o site e colar no text box do lado esquerdo
https://knsv.github.io/mermaid/live_editor/
57César Ofuchi – ofuchi@utfpr.edu.br10/19/2017
Exemplo RTOS Gantt 1/2
58César Ofuchi – ofuchi@utfpr.edu.br10/19/2017
Exemplo RTOS Gantt 2/2
59César Ofuchi – ofuchi@utfpr.edu.br
Roadmap Laboratórios -> Prova
DataLogger 1.0
- FatFs/SD Card
- Drivers
- Timers
DataLogger 2.0
- RTOS
-Processamento dos dados
- Interrupção
- Comunicação Serial com PC
DataLogger 3.0
-Comunicação Serial com PC
-Protocolo de comunicação (Máquina de
Estados)
-Escalonamento
Prova 2
Questões
30%
Apresentação 70%
dia semana atividade de entrega
19/10/2017 hoje Prévia laboratórios
26/10/2017 semana 1 Datalogger 1.0
02/11/2017 Recesso/feriado semana 2
09/11/2017 semana 3
16/11/2017 semana 4 Datalogger 2.0
23/11/2017 semana 5
30/11/2017 semana 6
07/12/2017 semana 7 Prova -> apresentação Datalogger 3.0 + questões
14/12/2017 semana 8 Recuperação/Fechamento
60César Ofuchi – ofuchi@utfpr.edu.br
Problemas com tempo de kit
• Diminução do tempo de aula teórica (maior
tempo de aula prática)
• Entregas serão em semanas distintas do prof.
André Schneider
• Agendar horário com professor para utilizar um kit
e mandar e-mail com dúvidas (avaliando)
• Simulação de partes do código
61César Ofuchi – ofuchi@utfpr.edu.br
Simulação
• Gravação de arquivo:– fprintf em arquivo (similar ao gantt)
• Comunicação serial com PC– com0com null modem emulator
– Free Virtual Serial Ports emulator
• Sensores (geração de valores aleatórios+delay)