6 Prog Conc RTOS

Programação Concorrente e
CMSIS RTOS
César Yutaka Ofuchi
ofuchi@utfpr.edu.br
(adaptado do prof. André Schneider de Oliveira)
César Ofuchi – ofuchi@utfpr.edu.br 1

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

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)

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)

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

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)

Implementação de Concorrência
Sequencial Laço + Interrupções RTOS (Multi-thread)
Tarefa Tarefa
Laço
1 1
Int
Interrupção 1
Tarefa Tarefa
2 2
Interrupção 2
Int
Tarefa Interrupção 3 Tarefa

3 3
- Periféricos
- Eventos externos
- Comunicação

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

Multi-threading com RTOS
• Múltiplas “linhas” de execução
Múltiplos processos
P1 P2 ... Pn Memória compartilhada
Periféricos compartilhados
Real Time OS
Controle de
Gerenciamento
execução de
de Memória
tarefas
Processador
Hardware Memória
Periféricos

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

Regiões de Memória
Programação sequencial
Flash RAM CPU

HEAP
CODE STACK Registradores
DATA

Regiões de Memória
Programação concorrente com RTOS
Flash CPU
CODE Registradores
RAM RAM RAM

HEAP Regs 1 ... Regs n
DATA STACK 1 STACK n

Efeito ao Longo do Tempo
(granularidade grossa)
Como as tarefas parecem estar sendo executadas:
segundos
Uma Thread é iniciada até uma ociosidade (desperdício), nesse

ponto inicia outra thread

(granularidade fina)
Porém, apenas uma tarefa é executada por vez...
milisegundos
Rodízio aproveitando todos os ciclos de clock, sem ociosidade

(granularidade)
ORDEM: A->B->C
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

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

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
17
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)
18
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)

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

Real Time Operating System (RTOS)
Sistema Real Time ... Existe tempo não real?
• 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 tem restrições de tempo para funcionar corretamente!

Tipos de Tempo Real
• Divisão entre 2/3 categorias
Hard Real Time Firm Real Time Soft Real Time

- Sistema deve - Sistema não - Deadlines são
cumprir deadline cumprir deadline toleráveis mas
senão resulta em não produz falha. indesejáveis.
falha. - Resultado é - Atrelado a
- Consequências obsoleto e deve Qualidade de
catrastróficas ser descartado. Serviço (QoS).
quando falha.
Exemplo: Exemplo:
Exemplo: Robo que faz a Streaming de vídeo
Airbag manufatura de uma Botão do teclado
peça (cuja falha é
detectada no setor
de qualidade)

CMSIS

CMSIS RTOS KEIL RTX
• Segue o padrão CMSIS voltado

para a linha Cortex
Obs: (ARM comprou a KEIL em 2005)

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
...

Estado das Tarefas no CMSIS RTOS
Time^Signal^Message^Mail^Release
Scheduling
Yield
^Scheduling

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

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.

Prioridades
osPriorityIdle = -3,
osPriorityLow = -2,
osPriorityBelowNormal = -1,
osPriorityNormal = 0,
osPriorityAboveNormal = +1,
osPriorityHigh = +2,
osPriorityRealtime = +3,
osPriorityError = 0x84

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 programa

principal:
#include "cmsis_os.h”

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

Ciclo de Vida dos Elementos do Kernel
Os elementos do Kernel seguem um ciclo de

vida:
1. Definição
2. Inicialização
3. Operação
4. Término
32
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

Definição e Acesso das Threads
osThreadDef(job1, osPriorityAboveNormal, 1, 0)
•Macro que cria uma instância de uma estrutura do tipo
osThreadDef_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

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
35
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

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);

Exemplo de Uso (Tarefa)
void main(){
osKernelInitialize();
SystemInit();
GPIOInit();
GPIOSetDir(0, 7, 1); // LED2 como saída
osThreadCreate(osThread(thread1), NULL);
osKernelStart();
osDelay(osWaitForever);
}

Exemplo Thread no RTOS LPC1343
10/19/2017
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

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
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

Principais Entidades
Estado inicial
Estado final
Estado
Transição
Condição
evento [condição] / ação
43
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
Diagrama de Tempo
S1 – Semáforo 1
S2 – Semáforo 2
Vermelho Verde A Vermelho Verde A

S1
28 20 4 28 20 4
Verde A Vermelho Verde A Vermelho

S2
20 4 28 20 4 28
t(s)

Número de Estados
Vermelho Verde A
S1
Verde A Vermelho
S2
1 2 3 4 5 6 1

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 c1
c2
→ TVerde2 = 30 seg S1
S2
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/

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
10/19/2017
Diagrama de Gantt
52
Tipos de Tarefas
53
Diagrama de Gantt
• Mermaid Live Editor

