6/4/2009. Aula 11. Engenharia de Sistemas Embarcados

(1)

Engenharia de Sistemas Embarcados

Prof. Abel Guilhermino

Tópico: Sistemas Operacionais Embarcados

Aula 11

Introdução

• No contexto geral, o Sistema Operacional (SO) é uma camada complexa de software residente entre os aplicativos e o hardware.

Tipos de Sistemas Operacionais

• Batch (de lote):

– todos os programas a executar eram colocados em uma fila, com seus dados e demais informações para execução. Ex: OS/360 e VMS

• Rede:

– deve possuir a capacidade de oferecer às aplicações locais recursos que estejam localizados em outros computadores da rede.

• Distribuído:

– Em um SO distribuído, os recursos de cada máquina estão

disponíveis globalmente, de forma transparente ao

usuário. Ao lançar uma aplicação o usuário interage com a janela, mas não sabe onde ela está executando ou armazenando os arquivos: o sistema é quem decide de forma transparente. Ex: Amoeba, Clouds.

Tipos de Sistemas Operacionais

• Multi-usuário:

– Deve suportar a identificação do “dono” de cada recurso dentro do sistema (arquivos, processos, conexões, etc) e impor regras de controle de acesso para impedir o uso desses recursos por usuários não autorizados.

• Desktop:

– Um SO de mesa é voltado ao atendimento do usuário doméstico e coorporativo para realização de atividades

corriqueiras (internet, planilhas, editores, etc). Ex:

Windows, XP, MacOS X, Linux.

• Servidor:

– Deve permitir a gestão eficiente de grandes quantidades de recursos (disco, memória, processadores), impondo prioridades e limites sobre uso de recursos pelos usuários

Tipos de Sistemas Operacionais

• Embutido:

– É dito embutido quando é construído para operar sobre um

hardware com poucos recursos de processamento,

armazenamento e energia. Ex: µC/OS, Xylnx, LynxOS,

VxWorks,µClinux.

• Tempo Real:

– Um SO de tempo real não precisa ser ultra-rápido; sua característica essencial é ter um comportamento temporal previsível. Sua estrutura interna deve ser construída de forma a minimizar esperas e latências imprevisíveis, como tempo de acessos a disco e sincronização excessiva. Ex: DCX, RXT Tiny, USX, CMX, ByteBOX, QNX, RT-Linux, VxWorks, ERCOS, RTAI.

Sistema Operacional Embarcado

• Um sistema operacional (SO) é dito embutido (embedded) quando é construído para operar sobre um hardware com poucos recursos de processamento, armazenamento e energia. • Muitas vezes um SO embutido se apresenta na

forma de uma biblioteca a ser ligada ao programa da aplicação (que é fixa).

• Muitos sistemas embutidos têm características de tempo real, e vire-versa.

• Exemplos de SO para aplicações embarcadas: DCX, RXT Tiny, USX, CMX, ByteBOX, QNX, RT-Linux, VxWorks, ERCOS,µClinux.

(2)

Modelo de Processo

Contexto de software Contexto de hardware Espaço de endereçamento programa Registradores Gerais Registrador PC Registrador SP Registrador de status Endereços de memória principal alocado nome PID Owner(UID) prioridade Tempo processador Deadline* quotas privilégios

Organização de um SO

• A forma mais simples de organizar um SO é colocar toda sua funcionalidade dentro de um único programa chamado kernel ou núcleo.

• O Kernel inclui o código necessário para prover toda funcionalidade do SO (escalonamento, gerência de memória, sistemas de arquivos, protocolos, device drivers, etc).

Organização de um SO

Kernel Monolítico

• Internamente, o código do kernel é dividido

em procedimentos. No entanto, tudo é

ligado junto e qualquer rotina pode chamar

qualquer rotina.

• O conceito de processo existe fora do

kernel, mas não dentro dele.

Kernel Monolítico

• Uma interrupção de hardware periférico ou de software (chamada de sistema) gera um chaveamento de contexto do processo que estava executando para o fluxo interno do kernel. • No que diz respeito as interrupções de hardware,

existem 2 variações do kernel monolítico:

– Não-Interrompível: enquanto o kernel está executando

