RTAI - Uma implementação de Tempo Real Crítico em Linux

Transcrição

1 RTAI - Uma implementação de Tempo Real Crítico em Linux Sistemas Operacionais - INE5355 Professor Antônio Augusto Fröhlich Alunos Andreu Carminati Pedro H. R. Ribeiro Novembro de

2 1 Sistemas de Tempo Real Crítico Como no caso de sistemas de controle com múltiplas entradas e múltiplas saídas, sistemas de Tempo Real Crítico não podem perder seus prazos e necessitam ter latências limitadas. Normalmente os requisitos de aplicações de Tempo Real Critico são preenchidos pela utilização CPUs dedicadas, como processadores de sinal digital (DSPs) e microcontroladores. Estes oferecem uma garantia de latência de interrupção no intervalo de alguns poucos ciclos de execução. Já os processadores de uso geral (General Purpuse CPUs (GPCPU)), como os utilizados nos computadores pessoais, são em princípio não utilizáveis para aplicações de tempo real. A utilização de memória virtual, de uma unidade de gerenciamento de memória (MMU), a alta dependência das caches multi-nível para performance, a possibilidade de arbitragem nos barramentos por dispositivos de I/O, a execução em pipelines profundos e utilização de especulação, tudo isto sujeita o sistema a latências e variações não determinísticas no tempo de execução. No entanto se olharmos o problema de execução em tempo real do ponto de vista da tarefa a ser realizada, podemos assumir que o conceito de Tempo Real Crítico é relativo à tarefa em questão. Se o sistema controlado possui uma vazão baixa e o número de amostragens que o sistema de controle consegue garantir por intervalo de tempo é grande o suficiente então para este caso podemos afirmar que o sistema de controle é de tempo real crítico. Como um exemplo, se o dispositivo controlado possui uma vazão de 1KHz e o sistema de controle realiza amostragens em uma frequência próxima de 10KHz, então as variações no período de amostragens causarão atrasos de leitura em um nível aceitável. Aplicações de tempo real geralmente não exercem somente controle mas frequentemente necessitam também se comunicar via links rápidos, receber comandos, supervisionar sua operação, fazer logs em um discos e oferecer visualização complexa de dados. Isto faz com que a possibilidade de utilizar uma infraestrutura conhecida e flexível seja algo a se desejar. A possibilidade de utilizar um SO conhecido e com um conjunto grande de ferramentas como o Linux para o desenvolvimento de sistemas de tempo real crítico sobre um computador pessoal é atrativa. Este é o objetivo do projeto RTAI. Para atingir este objetivo o RTAI [2] utiliza a estratégia de isolar o ambiente de execução de aplicações de tempo real crítico do ambiente de execução das demais aplicações. Ele é um componente que trabalha juntamente com o Linux, lidando com o escalonamento das tarefas de tempo real e permitindo que o Linux provenha todas as demais funcionalidade. Para poder cooperar com o Linux é necessário que o hardware seja compartilhado entre o Linux e o RTAI. Isto é feito pela utilização de um nanokernel, o Adeos. O Adeos assume o controle do hardware e, em particular, repassa as interrupções para os outros componentes. Na denominação utilizada no projeto Adeos, o Linux e o RTAI representam diferentes domínios. 2 Adeos O Adeos[3] (Adaptative Domain Environment for Operating Systems), liberado sob uma licença livre em junho de 2002, provê uma interface entre o kernel do linux e o hardware que permite a execução de múltiplos sistemas operacionais 2