https://knsv.github.io/mermaid/live_editor/
• Documentação Diagrama de Gantt

https://mermaidjs.github.io/gantt.html
10/19/2017
Prática gerar diagramas de Gantt
• Mermaid Live Editor

• Documentação Diagrama de Gantt

https://mermaidjs.github.io/gantt.html
10/19/2017
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


Exemplo RTOS Gantt 1/2
10/19/2017
Exemplo RTOS Gantt 2/2
10/19/2017
Roadmap Laboratórios -> Prova
DataLogger 2.0
DataLogger 3.0
- RTOS
-Comunicação Prova 2
DataLogger 1.0 -Processamento Serial com PC Questões
- FatFs/SD Card dos dados
-Protocolo de 30%
- Drivers - Interrupção comunicação
(Máquina de Apresentação
- Timers - Comunicação
Estados) 70%
Serial com PC
-Escalonamento
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

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

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)

6 Prog Conc RTOS

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

6 Prog Conc RTOS

Загружено:

Авторское право:

Доступные форматы

Programação Concorrente e

César Ofuchi – ofuchi@utfpr.edu.br 1

• Trevor Martin-The Designer’s Guide to

César Ofuchi – ofuchi@utfpr.edu.br 2

César Ofuchi – ofuchi@utfpr.edu.br 3

César Ofuchi – ofuchi@utfpr.edu.br 4

• Analogia indivíduo x equipe

César Ofuchi – ofuchi@utfpr.edu.br 5

• Não há necessidade de um indivíduo mudar de

• Há separação entre atividade e controle de

César Ofuchi – ofuchi@utfpr.edu.br 6

Tarefa Interrupção 3 Tarefa

César Ofuchi – ofuchi@utfpr.edu.br 7

César Ofuchi – ofuchi@utfpr.edu.br 8

César Ofuchi – ofuchi@utfpr.edu.br 9

• A soma da capacidade de processamento dos

César Ofuchi – ofuchi@utfpr.edu.br 10

Flash RAM CPU

CODE STACK Registradores

César Ofuchi – ofuchi@utfpr.edu.br 11

Programação concorrente com RTOS

RAM RAM RAM

DATA STACK 1 STACK n

César Ofuchi – ofuchi@utfpr.edu.br 12

Como as tarefas parecem estar sendo executadas:

Uma Thread é iniciada até uma ociosidade (desperdício), nesse

César Ofuchi – ofuchi@utfpr.edu.br 13

Porém, apenas uma tarefa é executada por vez...

Rodízio aproveitando todos os ciclos de clock, sem ociosidade

César Ofuchi – ofuchi@utfpr.edu.br 14

César Ofuchi – ofuchi@utfpr.edu.br 15

• Problemas surgem quando acessos aos

César Ofuchi – ofuchi@utfpr.edu.br 16

• Thread pode ser dividida em seção crítica e não-

• A seção crítica está relacionada com a área de

• Um único processo pode estar nesta seção em

• Certificar-se de que no máximo um processo

• Ausência de impasse (deadlock)

César Ofuchi – ofuchi@utfpr.edu.br 19

• Ausência de atrasos desnecessários

César Ofuchi – ofuchi@utfpr.edu.br 20

Sistema Real Time ... Existe tempo não real?

– Quantitativo (noção numérica,

Sistema tem restrições de tempo para funcionar corretamente!

César Ofuchi – ofuchi@utfpr.edu.br 21

Hard Real Time Firm Real Time Soft Real Time

César Ofuchi – ofuchi@utfpr.edu.br 22

César Ofuchi – ofuchi@utfpr.edu.br 23

• Segue o padrão CMSIS voltado

Obs: (ARM comprou a KEIL em 2005)

César Ofuchi – ofuchi@utfpr.edu.br 25

César Ofuchi – ofuchi@utfpr.edu.br 26

• Pronta (Ready): A tarefa está em memória,

• Executando(Running): O processador está

• Esperando(Waiting): A tarefa não pode

• Inativa (Inactive): O processamento da

César Ofuchi – ofuchi@utfpr.edu.br 27

• Pronta -> Executando: Tarefa escolhida

• Executando->Pronta: Acaba a fatia de

• Executando->Terminada: Tarefa encerra

• Executando->Esperando: tarefa precisa

• Esperando->Pronta: O recurso solicitado

César Ofuchi – ofuchi@utfpr.edu.br 28

César Ofuchi – ofuchi@utfpr.edu.br 29