programação concorrente e cmsis rtos
TRANSCRIPT
1César Ofuchi – [email protected]
Programação Concorrente e
CMSIS RTOS
César Yutaka Ofuchi
(adaptado do prof. André Schneider de Oliveira)
2César Ofuchi – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
Regiões de Memória
Flash
CODE
RAM
HEAP
STACK
DATA
CPU
Registradores
Programação sequencial
12César Ofuchi – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
CMSIS
24César Ofuchi – [email protected]
CMSIS RTOS KEIL RTX
• Segue o padrão CMSIS voltado
para a linha Cortex
Obs: (ARM comprou a KEIL em 2005)
25César Ofuchi – [email protected]
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 – [email protected]
Estado das Tarefas no CMSIS RTOS
Time^Signal^Message^Mail^Release
Yield
^Scheduling
Scheduling
27César Ofuchi – [email protected]
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 – [email protected]
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 – [email protected]
Prioridades
osPriorityIdle = -3,
osPriorityLow = -2,
osPriorityBelowNormal = -1,
osPriorityNormal = 0,
osPriorityAboveNormal = +1,
osPriorityHigh = +2,
osPriorityRealtime = +3,
osPriorityError = 0x84
30César Ofuchi – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]/19/2017
Exemplo Thread no RTOS LPC1343
40César Ofuchi – [email protected]
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 – [email protected]
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 – [email protected]
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 – [email protected]
43
Principais Entidades
Estado inicial
Estado final
Estado
Transição
Condição
evento [condição] / ação
44César Ofuchi – [email protected]
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 – [email protected]
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 – [email protected]
Número de Estados
S1
S2
Vermelho Verde A
Verde A Vermelho
1 2 3 4 5 6 1
48César Ofuchi – [email protected]
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 – [email protected]
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 – [email protected]/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 – [email protected]
Diagrama de Gantt
53César Ofuchi – [email protected]
Tipos de Tarefas
54César Ofuchi – [email protected]/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 – [email protected]/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 – [email protected]
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 – [email protected]/19/2017
Exemplo RTOS Gantt 1/2
58César Ofuchi – [email protected]/19/2017
Exemplo RTOS Gantt 2/2
59César Ofuchi – [email protected]
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 – [email protected]
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 – [email protected]
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)