3 sobre a mesma máquina. Diferente de das soluções de simulação preexistentes, como VMWare, Plex86, VirtualPC e SimOS; o ADEOS oferece ao usuário também um controle do SO base. Baseado no projeto SPACE, cada SO sendo executado sobre o Adeos é encapsulado em um domínio sobre o qual possui controle total. Figura 1: Arquitetura de comunicação do Adeos. Replica de figura em [3] No ambiente que o Adeos provê existem quatro categorias de métodos de comunicação. Na categoria A estão os acessos gerais dos domínios a memória e hardware. Como em caso de sucesso esses acessos não geram falta, cada domínio opera como se o Adeos não estivesse presente. Na categoria B o Adeos é envolvido recebendo o controle do hardware devido a uma interrupção de hardware ou software (a maneira como o Adeos gerencia interrupções está descrita a seguir). A categoria C consiste em invocar o tratador de interrupções de um SO provendo a ele as informações sobre a interrupção gerada. E a categoria D envolve comunicação mútua entre um domínio e o Adeos, permitindo que o SO peça ao Adeos o acesso a recursos de outros domínios ou maior prioridade no tratamento de interrupções. Figura 2: Linha de interrupções do Adeos. Replica de imagem em [1]. O Adeos utiliza uma linha de interrupções para propagar as interrupções pelos diferentes domínios sendo executados. Caso um domínio deseje pode requisitar ser o primeiro na linha de interrupções. O Adeos foi implementado como um módulo carregável do Linux. Este módulo quando carregado assume o controle do hardware. Para isto ele utiliza dos níveis de prioridade disponíveis na arquitetura ix86. Por padrão o Linux executa no nível 0, comummente denominado ring-zero. O que o Adeos faz 3

