Conectando Sistemas Embarcados

Prof. Eduardo Augusto Bezerra 

Faculdade de Informática, PUC-RS

Porto Alegre, Março de 2004

http://www.inf.pucrs.br/~eduardob/

6.a. Gerência de Comunicação: Visão Geral de Sistemas Operacionais e Linguagens

·        Até recentemente sistemas operacionais como o MS-DOS rodando em processadores tais como o 8088 (PC-XT) e 80286 (primeiro PC-AT) permitiam ao desenvolvedor re-programar praticamente toda a máquina. Era possível, por exemplo, re-programar o teclado ou o relógio de tempo real do computador. Isso se devia ao fato também da arquitetura desses processadores que não possuíam características tais como o modo protegido dos processadores atuais.

·        Com o surgimento de processadores mais sofisticados e com a disseminação e evolução do sistema operacional MS-Windows para uma plataforma multitarefa 32 bits, e em modo protegido, o acesso direto ao hardware passou a ser um perigo para o bom funcionamento do sistema. Processadores ‘386 e superiores possuem o “modo protegido” onde o acesso direto a portas pode ser impedido.

·        Existem duas solucoes para o problema de acesso as portas de entrada e saida nas versoes 32 bits do Windows. A primeira solucao e a criacao de um device driver que executara com privilegio nivel 0 para entrada/saida (modo kernel, ou super-usuario). Dados poderao entao ser enviados por programas do usuario (privilegio nivel 3) para o device driver, e o driver executara a operacao de entrada/saida.

·        Uma outra alternativa e a modificacao da tabela de permissoes de entrada/saida do sistema operacional. Existe um bit nessa tabela para cada porta do sistema. A tabela podera ser modificada de forma a dar permissao de acesso irrestrito a uma determinada porta. A opcao do device driver e a melhor. O driver devera ser escrito de forma a verificar se existem conflitos antes de acessar a porta.

·        O conceito de drivers (device drivers) foi introduzido no Windows com o objetivo de isolar o hardware da aplicacao do usuario. As versões mais recentes do Windows possuem o conceito de drivers virtuais de dispositivos, ou VxDs, que possibilitam ao desenvolvedor escrever aplicativos que acessem virtualmente os recursos de entrada/saída e interrupções desse sistema operacional.

·        Um driver é utilizado, basicamente, para interfacear um dispositivo de hardware à CPU. Sistemas operacionais de 32 bits tais como o Windows NT, Windows XP e Unix, proíbem ou tentam evitar que os aplicativos acessem diretamente as portas de entrada e saída. É preciso utilizar os serviços dos drivers, que possuem os devidos previlégios, para obter acesso indireto às portas de entrada/saída.

·        A forma mais bem comportada e, consequentemente, a mais indicada para acessar um dispositivo externo, é por intermédio da API (Application Programming Interface) apropriada.

·        É possível, por exemplo, escrever um driver USB utilizando diretamente as informações sobre o protocolo descrito anteriormente para gerenciar um dispositivo conectado a essa porta de um computador pessoal. Porém é muito mais fácil utilizar as funções disponíveis na API da linguagem escolhida para a implementação. Essas funcoes se encarregam de “conversar” com o driver.

·        A utilização das funções da API na construção do driver ou aplicação significa não apenas uma economia nas etapas de implementação e teste, mas também uma maior portabilidade.

·        Outro ponto é a questão de segurança existente em sistemas unix e versões recentes do Windows. Como os programas de usuários comuns (sem permissões de super-usuário) normalmente não conseguem acessar diretamente as portas de entrada/saída da máquina, o uso de algumas APIs pode possibilitar ao usuário o acesso em mais alto nível da porta, ou melhor, do driver para acesso à porta.

·        Para as portas que não possuem um padrão bem definido, é mais difícil de se encontrar APIs padronizadas, e o usuário acaba tendo que utilizar o conhecimento mais baixo nível sobre a porta para implementar o driver ou aplicação.

·        O sistema de entrada/saída do unix possui uma estrutura conhecida como open-read-write-close, uma vez que esses são os passos para a realização de uma operação de E/S com arquivos, dispositivos ou portas de E/S.

·        As operações de entrada/saída são realizadas por meio de arquivos. O sistema operacional atribui um descritor de arquivo, que é um número que identifica o arquivo, tanto para dispositivos, portas de E/S ou arquivos propriamente ditos. Um programa utiliza esse descritor de arquivo para acessar o “arquivo”.

·        Uma função de abertura de arquivo (open) é necessária para atribuir o descritor à variável no programa. Uma função de leitura (read) é utilizada para transferir informações do “arquivo” para o programa do usuário. Uma função de escrita (write) é utilizada para transferir informações do programa do usuário para o “arquivo”. Uma função de fechamento de arquivo (open) é utilizada para devolver o descritor do arquivo ao sistema operacional. As funções de leitura/escrita utilizam o número do descritor do arquivo, o número de bytes a ser transferido, e o endereço de um buffer para o qual serão escritos ou lidos dados.