nada mais acontece, nem mesmo interrupções de

periféricos como temporizadores e controladores de disco. Isso reduz desempenho

– Interrompível: eventos associados com periféricos e temporizadores ganham imediata atenção.

Kernel Convencional

• É aquele que além de interrompível, permite uma troca de contexto mesmo quando o código do kernel estiver executando.

• O conceito de processo existe também dentro do kernel, uma vez que o processo pode ser suspenso e liberado mais tarde enquanto executa o kernel.

(3)

Kernel Convencional

• No kernel monolítico apenas uma pilha

basta, pois a cada momento apenas um

fluxo de execução existe dentro dele.

• No kernel convencional um processo pode

passar o processador para outro processo

que também vai executar código do kernel.

Logo, é necessária uma pilha interna ao

kernel para cada processo

Kernel Convencional Kernel Convencional

• Tipos de Kernel Convencional

– Não-preemptivo: quando o processo que está executando código do kernel não perde o processador para outro processo.

– Com pontos de preempção: quando somente suspende um processo que executa código do kernel em pontos previamente definidos do código, nos quais é sabido que nenhuma estrutura de dados está inconsistente. – Preemptivo: aquele que realiza chaveamento de

contexto tão logo o processo de mais alta prioridade seja liberado. Para isso é necessário algum mecanismo como semáforo.

• Threads

– Como existe no kernel convencional possibilidade de execução de vários fluxos de execução simultaneamente, pode-se usar construções chamadas threads. Threads do kernel são fluxos de execução que executam o tempo todo código do kernel. Eles executam tarefas auxiliares.

Microkernel

• Esta abordagem suporta os serviços mais

elementares

de

um

SO:

gerência

de

processador e uma gerência de memória

simples.

• Subtipos

– Microkernel com kernel:

– Microkernel com processos servidores:

Microkernel

Microkernel com

com kernel

kernel

• O microkernel corresponde a funcionalidade de mais

baixo nível do kernel

convencional preemptivo,

aquela responsável por

realizar chaveamento dos

processos. • Suporta um kernel semelhante ao convencional preemptivo, separado da funcionalidade inserida no microkernel.

Microkernel

Microkernel com Processos Servidores

com Processos Servidores

• Conjunto de processos servidores autônomos.

• Chamadas de serviço dos processos feitas diretamente para eles, sem passar por uma camada que uniformize a interface do kernel. • Temos um microkernel que

suporta um conjunto de processos com espaços de endereçamento independentes.

• Alguns processos executam programas de usuário, outros implementam serviços do S.O.

• Cada processo servidor pode conter várias threads para

• Exemplo o Minix. • Vantagem:

• Facilidade para atualizações • Isolamento entre os

diferentes componentes • Depuração e manutenção

mais fácil

• Facilidade para distribuição e tolerância a falhas. • Desvantagem

• Custo alto associado a chamada do sistema

Gerenciamento de Tarefas

(4)

Controle Temporal

• Controle dos instantes de execução das operações do programa (disparo das atividades, verificação do cumprimento dos dealines)

• Disparo de tarefas:

– Por tempo (time-trigger) - TT

• Execução das tarefas é disparada por intermédio de um sinal de controle baseado na progressão do tempo (interrupção periódica)

– Por eventos (event-trigger) - ET

• Execução das tarefas disparada por intermédio de um sinal de controle assíncrono baseado na alteração do estado do sistema (interrupção externa)

Classificação

((Garantias Temporais)

Garantias Temporais)

• Não Tempo Real (time-sharing)

– Tempo ocioso entre processos são compartilhados com outros processos para dinamizar o sistema.

• Ex: Unix, Linux, Windows NT

• Soft Real-Time

– Usam solução de escalonamento de tempo real mas não oferecem garantias temporais

• Ex: OS9, RT-Linux, pSOS, VRTx

• Hard Real-Time

– Oferecem garantias temporais

• Ex: HARTIK, Spring Kernel.

Gerenciamento de Tarefas

• Escalonamento

– Determina qual a próxima tarefa a ser executada

• Pode ser efetuado

– Com preempção

• Uma tarefa pode ser suspensa para

execução de uma outra mais

prioritária

– Sem preempção