4 é transportar o Linux do ring-zero para o ring-one. Desta maneira todas as instruções privilegiadas, como cli e sti não são mais permitidas e sua execução passa a gerar faltas pelo processador. Essas faltas são tratadas pelo Adeos que as trata de maneira semelhante a como os sistemas de virtualização o fazem. O próprio Adeus necessita ser executado no ring-zero. A maneira como ele realiza sua mudança para o ring-zero e a mudança do Linux para o ring-one é modificando a GDT e alterando os privilégios dos códigos. O registrador IDT (Interrupt Descriptor Table também é modificado para apontar para as tabelas do próprio Adeos. A IDT original é mantida pelo Adeos para que possa invocar a entrada correta quando uma interrupção necessitar ser repassada para o Linux. 3 RTAI Figura 3: Camadas no RTAI. Replica de figura em [1]. O projeto RTAI [] teve inicio no Dipartimento di Ingegneria Aerospaziale del Politecnico di Milano (DIAPM) em 1996/1997. Seu objetivo era tornar disponível uma ferramenta que permitisse o desenvolvimento de atividades de pesquisa relacionadas a controle ativo de atuadores aerodinâmicos, e que isto fosse possível de ser realizado em computadores pessoais 32 bits, placas de aquisição de dados comuns e através da utilização de linguagens de alto nível para permitir fácil uso por estudantes de graduação. Inicialmente o RTAI foi desenvolvido como um conjunto de patches para o Linux. Com o surgimento do Adeos o RTAI passou a utilizá-lo assumindo uma maneira mais estruturada e flexível de suporte a Tempo Real no Linux. Para obter determinismo de Hard Real Time, o RTAI é o domínio de mais alta prioridade na linha de propagação de interrupções do Adeos, sempre processando as interrupções antes do domínio Linux. Desta maneira a aplicação hard real time no RTAI é servida primeiramente ainda que seja necessário fazer preempt de qualquer outro processo não hard real time. 4

5 Além da garantia de determinismo no tratamento de exceções oferecida pelo Adeos, o RTAI provê serviços de escalonamento de tarefas a serem executados em tempo real juntamente com maneiras de permitir interações com as tarefas sendo escalonadas no Linux padrão. Os escalonadores do RTAI são totalmente preemptíveis e podem ser escalonados diretamente dos tratadores de interrupções para que o Linux não tenha de atrasar qualquer atividade de tempo real do RTAI. Tarefas desenvolvidas para executar sobre o RTAI podem ser executadas tanto no espaço de usuário como no espaço do kernel. Para tal o RTAI mantém uma API única para os dois casos. Isto facilita o desenvolvimento de tarefas de controle dentro do kernel, o que permite menor latência de execução evitando a troca de contexto pelas MMUs existentes em processadores de uso geral. Esta funcionalidade adiciona o grande beneficio se poder iniciar um desenvolvimento de maneira segura em espaço de usuário e posteriormente, quando for necessário para obter maior performance, migrar para dentro do kernel. O RTAI dispõe de três diferentes escalonadores: o Uniprocessor (UP), é otimizado para maquinas uniprocessadas; o Symetric Multi Processors (SMP) permite executar qualquer tarefa pronta em qualquer CPU, enquanto permite definir a seleção de uma CPU específica para uma tarefa; o escalonador Multi uniprocessor, diferentemente, impõe que toda tarefa é amarrada a uma CPU especifica desde o momento de sua criação, permitindo a obtenção de melhores performances pela exploração mais eficiente das caches. Também estão disponíveis as seguintes politicas de escalonamento: First in Fisrt Out (FIFO) totalmente preemptível, para escalonamento cooperativo voluntário. Uma tarefa segura a CPU até que a libere ou até que uma tarefa de maior prioridade preempte sua execução. Sob esta politica de escalonamento há uma função de suporte para auxiliar o cumprimento dos prazos de execução utilizando prioridades atribuídas estaticamente de acordo com o conceito de Taxa Monotônica. Round Robin (RR), como o FIFO mas com um limite de tempo por tarefa, depois da qual a CPU pode ser repassada a qualquer outra tarefa de mesma prioridade esperando na fila para execução. Early Deadline First (EDF), para atribuir prioridades dinamicamente de maneira a cumprir o prazo final para término de execução das tarefas. Requer do usuário atribuir estimativas razoavelmente boas para o tempo de execução requerido por cada tarefa periódica. Resumidamente o RTAI oferece os seguintes serviços: Gerenciamento básico de tarefas. Gerenciamento de memória. Memória compartilhada inter-tarefas, espaço de dados compartilhado entre espaços de usuário e kernel. Semáforos. Mecanismos de comunicações inter-processos. Incluindo RPC. Tratamento de interrupções em espaço de usuário. Monitores Watchdog. 5

6 4 Exemplos de aplicações sobre RTAI 4.1 Aplicação em espaço de usuário 6

7 #include <stdio.h> #include <errno.h> #include <fcntl.h> #include <sched.h> #include <signal.h> #include <sys/mman.h> #include <stdlib.h> #include <pthread.h> #include <unistd.h> #include <rtai_lxrt.h> #include <rtai_sem.h> #include <rtai_usi.h> #include <sys/io.h> #define PARPORT_IRQ 7 #define BASEPORT 0x378 static SEM *intsem, *dspsem; static volatile int end = 1; static volatile int ovr, intcnt, retval, maxcnt; static void *timer_handler(void *args) { RT_TASK *handler; if (!(handler = rt_task_init_schmod(nam2num("handlr"), 0, 0, 0, SCHED_FIFO, 0xF))) { printf("cannot INIT HANDLER TASK > HANDLR <\n"); exit(1); rt_allow_nonroot_hrt(); mlockall(mcl_current MCL_FUTURE); rt_make_hard_real_time(); end = 0; while (!end) { do { ovr = rt_wait_intr(intsem, (void *)&retval); hard_sti(); if (end) break; // overrun processing, if any, goes here if (ovr > 0) { rt_sem_signal(dspsem); /* normal processing goes here */ intcnt++; rt_sem_signal(dspsem); // notify main() rt_ack_irq(parport_irq); while (ovr > 0); rt_pend_linux_irq(parport_irq); 7

8 rt_make_soft_real_time(); rt_task_delete(handler); intcnt = maxcnt; return 0; static pthread_t thread; int main(void) { RT_TASK *maint; printf("give THE NUMBER OF INTERRUPTS YOU WANT TO COUNT: "); scanf("%d", &maxcnt); if (!(maint = rt_task_init(nam2num("main"), 1, 0, 0))) { printf("cannot INIT MAIN TASK > MAIN <\n"); exit(1); // Create semaphore for notification when interrupt occurs // In the thread we wait with rt_wait_intr until an interrupt occurs if (!(intsem = rt_sem_init(nam2num("irqsem"), 0))) { printf("cannot INIT SEMAPHORE > IRQSEM <\n"); exit(1); // create semaphore to notify main() when interrupt occurs if (!(dspsem = rt_sem_init(nam2num("dspsem"), 0))) { printf("cannot INIT SEMAPHORE > DSPSEM <\n"); exit(1); if (iopl(3)) { // ask for permission to access the parallel port from user-space printf("iopl err\n"); rt_task_delete(maint); rt_sem_delete(intsem); rt_sem_delete(dspsem); exit(1); outb_p(0x10, BASEPORT + 2); //set port to interrupt mode; pins are output // create thread pthread_create(&thread, NULL, timer_handler, NULL); // wait until thread went to hard real time while (end) { usleep(100000); // request the interrupt and bind it to semaphore rt_request_global_irq(parport_irq, intsem, USI_SEM); rt_startup_irq(parport_irq); 8

9 rt_enable_irq(parport_irq); while (intcnt < maxcnt) { rt_sem_wait(dspsem); printf("retval %d, OVERRUNS %d, INTERRUPT COUNT %d\n", retval, ovr, intcnt); end = 1; printf("test ENDS\n"); outb_p(0, BASEPORT); outb_p(255, BASEPORT); // generate final interrupt to unblock rt_wait_intr outb_p(0, BASEPORT); pthread_join(thread, NULL); rt_free_global_irq(parport_irq); rt_task_delete(maint); rt_sem_delete(intsem); rt_sem_delete(dspsem); return 0; 9

10 4.2 Aplicação em espaço de kernel 10

11 #include <linux/kernel.h>/* decls needed for kernel modules */ #include <linux/module.h>/* decls needed for kernel modules */ #include <linux/version.h>/* LINUX_VERSION_CODE, KERNEL_VERSION() */ #include "rtai.h" /* RTAI configuration switches */ #include "rtai_sched.h" /* rt_set_periodic_mode(), start_rt_timer(), nano2count(), RT_LOWEST_PRIORITY, rt_task_init(), rt_task_make_periodic() */ #if! defined(rt_lowest_priority) #if defined(rt_sched_lowest_priority) #define RT_LOWEST_PRIORITY RT_SCHED_LOWEST_PRIORITY #else #error RT_SCHED_LOWEST_PRIORITY not defined #endif #endif #include <linux/errno.h>/* EINVAL, ENOMEM */ #include <asm/io.h>/* may be <sys/io.h> on some systems */ #if LINUX_VERSION_CODE > KERNEL_VERSION(2,4,0) MODULE_LICENSE("GPL"); #endif static RT_TASK hello_task; /* we ll fill this in with our task */ static RTIME hello_period_ns = ; /* timer period, in nanoseconds */ void hello_function(int arg) { while (1) { printk("hello world"); rt_task_wait_period(); return; int init_module(void) { RTIME hello_period_count; /* requested timer period, in counts */ RTIME timer_period_count; /* actual timer period, in counts */ int retval; /* we look at our return values */ rt_set_periodic_mode(); hello_period_count = nano2count(hellp_period_ns); 11

12 timer_period_count = start_rt_timer(hello_period_count); printk("periodic_task: requested %d counts, got %d counts\n", (int) hello_period_count, (int) timer_period_count); rt_task_init(&hello_task,/* pointer to our task structure */ hello_function, /* the actual timer function */ 0,/* initial task parameter; we ignore */ 1024,/* 1-K stack is enough for us */ RT_LOWEST_PRIORITY, /* lowest is fine for our 1 task */ 0,/* uses floating point; we don t */ 0); /* signal handler; we don t use signals */ rt_task_make_periodic(&hello_task, /* pointer to our task structure */ /* start one cycle from now */ rt_get_time() + hello_period_count, hello_period_count); /* recurring period */ return 0; void cleanup_module(void) { rt_task_delete(&hello_task); return; 12

13 Referências [1] A. Barbalace, A. Luchetta, G. Manduchi, M. Moro, A. Soppelsa, and C. Taliercio. Performance comparison of vxworks, linux, rtai, and xenomai in a hard real-time application. Nuclear Science, IEEE Transactions on, 55(1): , Feb [2] Mantegazza P. Dozio L. Linux real time application interface (rtai) in low cost high performance motion control [3] Karim Yaghmour. Adaptive domain environment for operating systems