• Uma tarefa, uma vez iniciada a execução, não pode ser interrompida até terminar. T₂ T₁ T2 T1

Gerenciamento de Tarefas

• Técnicas Típicas em Sistemas NRT (Não

tempo-real) ou mesmo em alguns SRT (Soft

real-time)

– FCFS (First Come First Served)

• As tarefas são atendidas na ordem em que elas chegam

– Round Robin

• Executa as tarefas em sequência independente da importância

FCFS (First Come First Served)

• Uso

de

uma

lista

de

processos

sem

prioridades

• São atendidos na ordem em que chegam

• Escalonamento não-preemptivo

• Simples e Justo

• Bom para sistemas em batch

B C D E F … N

CPU

A

FIM

Round Robin

• Características:

– Uso de uma lista de processos sem prioridade – Escalonamento preemptivo

– Simples e justo

– Bom para sistemas interativos – Imune a problemas de starvation*

• Todos os processos são armazenados em uma fila circular. Uma unidade de tempo definida pelo SO (quantum) determina o tempo de cada interrupção.

– Se processo acaba antes doquantum, ok, pega o próximo.

– Se processo não acaba antes do quantum, preempção e o processo vai para o final da fila circular.

*Starvation: um processo nunca é executado pois processos de prioridade maior impedem

(5)

Gerenciamento de Tarefas

• Técnicas Típicas em Sistemas HRT (Hard

tempo-real) e em alguns SRT (Soft

real-time)

– Rate Monotonic Scheduling (RMS)

• Prioridades Fixas, Menor período maior prioridade

– Earliest Deadline First (EDF)

• Prioridades dinâmicas, Inversas à distância à deadline

– Deadline Monotonic Scheduling (DMS)

• Prioridades Fixas, Menor deadline maior prioridade

Rate Monotonic Scheduling (RMS)

• O algoritmo produz escalas em tempo de

execução

através

de

escalonadores

preemptivos, dirigidos a prioridade.

• Modelo de tarefas:

– São periódicas e independentes – Deadline coincide com o período (Di=Pi)

– Tempo de computação (Ci) de cada tarefa é conhecido e constante (WCCT – Worst Case Computation Time)

– O tempo de chaveamento entre tarefas é assumido como nulo.

Rate Monotonic Scheduling (RMS)

• Política de Atribuição de Prioridades

– Quanto menor o período, maior sua prioridade no conjunto.

– Análise de escalonabilidade baseia-se no cálculo da

Utilização

• Condição Suficiente

• Condição necessária e suficiente (períodos múltiplos, U→0,69)

Exemplo (RMS)

• Avaliar escalonabilidade de um conjunto de

tarefas periódicas usando RMS;

Earliest Deadline First (EDF)

• Escalonamento baseado em prioridades: a escala é produzida em tempo de execução por um escalonador preemptivo dirigido a prioridades.

• É um esquema de prioridade dinâmica • Modelo de tarefas idêntica ao RMS

– São periódicas e independentes – Deadline coincide com o período (Di=Pi)

Earliest Deadline First (EDF)

• Política de Atribuição de Prioridades

– A tarefa mais prioritária é a que tem o deadline dimais próximo do tempo atual.

– A cada chegada de tarefa, a fila de pronto é reordenada considerando a nova distribuição de prioridades

– O novo valor de deadline absoluto é determinado considerando o número de períodos que antecede a atual ativação (K): dik= kPi.

• Teste de escalonabilidade

(6)

Exemplo (EDF)

Deadline Monotonic Scheduling(DMS)

• Estende o modelo de tarefas do RMS.

• Modelo de tarefas:

– São periódicas e independentes

– Deadline coincide com o período (Di=Pi) • Em substituição a: (Di≤≤≤≤Pi)

Deadline

Deadline Monotonic

Monotonic Scheduling

Scheduling(DMS)

(DMS)

• Política de Atribuição de Prioridades

– Determina prioridade baseada em di.

• Menor o dimaior a prioridade.

– Teste de escalonabilidade

• Condição Suficiente

Diferença em relação ao RMS Exemplo:

2006.2 Engenharia de Sistemas Embarcados 34

Deadline

Deadline Monotonic

Monotonic Scheduling

Scheduling(DMS)

(DMS)

Comunicação entre processos

Tarefas Dependentes

• Em um ambiente multitarefa o compartilhamento de recursos é implícito e determina alguma forma de relação de exclusão entre tarefas.

• Comunicações entre tarefas no mesmo processador, podem se dar através de variáveis compartilhadas, usando mecanismos como: semáforos e monitores para implementar a exclusão mútua entre as tarefas.

(7)

Exemplo de Problema

Processo A

x := x + 1;

Processo B

x := x - 1;

Processo comando x Ra Rb

A LOAD x,Ra 2 2 * A ADD 1,Ra 2 3 * B LOAD x,Rb 2 * 2 B SUB 1, Rb 2 * 1 A STORE Ra,x 3 3 * B STORE Rb,x 1 * 1

Processo B

LOAD x,Rb SUB 1,Rb STORE Rb,x

Processo A

LOAD x,Ra ADD 1,Ra STORE Ra,x

Soluções

• Exclusão Mútua

– Solução mais simples para tarefas dependentes; – Impede que dois ou mais processos acessem um

mesmo recurso simultaneamente;

– Enquanto um processo estiver acessando determinado recurso, todos os demais processos que queiram acessá-lo deverão esperar pelo término da utilização do recurso.

• Soluções para exclusão mútua:

– Test-and-set – Algoritmo de Dekker – Algoritmo de Peterson

Semáforos

• Mecanismo de sincronização não estruturado

que permite implementar, de forma simples,

a exclusão mútua entre processos.

• Um semáforo é uma variável inteira, não

negativa, que só pode ser manipulada por

duas instruções: DOWN e UP.

– As instruções UP e DOWN são indivisíveis, ou seja, a execução dessas instruções não pode ser interrompida.

Monitores

• Mecanismo de sincronização estruturado de

alto

nível

tendo

em

vista

que

são

implementados pelo compilador.

• A comunicação do processo com o monitor é

feita unicamente através de chamadas a seus

procedimentos e dos parâmetros passados.

Troca de Mensagens

• Execuções sincronizadas

• Pode ser implementada de 2 maneiras:

– Comunicação Direta: exige que ao enviar uma mensagem, o processo enderece explicitamente o nome do processo receptor ou transmissor. – Comunicação indireta: utiliza uma área

compartilhada, onde as mensagens podem ser colocadas pelo processo transmissor e retiradas pelo receptor. (Buffer = Port ou Mailbox)

• Fazem uso de buffer para trocar mensagens através do uso de duas rotinas:

– SEND(receptor, mensagem) – RECEIVE (transmissor, mensagem).

Sistemas Operacionais para ARM7

(8)

Sistemas Operacionais para o ARM7

• Os microcontroladores ARM7 costumam ser dispositivos com capacidades de memória limitadas

– Memória de programa entre 16kB e 1MB – Memória de dados entre 16KB e 64KB

• Indisponibilidade de MMU (unidade de gerenciamento de memória) nos modelos ARM7TDMI dificulta ainda mais a execução de Sos complexos neste tipo de plataforma.

Sistemas Operacionais para o ARM7

• Apesar das limitações, pode-se encontrar uma vasta quantidade de sistemas operacionais, grande maioria RTOS.

– µCLinux

• Variante do Linux, desprovida de MMU

– VxWorks

• RTOS (Wind River Systems) com kernel

multi-tasking. Possui agendamento preemptivo,

rápida resposta a interrupções, comunic. entre processos, sincronização e sistemas de arquivos.

– IAR PowerPAC

• RTOS (IAR), que é um sistemas de arquivos e suporte a cartões de memória SD/MMC e pilha USB.

Sistemas Operacionais para o ARM7 – RL-ARM

• From Keil, é uma biblioteca de aplicações que inclui um kernel de tempo real (RTX), um sistema de arquivos, pilhas TCP/IP, CAN e USB.

– EmbOS

• By Segger. É um RTOS com um núcleo pequeno e rápido que pode ser portado para diversas plataformas

– FreeRTOS

• RTOS de código aberto, configurável para multitarefa cooperativa ou preemptiva.

– Contiki

• RTOS de código aberto voltado para sistemas com pequena disponibilidade de memória.