Sistemas robóticos podem ser compreendidos como sistemas concebidos de liberdade de movimentos para realizarem tarefas de forma autônoma, suas aplicações estendem-se por um amplo espectro de áreas, tais como: automação industrial; medicina; exploração espacial e outros. O presente artigo utiliza ferramentas de software livre para simular um sistema de navegação nebuloso para um agente robótico. O software Simbad, em conjunto com a biblioteca jFuzzyLogic, foram aplicados para realizar esta simulação, cujos resultados demonstram que o agente robótico é capaz de percorrer o trajeto proposto, ao mesmo tempo em que desvia dos obstáculos.

Palavras-chave: robótica móvel, lógica nebulosa, software livre

1. Introdução

O emprego de robôs para a realização de diversas tarefas tem sido cada vez mais comum, facilitando, dessa forma, o desempenho de inúmeras atividades, inclusive as mais perigosas, nas quais seria inviável ou impossível a realização delas pelo homem. Algumas vantagens proporcionadas pela utilização de robôs são: aumento de produtividade na indústria; maior precisão e velocidade na fabricação e montagem dos produtos e afastamento da mão de obra humana dos locais inóspitos. Dessa maneira, o incentivo ao desenvolvimento da robótica torna-se cada vez mais crucial para a melhoria da qualidade de vida e desenvolvimento da sociedade.

Sistemas robóticos podem ser compreendidos como sistemas concebidos de liberdade de movimentos para realizarem tarefas com certo nível de autonomia de decisão, suas aplicações estendem-se por um amplo espectro de áreas, como: automação industrial (FILHO et al., 2010); medicina (PREISING et al., 1991); exploração espacial (HIRZING et al., 1994) e outros.

O avanço da robótica também é percebido no ramo educacional, onde diversos robôs têm sido empregados para o ensino, para o provimento da multidisciplinaridade e interdisciplinaridade, fornecimento de conhecimento tecnológico e principalmente para disseminar conceitos da mecânica, eletrônica, engenharia e computação (SOLIS et al., 2009). Dessa forma, a utilização de robôs autônomos proporciona inúmeras vantagens e possui grande empregabilidade em inúmeras áreas de atuação.

A utilização de softwares livres, da mesma maneira, tem se mostrado cada vez mais notória em iniciativas governamentais e privadas. As vantagens oriundas desses softwares vão além do custo econômico, a possibilidade de modificar o código-fonte do software fornece uma grande liberdade e flexibilidade para os sistemas computacionais (STALLMAN, 1999). As características existentes no software livre contribuem para elaboração de ferramentas de simulação de sistemas robóticos, auxiliando na resolução de diversos problemas nessa área.

O objetivo deste artigo é realizar a simulação de um sistema de navegação robótica através da utilização de softwares livres. Para isso, foi utilizado o simulador Simbad (HUGUES e BREDECHE, 2006) escrito em Java, o mesmo fornece um ambiente de simulação contendo um ou mais robôs, que podem ser equipados com câmeras e sensores e um cenário contendo obstáculos e vários outros recursos adicionais. Foi utilizado também um pacote, o jFuzzyLogic (CINGOLANI, 2011), para implementar o paradigma reativo para o desvio de obstáculos através da utilização da lógica fuzzy, proporcionando ao sistema uma metodologia para representar a percepção baseada em ações. Estas duas ferramentas de software livre foram aplicadas para realizar essa simulação, cujos resultados demonstram que o agente robótico é capaz de percorrer a sequência de coordenadas especificadas, ao mesmo tempo em que desvia dos obstáculos do ambiente.

O restante do trabalho está dividido em seis seções. A seção 2 traz conceitos de robótica móvel e as dificuldades existentes na navegação robótica. A seção 3 do artigo discorre sobre a lógica fuzzy. A seção 4 detalha as ferramentas utilizadas na simulação. A seção 5 mostra como foi implementado o sistema robótico. A seção 6 exibe os resultados da simulação. Finalmente, a última seção mostra as considerações finais obtidas com a conclusão desse trabalho.

2. Robótica Móvel

A robótica móvel engloba todos aqueles dispositivos automatizados capazes de se locomoverem em um determinado ambiente. A movimentação pode ser controlada através da intervenção humana, onde temos o uso de controle remoto, por exemplo, ou através de inteligência computacional, onde os robôs podem tomar decisões sobre a rota a ser seguida através da leitura do ambiente. Existe uma grande variedade de ferramentas para a locomoção de robôs, cada uma atendendo a características específicas do ambiente. Por exemplo, robôs podem atuar em solos rochosos ou arenosos, em ambientes aquáticos ou até mesmo em céu aberto. Cada ambiente requer equipamento e controles especiais para atenderem suas especificidades.

Os paradigmas da robótica móvel são mostrados na Figura 1. A escolha de qual paradigma empregado no projeto depende da necessidade e da complexidade da tarefa a ser executada.

Figura 1 – Paradigmas na robótica: (i) hierárquico, (ii) reativo, (iii) híbrido (SIMÕES et al., 2006).

Para projetos mais complexos, nos quais o ambiente apresenta uma grande quantidade de informações, o paradigma hierárquico é mais adequado porque o robô pode tomar decisões baseadas no grau de dificuldade obtida, permitindo um domínio maior da situação. Por sua vez, o paradigma reativo procura diminuir a complexidade gerada pelo paradigma hierárquico, pois com o decorrer dos anos a etapa de planejamento se tornou demasiadamente complexa. Com o intuito de mesclar as vantagens dos dois paradigmas apresentados, surge o paradigma híbrido. Assim, uma tarefa pode ser decomposta em sub-tarefas para que o robô possa escolher qual a ação mais adequada para executá-las (SIMÕES et al., 2006).

A navegação robótica torna-se um obstáculo encontrado no desenvolvimento da robótica móvel. Inúmeros fatores podem torná-la mais complicada uma vez que é necessária a leitura e a interpretação do ambiente para que as decisões sejam tomadas, visando permitir ações rápidas que evitem colisões e garantindo que a trajetória seja percorrida com sucesso (FRACASSO et al., 2005).

A percepção territorial realizada pelo robô pode ser feita através de diversos métodos, dependendo do terreno onde o mesmo se encontra. Pode-se utilizar sonares em ambientes em que a informação é pouca ou nenhuma (OTTONI et al., 2003) ou o rastreamento pode ser feito através da visão (MOTTA et al., 2008). As informações captadas passam por um estágio de processamento, onde muitas vezes são filtradas para que sejam interpretadas com maior precisão. A partir daí, os resultados obtidos pela etapa de processamento são usados para realizar a ação do robô, onde os comandos são enviados para os atuadores.

Estudos têm buscado diminuir várias dificuldades encontradas na navegação de um robô (BATISTA et al., 2010). Nosso trabalho tem como objetivo realizar uma simulação de um sistema robótico móvel e nebuloso, o qual será descrito nas seções seguintes, utilizando ferramentas de software livre.

3. Lógica Fuzzy

A lógica fuzzy ou lógica nebulosa é uma forma de realizar a interface entre processos inerentemente analógicos, que se movem através de uma faixa contínua de valores, para o universo digital, onde os valores são definidos como discretos. Foi inicialmente proposta por Lotfi A. Zadeh (PERRY, 1995) na Universidade da Califórnia em Berkeley em um artigo datado de 1965.

As implementações da lógica nebulosa permitem que estados indeterminados possam ser tratados por dispositivos de controle. Desse modo, é possível avaliar conceitos não quantificáveis. A lógica fuzzy deve ser vista mais como uma área de pesquisa sobre tratamento da incerteza, ou uma família de modelos matemáticos dedicados ao tratamento da incerteza, do que uma lógica propriamente dita. A lógica nebulosa normalmente está associada ao uso da teoria de conjuntos fuzzy.

A lógica fuzzy pode ser empregada no ramo industrial, possibilitando automatizar diversas tarefas. Tal fato pode encorajar a utilização da lógica fuzzy na robótica móvel, possibilitando desta forma a navegação robótica de uma maneira mais simplificada. Alguns trabalhos que seguem tal linha de pesquisa podem ser encontrados em Joshi e Zaveri (2009) e Raguraman et. al (2009), por exemplo. A lógica fuzzy também pode ser aplicada em outras funcionalidades existentes no robô.

Em um sistema de controle fuzzy, possuímos variáveis de entrada que representam os valores que podem ser obtidos através de sensores. Tais valores podem ser categorizados em faixas: muito longe, longe, normal, perto, muito perto. Esses estados são conhecidos como estados fuzzy e não possuem um limiar definido de um para outro. As variáveis de entrada podem pertencer a vários estados com diferentes níveis de pertinência. A Figura 2 apresenta um exemplo de funções de pertinência de uma variável fuzzy.

Figura 2 – Note que a um dado instante, a distância será um grau de pertinência com respeito a dois conjuntos fuzzy: 0.3 Muito Longe e 0.7 Longe, 0.4 Normal e 0.6 Perto, assim por diante.

Os valores de entrada, conhecidos como crisp, são convertidos para valores fuzzy em um processo conhecido como “fuzzificação”, utilizando as funções de pertinência dos termos fuzzy de entrada. O grau de participação de uma grandeza de entrada é dado em função dos termos primários definidos como o “Universo do Discurso” de entrada. Assim, cada valor de entrada tem um grau de pertinência para cada termo primário definido. A arquitetura fuzzy pode ser observada na Figura 3.

Dados “mapeamentos” das variáveis de entrada para as funções de pertinência e valores verdade, um micro-controlador pode então tomar decisões sobre a ação a ser executada baseada em um conjunto de regras, da forma:

“Se a distância frontal é muito perto e a velocidade é muito rápida então gire acentuadamente à esquerda”

É possível perceber que, neste exemplo, a variável de saída é também definida como um conjunto fuzzy que pode assumir os valores como “acentuadamente à esquerda”, “levemente à direita” e assim por diante. Existe uma ampla gama de funções que podem ser utilizadas, como: NÃO-fuzzy, E-fuzzy e OU-fuzzy.

Figura 3 – Arquitetura de um controlador fuzzy.

Os valores obtidos por todas as regras de inferência que foram acionadas são “defuzzificados” para valores exatos por meio de um dentre vários métodos possíveis. Por exemplo, o método do centróide retorna o centro de massa do resultado como valor exato. Por sua vez, o método da altura retorna o maior valor. A Figura 4 apresenta um exemplo de um sistema de inferência nebuloso que utiliza o método do centróide para realizar a defuzzificação.

Figura 4 – Exemplo de ativação das regras em um sistema de inferência nebuloso e o processo de defuzzificação pelo cálculo do centroide.

 4. Ferramentas de software livre

Esta seção apresenta as ferramentas de software livre utilizadas para simular o sistema nebuloso de navegação proposto neste trabalho.

4.1 Simulador Simbad

O Simbad é um simulador de sistemas robóticos utilizado para fins científicos e educacionais. Esta ferramenta é principalmente dedicada a pesquisadores/programadores que querem uma base simples para estudar Inteligência Computacional (IC), aprendizado de máquina e outros algoritmos IC no contexto da robótica autônoma e agentes autônomos. O projeto Simbad está hospedado no SourceForge, este projeto é livre para ser usado e modificado sob as condições da Licença Pública Geral GNU.

O emprego de um simulador de sistemas robóticos traz inúmeras vantagens. Uma destas vantagens é a sua utilização no desenvolvimento da programação offline (programas elaborados em um computador e carregados posteriormente no robô, possibilitando que o mesmo não seja retirado das funções de produção e ocupado com a tarefa de programação), permitindo que sejam feitos testes dos programas antes de executá-los no robô real (REDEL e HOUNSELL, 2004). Outra vantagem é a possibilidade de seu uso para o ensino, pois permite que cada aluno se familiarize com o robô de forma individual, mesmo sem a existência física do mesmo, fazendo com que estes alunos adquiram os conhecimentos básicos necessários antes de utilizarem o robô real.

O simulador Simbad possui sensores de visão, sensores de alcance (com sonares e infravermelho) e sensores de contato. O uso destes sensores permite a interação do robô com o ambiente que o rodeia de uma forma flexível. Existem vários tipos de sensores e cada um se adapta a uma função específica. Estes são adicionados no sentido anti-horário em cada robô e retornam o alcance, o ângulo e informam se houve colisão.

O Simbad possui uma interface que permite a manipulação e a visualização dos eventos da simulação. Durante a execução do programa, aparecerá uma janela dividida em três setores, como mostra a Figura 5. A janela World exibe o mundo da simulação descrito pelo usuário ou algum dos exemplos presentes no Simbad. Na parte lateral situada à esquerda são exibidas as informações do robô e de seus acessórios, como o nome do robô, alcance dos sensores, velocidade translacional e rotacional, visão da câmera, colisão, tempo de vida do robô, entre outras, que podem variar de acordo com o projeto. A terceira janela é a Control, esta é dividida em três abas. As abas View From e a Follow são responsáveis pela visualização da simulação. A aba Simulator permite rodar, pausar, reiniciar ou passar cada etapa da simulação manualmente, além de alterar a velocidade da simulação na opção Time Factor.

Figura 5 – Visão geral do simulador Simbad.

4.2 jFuzzyLogic

O jFuzzyLogic é um pacote de lógica fuzzy escrito em Java, disponível pela licença “LGPLv3″, este pacote implementa uma Linguagem de Controle Fuzzy (FCL). A FCL é um padrão para a programação de Controle Difuso, publicado pela Comissão Electrotécnica Internacional (IEC). As especificações para a sintaxe FCL podem ser encontradas no documento IEC 61131-7. Esta linguagem é uma linguagem de programação de domínio específico, ou seja, possui características diretamente relacionadas com a lógica fuzzy. Dessa forma, o FCL permite ao programador especificar conjuntos fuzzy, que são listas de pontos em um gráfico, bem como o conjunto de regras do sistema de inferência e o método de defuzzificação.

5. Sistema Robótico móvel e nebuloso

O sistema robótico móvel e nebuloso proposto neste trabalho objetiva controlar os movimentos do agente robótico de forma que este seja capaz de alcançar uma sequência especificada de coordenadas no ambiente, ao mesmo tempo em que desvia dos obstáculos. Neste modelo, o agente robótico é ciente de sua localização no ambiente, bem como das coordenadas que devem ser alcançadas para completar sua trajetória.

Figura 6 – Módulo de navegação e diferença de direção, adaptado de Fracasso (2005).

A postura do robô é determinada pela sua orientação no ambiente (x, z, ξ), na qual x e z representam suas coordenadas no plano bi-dimensional e o ângulo ξ representa a direção do seu movimento. Durante a navegação, a postura atual, a próxima postura e o ângulo atual são utilizados para calcular o ângulo de rotação necessário para o robô alcançar o objetivo, como ilustrado na Figura 6. Os sonares frontais indicam a distância dos obstáculos que possam existir no caminho. O controlador nebuloso utiliza as informações sobre a diferença angular das posturas e da distância dos obstáculos para definir o ângulo de rotação. A velocidade de translação do robô é mantida fixa para simplificar a modelagem.

5.1 Variáveis linguísticas

Neste sistema nebuloso, são utilizadas três variáveis linguísticas de entrada. As variáveis esquerda e direita indicam a distância dos obstáculos obtida pela leitura dos pares de sonares existentes. A última variável linguística é o ânguloє1, queé obtida pela diferença dos ângulos de orientação das posturas inicial e final. Além disso, existe apenas uma variável linguística de saída: o ângulo de rotaçãoє2.

As funções de pertinência das variáveis linguísticas são apresentadas na Figura 7. Pode-se observar que o universo do discurso dos sonares varia de 0 à 1.5m, com os valores linguísticos: Perto e Longe, simplificando o projeto para que o robô apenas evite as colisões. Por outro lado, o universo do discurso dos ângulos de entrada є1 e de saída є2 varia de -30º à +30º, ambos possuem doze variáveis linguísticas, Ângulo Muito Pequeno (AMP), Ângulo Pequeno (AP), Ângulo Médio (AM), Ângulo Médio Zero (AMZ), Ângulo Grande (AG), Ângulo Muito Grande (AMG), que podem ser positivos ou negativos.

Figura 7 – Funções de pertinência das variáveis de entrada: direita/esquerda e ângulo. A função de pertinência para o ângulo de saída é a mesma da função que representa o ângulo de entrada.

5.2 Regras, sistema de inferência e defuzzificação

As regras de inferência são colocadas no arquivo navigation.fcl, tendo um objetivo com duas premissas: fazer o robô desviar dos obstáculos, se os mesmos estiverem próximos, ou fazer simplesmente o robô continuar a sua trajetória quando o caminho está livre. A Figura 8 apresenta algumas das regras utilizadas. O sistema utilizado foi o método dos mínimos de Mamdani. No processo de defuzzificação, os valores obtidos pelas regras acionadas foram defuzzificados através do método de máximo mais à esquerda.

Figura 8 – Exemplo de algumas regras utilizadas na simulação.

6. Resultados

Após a implementação dos sistemas de fuzzificação, motor de inferência e defuzzificação, bem como a implantação do conjunto de regras elaboradas, iniciou-se a etapa de simulação. O código-fonte do simulador Simbad foi modificado para que a rota realizada pelo robô seja exibida em tempo de simulação. Possibilitando, dessa forma, a visualização do percurso realizado.

A avaliação do sistema proposto utiliza dois ambientes de simulação. Nos quais foram criados obstáculos no intuito de bloquear a trajetória do robô através das coordenadas inseridas, representadas pelas esferas vermelhas no cenário, testando assim, a lógica nebulosa para desvio de obstáculos. Para o primeiro ambiente, foi modelado um cenário simples, com dois obstáculos do tipo parede, o qual é ilustrado na Figura 9. Através da utilização da lógica fuzzy, a navegação do robô foi realizada com êxito. A Figura 9 demonstra também como o robô consegue seguir as coordenadas estipuladas e, ao mesmo tempo, desviar dos obstáculos dispostos no ambiente.

Figura 9 – Rota realizada pelo robô antes e após a simulação.

Em uma segunda simulação, foi utilizado um ambiente com mais obstáculos. A Figura 10 demonstra o ambiente antes do início da simulação e o percurso realizado pelo robô com tais obstáculos. Durante essa simulação, o robô consegue novamente percorrer com êxito as coordenadas definidas.

Figura 10 – Rota realizada pelo robô em um segundo ambiente de simulação.

Como foi visto, a lógica nebulosa para o desvio de obstáculos funcionou perfeitamente para os dois ambientes de simulação propostos. O robô apresentou como saída os movimentos giratórios para esquerda ou direita, fazendo com que o mesmo consiga evitar as colisões validando, dessa forma, o sistema fuzzy proposto.

7. Considerações finais

Este artigo apresenta o modelo e a simulação de um sistema robótico móvel e nebuloso baseado nas ferramentas de software livre: Simbad e jFuzzyLogic. Os resultados demonstram que o agente robótico consegue não só desviar dos obstáculos, mas percorrer a trajetória designada nos dois ambientes de simulação propostos. Contudo, o modelo apresentado não é capaz de percorrer trajetos em um ambiente mais complexo e com muitos obstáculos, nesse caso é necessário modificar as regras e tornar o sistema mais robusto. Assim, surgem duas motivações principais para um futuro trabalho: adicionar e melhorar as regras existentes, com o objetivo de deixar o sistema mais tolerante a falhas, e realizar a implementação desse projeto em um ambiente com elementos reais.

Referências

BATISTA, I. J. L. et al. Navegação de Robôs Móveis com Ênfase em Planejamento e Supervisão de Trajetórias. In: XVIII Congresso Brasileiro de Automática, 1., 2010, Bonito. Anais… Bonito: UNESP-MS. 1 CD-ROM.
CINGOLANI, P. jFuzzyLogic. Disponível em: <http://jFuzzyLogic.sourceforge.net> Acesso em: 20 jul. 2011.
FILHO, F. A. R. et al. Development of Robots for the Pipeline Industry… 2010.Trabalhoapresentadoao41st International Symposium (ISR) on and 2010 6th German Conference on Robotics (ROBOTIK), Munique, 2010.
FRACASSO, P. T.; REALI COSTA, A. H. Navegação reativa de robôs móveis autônomos utilizando lógica nebulosa com regras ponderadas. In: IEEE LATIN-AMERICAN ROBOTICS SYMPOSIUM. São Luis, MA, 2005. SBAI IEEE LARS. São Luis: IEEE, 2005. pp. 1-7.
FUZZY INFERENCE SYSTEMS. Disponível em: <http://www.mathworks.com/help/toolbox/fuzzy/fp351dup8.html>. Acessado em: 21 jul. 2011.
GOEBEL, G. A Introduction To Fuzzy Control Systems. Disponível em: <http://www.faqs.org/docs/fuzzy/> Acesso em: 19 jul. 2011.
HIRZINGER, G. et al. ROTEX-the first remotely controlled robot in space.In: Proc. IEEE Conf. on Robotics and Automation. Anais Proceedings San Diego: IEEE, 1994. pp. 2604-2611.
HUGUES, L.; BREDECHE, N. Simbad: An Autonomous Robot Simulation Package for Education and Research. In: Proceedings of SAB’2006. pp.831~842
JOSHI, M.M.; ZAVERI, M.A.; Fuzzy Based Autonomous Robot Navigation System. Proceedings of the India Conference (INDICON), 2009 Annual IEEE, ISBN: 978-1-4244-4858-6, DOI: 10.1109/INDCON.2009.5409419, pp. 1-4, Gujarat, India, 18-20 Dec. 2009.
MOTTA, J. M. S. T.; TOURINO, S. R. G. Sistema de Rastreamento por Visão em Robôs Móveis com Otimização por Projeto Fatorial. Revista Iberoamericana de Ingeniería Mecánica. Vol. 12, N° 1, pp. 25-34, jan. 2008.
OTTONI, G. L.; LAGES, W. F. Navegação de robôs móveis em ambientes desconhecidos utilizando sonares de ultra-som. Sba Controle & Automação [online]. 2003, vol.14, n.4, pp. 402-411.
PERRY, T.S. Lotfi A. Zadeh [fuzzy logic inventor biography]. Ieee Spectrum. Disponível em: <http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=387136> Acesso em: 21 jul. 2011.
PREISING, B.; HSIA, T. C.; MITTELSTADT, B. A literature review: robots in medicine. IEEE Engineering in Medicine and Biology Magazine. Vol. 10, N° 2, pp. 13-22, jun. 1991.
REDEL, R.; HOUNSELL, M.S. Implementação de Simuladores de Robôs com o Uso da Tecnologia de Realidade Virtual. In: IV Congresso Brasileiro de Computação, Itajaí – SC. IVCBCOMP, v. 1, 2004, pp. 398-401.
RAGURAMAN, S.M.; TAMILSELVI, D.; SHIVAKUMAR, N. Mobile robot navigation using Fuzzy logic controller. In: International Conference on Control, Automation, Communication and Energy Conservation, Perundurai – 638052, Erode, Tamilnadu, Índia – INCACEC 2009. pp. 1-5.
SIMBAD PROJECT HOME. Disponível em: <http://simbad.sourceforge.net/> Acesso em: 21 jun. 2011.
SIMÕES, A. S.; MARTINS, A. C. G.; CARRION, R. Robôs móveis autônomos na missão marte: projetando um sistema reativo com transição sequencial de comportamentos. In: Anais do XXVI Congresso da Sociedade Brasileira de Computação (SBC). ENRI’06: Encontro de Robótica Inteligente. Campo Grande, 17-20 de julho de 2006.
SOLIS, J.; TAKANISHI, A. Practical Issues on Robotic Education and Challenges Towards RoboEthics Education. In: 18th IEEE International Symposium on Robot and Human Interactive Communication, 3., 2009, Toyama. IEEE Press, 2009 pp. 561-565.
STALLMAN, R. Open Source: Voices from the Open Source Revolution. 1. ed. Sebastopol: O’Reilly & Associates. 1999.

Autores

Jardel Rodrigues <jardel.ifce@gmail.com> – Aluno de graduação em Ciência da Computação, IFCE Campus Maracanaú.

Leandro Bezerra <leandrobezerramarinho@gmail.com> – Aluno de graduação em Ciência da Computação, IFCE Campus Maracanaú.

MSc. Otávio A. de Lima Jr. <otavio@ifce.edu.br> – Professor, IFCE Campus Maracanaú.

O  aspecto mais desconsiderado foi a falta de capacitores de bypass. Então, após ler um artigo sobre a Lei de Murphy que referenciava um outro application note da Maxim, eu decidi escrever um pouco sobre capacitores de desacoplamento e bypass.

Como uma pessoa que pode ser considerada velha neste trabalho, eu já experimentei os problemas da ausência de desacoplamento em primera mão. Meu primeiro projeto em alta velocidade foi como aprendiz em meados dos anos oitenta em uma grande empresa de eletrônica. O projeto que eu estava construindo, um medidor de frequência digital, usava portas lógicas 74Fxx a uma velocidade de 11MHz (que era muito rápido para a época). Ele estava feito em “wire-up” em uma placa do tamanho de uma placa euro-card dupla e usava em torno de 40 CIs. Quando chegou a hora de ligar, eu notei que ele não funcionava como o esperado e todo o tipo de coisa apareceu em todos os lugares. Depois de verificar a montagem várias vezes eu conversei com o meu supervisor sobre o problema e ele me disse: “Não existem capacitores de bypass; monte-os em todos os chips, junto à alimentação, e nós conversaremos novamente”. Completamente desorientado eu fiz o que ele disse e, como um milagre, tudo simplesmente funcionou. Porque a aparente inerte capacitância da fonte de alimentação não faz as coisas simplesmente funcionarem?

Meu supervirsor então me falou sobre correntes de chaveamento/surto, indutância dos fios e sobre o conto do desacoplamento. Eu admito que somente alguns anos depois eu realmente entendi o que ele falava, mas a lição estava aprendida: sempre coloque capacitores na alimentação de CIs lógicos.

Os termos “capacitor de bypass” e “desacoplamento” não são simplesmente palavras aleatórias, elas possuem um significado específico neste contexto:
- desacoplamento (decoupling): o ato de separar (parcialmente) a fonte de energia do CI da fonte principal de alimentação.
- capacitor de bypass: o capacitor montado desta forma atua como bypass da fonte principal de alimentação e funciona (temporariamente) como uma fonte de energia local.

Mas porque isso é tão importante? Bom, deixe-me te mostrar uma imagem:

Figura 1: Ausência de capacitor de bypass

Isso parece com algum sinal digital? Isso é o que você tem sem capacitores de bypass.

Por favor atente ao fato que a frequência principal de operação é irrelevante. O problema são as bordas de subida e descida das saídas. Então sistemas com o clock 1Hz, 20kHz ou 50MHz necessitam das mesmas considerações. O uso das frequências nos exemplos abaixo foi escolhida apenas para tornar fácil a visualização no osciloscópio.
Deve-se destacar que projetos com alta frequência irão falhar mais rápido porque o número de transições é significamente maior que em projetos de baixa frequência. No entanto, isto não significa que projetos de baixa frequência são imunes. Longe disso, eles falham tão facilmente quanto Murphy nos ensinou. Há… você imaginou agora aquele seu pequeno microcontrolador rodando a 16Mhz ou talvez aquele controlador de LEDs, usado para o show de luzes?

Medindo correntes de surto

Para ver o que está acontecendo nós precisamos medir a corrente que flui. Um circuito de teste simples foi criado para ilustrar.

Figura 2: Circuito Inversor

Figura 3: Medição de Corrente

Um gerador de pulso é conectado a um inversor 74HC04 e um capacitor de 10pF de capacitância é colocado como carga. A saída, TP1, é mostrada no traço superior do osciloscópio. A fonte de alimentação é conectada nos pinos 14 e 7 com um resistor de 10 ohm para o GND. A corrente de alimentação do 74HC04 é medida em TP2 e visualizada no traço inferior do osciloscópio. O capacitor de bypass é montado e desmontado como indicado no texto.

As pontas do osciloscópio usadas são do tipo 1:10, então todos os valores no eixo Y da imagem do osciloscópio devem ser multiplicados por um fator de 10. Todos os pinos não utilizados do 74HC04 são conectados ao GND. A configuração se parece com isso:

Figura 4: Montagem na breadboard

A Figura 5 ilustra o problema em baixas e altas frequências de entrada. As imagens da esquerda são sem os capacitores e os da direita são com os capacitores montados:

Figura 5: Saída e corrente sem (esquerda) e com (direita) capacitores de bypass

Algumas observações sobre a figura 5:

- A corrente medida é somente a que flui entrando e saindo através do GND da fonte de alimentação e o pino do 74HC04 e pelo capacitor de bypass, quando montado. Isto não representa toda a corrente que entra e sai da saída do inversor. É difícil medir correntes que fluem nos dois sentidos pelo Vcc e GND simultanetamente (com o osciloscópio no modo DC). No entanto, a corrente de GND é suficiente para ilustrar o problema do circuito.

- “Ruído” de alta frequência no nível alto da saída. Esta “oscilação” é de mais de 2V pico-a-pico e supera a fonte de alimentação (5V) significativamente. Adicionando os capacitores de bypass esta “oscilação” é reduzida a um nível virtualmente inexistente. Ainda existe este overshoot, mas ele é suprimido muito mais eficientemente.

- “Spikes” (picos) de corrente nas transições. Adicionar um capacitor de bypass reduz os spikes e torna-os simétricos nas transições de subida e descida. Os picos de corrente vão de -22 a +45mA sem o capacitor de bypass e de -32 a +36mA com o capacitor.

- A simetria da corrente nas imagens com o capacitor de bypass montado mostra que a energia é tando recuperada como armazenada. Isso é um fator muito importante.

- O ruído residual de altíssima frequência depende bastante da posição das ponteiras (não mostradas), o que indica que existem significativas antenas de RF no circuito (circuitos LC indesejados). O layout da breadboard (matriz de contatos) e a posição dos fios de conexão possuem impacto significativo na amplitude e frequência. Isso não pode ser eliminado mas pode ser bastante reduzido em um bom layout de PCI (placa de circuito impresso).

Olhando as transições em mais detalhes:

Figura 6: Detalhes da borda de saída e da corrente sem (esquerda) e com (direita) o capacitor de bypass

As correntes que fluem

O 74HC04 é um projeto de chip totalmente CMOS. Isso significa que a corrente estática drenada é próxima de zero. A corrente é desenhada nas transições de alto para baixo e de baixo para alto. Nas transições é que todas as cargas, parasitas ou não, precisam ser (des)carregadas. O circuito de teste da figura 2 possui um capacitor de 10pF como carga. O pino – e sua capacitância devem ser adicionadas, o que nós dá algo na ordem de 5pF+2pF. A ponteira do osciloscópio também possui sua capacitância, que adiciona outros 10pF. A capacitância total da carga na saída é, então, da ordem de 27pF.
Considerando somente essa capacitância de saída, nós estamos (des)carregando a carga com 5V a cada 4,3ns. Se assumirmos a medida da corrente constante (tornando os cálculos mais fáceis) nós podemos estimar a corrente através dos parâmetros acima, utilizando a equação da carga:

Q = I • t  =  C • U I = 5 • 27 • 10 -12 4.3 • 10 -9 ≅ 31.4mA

Isto significa que uma enorme corrente está fluindo em ambas direções para equilibrar a corrente em todas as direções. De onde vem todo este poder? Bom, da fonte de alimentação. Isso pode ser visto claramente na figura 6, onde temos que a corrente não é instantânea; ela acumula-se a um nível específico e depois cai de novo. Este comportamento indica claramente um elemento indutivo.

Isto pode ser visto melhor nas duas imagens da direita na figura 6 (com o capacitor de bypass), quando a corrente (o traço inferior) dá um pico no momento que a saída (traço superior) vai a zero. A corrente então cai, derrubando a saída com ela.

A corrente calculada comparada com as medições estão bem compatíveis, considerando que o nosso cálculo foi uma simples estimativa.

Então, para que o capacitor de bypass?

Dê outra olhada de perto nas duas imagens inferiores da figura 6. A esquerda não atinge o nível dos 5V na saída por algum tempo, enquanto a da direita não tem nenhum problema neste aspecto. Não há energia suficiente sem o capacitor de bypass para suportar a borda de subida e ela trava em 4V por algum tempo. Adicionar o capacitor de bypass supre o 74HC04 com potência instantânea neste período.

O capacitor de bypass é cerca de 4000 vezes maior que a capacitância da carga, o que significa que a queda de tensão esperada é cerca de 4000 vezes menor (na faixa de 1 a 2mV) para dar suporte à transição.

Quando a transição é no sentido contrário, como na parte superior das duas imagens da figura 6, então o capacitor de bypass funciona como um reservatório para receber a energia liberada. A capacitância da carga precisa ser descarregada e então a corrente quer fluir para o GND. No entanto, a energia não pode se mover facilmente para a fonte de alimentação principal e então o capacitor armazena-a temporariamente.

Fonte de alimentação sem potência

A fonte de alimentação principal não pode prover o chip lógico com toda a energia necessária por causa da indutância. Todo fio possui indutância (parasita) e isso dificulta as variações de corrente. A equação básica na eletrônica para indutância é:

 U = L dI dt ⇒ dI = U • dt L

A partir desta equação pode ser visualizado que a mudança na corrente dI é inversamente proporcional a L (indutância). Em outras palavras, quando a indutância aumenta torna-se mais difícil alterar a corrente em determinado período de tempo, se todos os outros parâmetros permanecerem os mesmos. Além disso, uma mudança na corrente atual significa que há uma queda de tensão sobre a indutância. Um fio longo (ou uma trilha na PCI) tem indutância maior e, portanto, atua contra as mudanças rápidas de corrente provocando uma queda de tensão grande.
O capacitor de bypass é uma fonte local de energia. Ele precisa ser montado bem perto dos pinos de alimentação do CI, reduzindo assim a indutância entre o CI e o capacitor ao mínimo. Esta configuração desacopla a fonte principal do fornecimento de energia do chip.

Stress no inversor

Existem seis inversores no encapsulamento, então o circuito de teste foi modificado para consumir mais corrente:

Figura 7: Circuito de teste com carga adicional

Figura 8: Alta carga na saída e corrente sem (esquerda) e com (direita) o capacitor de bypass; note a mudança na escala da corrente

A corrente no pino de GND agora atinge pico de cerca de 70mA quando o capacitor de bypass não está instalado. Uma imagem simétrica é novamente visualizada com o capacitor de bypass instalado, mostrando +/-50mA, dependendo da borda, se subindo ou descendo.
Note que as transições, como mostrado na imagem inferior esquerda da figura 8, são significativamente mais irregulares. O 74HC04 simplesmente não possui energia para suportar a transição. Adicionando o capacitor de bypass (imagem da direita) a transição volta novamente a um nível aceitável.

Figura 9: Detalhe da borda alta com o capacitor de bypass; note a mudança na escala da corrente

O detalhe da borda revela uma alongado consumo de corrente, que é causado por uma demanda de energia muito mais alta. A carga no chip é seis vezes maior (o primeiro inversor tem uma carga 5 vezes ~5pF da capacitância dos inversores secundários).

Este foi só um exemplo com um CI de portas inversoras. Agora, extrapole a idéia para CIs lógicos complexos, que possuem muitas portas internamente com muitas transições. Existem muitas capacitâncias parasitas nas portas que precisam ser (des)carregados toda vez que uma entrada muda. Ou pense sobre microcontroladores, com milhares de portas lógicas lá dentro.

Aterramento

Apartir dessa explanação e visualização dos dados, deve ficar claro que o capacitor de bypass é um elemento importante com uma função bem definida. Ele armazena energia e libera quando necessário, além de recebê-la quando há excesso.

Esta fonte local está sempre sendo suprida pela fonte de alimentação principal através da conexão de Vcc. No entanto, o excesso de energia precisa ser devolvida para a fonte principal através da conexão de GND. Receber esta energia no capacitor de bypass eleva a tensão e, efetivamente, cria temporariamente uma ilha com um potencial diferente. Remover este desequilíbrio é muito importante e isto é feito através das conexões de GND.

Projeto de PCIs (Placas de Circuito Impresso) oferecem planos de aterramento que fazem conexões muito eficientes com a fonte principal. Um bom projeto de plano de GND é essencial para liberar a energia excessiva. Mas seja cauteloso, pois um simples plano de aterramento também pode induzir correntes parasitas (Foucault) e múltiplas conexões ao GND podem introduzir loops.

Sempre é uma boa idéia conversar com aquele experiente amigo projetista de PCIs. A maioria dos erros já foram cometidos e não há necessidade que sejam repetidos por nós ad infinitum.

Bertho Stultiens

Este artigo foi adaptado para o Eletronica.org a partir do original, em inglês, disponível em http://www.vagrearg.org/?p=decoupling, com autorização do autor.

Obra sob Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0)
Você tem a liberdade de:

•     Compartilhar — copiar, distribuir e transmitir a obra.
•     Remixar — criar obras derivadas.
•     fazer uso comercial da obra

Sob as seguintes condições:

•     Atribuição — Você deve creditar a obra da forma especificada pelo autor ou licenciante (mas não de maneira que sugira que estes concedem qualquer aval a você ou ao seu uso da obra).
•     Compartilhamento pela mesma licença — Se você alterar, transformar ou criar em cima desta obra, você poderá distribuir a obra resultante apenas sob a mesma licença, ou sob uma licença similar à presente.

O equipamento vem acondicionado em uma embalagem bem desenhada que traz o manual de instruções em várias linguas (mas não o português), a própria estação de solda, seu ferro com ponta destacável (modelo FM-2028) e suporte para o ferro com sensor de posição. Além disso acompanha uma espuma para água (limpeza da ponta), chave para programação e uma placa de material resiste ao calor para a movimentação das pontas à quente.

Duas características deste equipamento se destacam no dia-a-dia: o ferro de solda extremamente leve e a resistência incorporada à ponta. Estes dois fatores, além das 85  pontas disponibilizadas pela Hakko para este modelo, tornam o conjunto imbatível em qualidade e conforto para a soldagem. O ferro, com a minha ponta  preferida (T2L 0,2mm),  pesa não muito mais que uma caneta “gordinha”  (e isso faz toda a diferença).

O suporte para o ferro de solda é conectado através de um jack simples para determinar se o ferro encontra-se em repouso. Nesta condição a temperatura é alterada, de forma a economizar energia e salvar a ponta de desgaste excessivo em altas temperaturas. Ao contrário do que parece a primeira vista,  isto não dificulta em nada a utilização pois a curva de subida da temperatura é extremamente elevada. O simples tempo de retirar o ferro do suporte e dirigir para o local da soldagem é suficiente para recuperar a temperatura setada digitalmente, com precisão de 1ºC, até o limite de 450ºC. Outro detalhe do suporte é o movimento articular que o coloca em uma posição ideal – e diferente – para colocação e remoção do ferro de solda.

A chave para programação é util para evitar mudanças incorretas nas temperaturas e ajustes do ferro. Quanto este chave (plástica, azul) não está inserida no equipamento a mudança de temperatura fica bloqueada.

Importante ressaltar que praticamente todos os itens, ferro, suporte e pontas, possuem algumas outras versões disponíveis para compras adicionais junto à Hakko, permitindo personalizar a estação para cada nicho específico.

Infelizmente, por tratar-se de um produto importado, o custo não é dos mais baixos aqui no Brasil. Comumente encontra-se em alguns distribuidores nacionais com preços variando entre R$1250,00 e R$1500,00. Por possuir um preço alto, esta estação é indicada para quem a utiliza de forma profissional e frequente, com necessidade de reposição de pontas e extrema precisão na soldagem.

Mais informações sobre este produto podem ser encontradas na página do fabricante.

Por Roberto Alcântara (roberto@eletronica.org)

Antes de tudo eu devo avisar que essa resenha não pertence à série de resenhas que eu vinha fazendo, e que devo continuar em breve, à qual eu dei o nome de “Leitura Obrigatória”.

O livro de hoje é o Programming Embedded Systems, Second Edition. Eu já estou quase terminando a leitura deste livro e já me sinto à vontade para recomendá-lo por aqui porque eu realmente me empolguei com o material.

Como muitos já sabem eu voltei a praticar o antigo hobby de montar dispositivos eletrônicos, e desde que eu havia parado de brincar com essas coisas muita coisa mudou. Hoje em dia é muito comum encontrar microprocessadores e microcontroladores em vários projetos, e trabalhar com esses componentes exige um conhecimento que mora entre a eletrônica “pura” e a informática.

Como eu já tenho bons conhecimentos de informática e meus conhecimentos de eletrônica “pura” estavam evoluindo com a prática do meu antigo hobby, estava faltando construir a ponte que iria unir essas duas áreas do conhecimento.

Na mesma época recebi uma proposta da O’Reilly para fazer resenhas dos livros de Python deles e aproveitei para pedir alguns títulos que tratavam de dispositivos embarcados. Recebi este livro juntamente com outros 3 de Python (aguardem resenhas) e comecei a lê-lo.

O livro tem foco prático como em quase todos os títulos da editora O’Reilly. Os autores realmente irão desenvolver o assunto em cima de uma plataforma real de desenvolvimento que usa um processador ARM XScale e irão conduzir o leitor desde o ponto onde a gente faz um LED piscar até o momento onde desenvolvemos aplicações reais com RTOS e Linux.

O livro fala sobre device drivers, interrupções, registradores, memória e sobre como gerenciar e desenvolver software em C (gcc) para usar todas essas funcionalidades.

Vale destacar que esse livro fica exatamente na fronteira entre um livro de nível básico e um livro avançado, ou seja, se você não entende nada de eletrônica e muito pouco de informática esse livro não irá lhe servir. Se você também já é um especialista no assunto pode achar o livro massante demais na primeira parte que trata de assuntos mais básicos.

O próximo passo agora é adquirir um kit de desenvolvimento parecido com esse que foi proposto no livro e começar a brincar. Eu tenho certeza que eu vou me divertir muito com esse tipo de coisa depois de ler este livro.

Para comprar: Programming Embedded Systems, Second Edition
Por Osvaldo Santana
Veja esta resenha também em www.pythonologia.org

Em seguida o autor dedica capítulos específicos que abordam áreas importantes dos projetos de sistemas embarcados, iniciando com as fontes de alimentação. Baseado na sua própria experiência, algumas dicas básicas sobre redução de ruídos e interferências são mostradas após descrever e exemplificar, através de circuitos, meia dúzia de componentes específicos para a regulação da alimentação, em 5Vcc e em 3.3Vcc.

No sexto capítulo nós temos uma série de dicas sobre ferramentas, soldagem e prototipagem de circuitos impressos para em seguida, no sétimo capítulo, iniciar uma abordagem mais detalhada sobre alguns protocolos de comunicação utilizados como SPI, I2C, portas seriais, IRDA, USB, CAN e Ethernet. Algumas dessas abordagens são mais resumidas que outras, mantendo o foco do autor principalmente nos protocolos que ele posteriormente vem a utilizar quando trata, no capítulo “Analógico”, sobre diversos sensores e circuitos de conversores analógicos digitais. Neste ponto vê-se mais uma vez o uso da experiência do autor ao selecionar sensores que estão presente de forma bastante ativa nos projetos de sistemas embarcados tradicionais.

Os últimos seis capítulos do livro são dedicados aos microcontroladores. Nestas mais de 100 páginas o autor não foca exclusivamente em um fabricante ou arquitetura. Ele prefere abordar  algumas arquiteturas mais utilizadas no mercado para que o estudante possa adquirir uma bagagem de conhecimento que lhe seja útil para escolher o componente que melhor se adequa ao seu projeto. Os microcontroladores citados são os PIC e AVR, contando em seguida com textos sobre o 68HC11, MAXQ, 68k e DSPs. Neste espaço o autor detalha diversos parâmetros envolvidos nos projetos, como temporizações de clock, conexões de barramentos, lógica de decodificação de memórias, entre outros, sempre com a utilização de exemplo de circuitos reais que facilitam a absorção do conteúdo.

Muito dos conceitos descritos no decorrer do livro podem frustrar os mais experientes pela simplicidade, mas a abordagem é ideal para quem está tendo o primeiro contato com este mundo. Vale ressaltar também que, por não ser o foco do livro, muito pouco sobre software é abordado, obrigando os estudantes a procurarem outra referência sobre o tema.  Enfim, Designing Embedded Hardware é um livro ideal para quem está começando no mundo dos projetos de sistemas embarcados, mas não recomendado para usuários que já desenvolveram projetos de médio porte.
Para comprar (30% de desconto para os membros Eletronica.org): Loja Internacional da O’Reilly. Para comprar no Brasil: Livraria Cultura.
Não existe, até o momento, edição em português deste livro.

Elementos matemáticos fundamentais, como raiz quadrada, exponenciais, logarítmos, seno, cosseno, tangente e suas variantes, e os fundamentos do cálculo numérico são revisados teoricamente e analisados através de uma abordagem prática, com exemplos de algorítmos com diferentes estratégias de cálculos, priorizando precisão e velocidade.

Outros temas, como ponto flutuante, constantes, erros, série de Taylor, transformada Z, são tratados em capítulos dedicados ou como subtema em um capítulo maior.

No final do livro, uma pequena biblioteca em C++ com funções estudadas no livro e um CD-ROM contendo as bibliotecas e todos os exemplos utilizados ajudam ainda mais o desenvolvedor em seus estudos.

Enfim, leitura fortemente recomendada se você se encaixa no perfil descrito no início ou se é um entusiasta da área. Como diz o autor, “Se você está procurando um livro sobre os últimos métodos para escrever Applets Java ou aprender como criar seus próprios controles VBx, devolva o livro e pegue o seu dinheiro de volta”.

Infelismente não existe uma versão em português do livro. Dois locais onde você pode encontrá-lo: Livraria Cultura e Amazon.

Por Roberto Alcântara

Os capítulos que tratam da preparação do kernel, das bibliotecas, dos utilitários e dos compiladores são bastante práticos, com uma vasta lista de comandos necessários em cada etapa para construir os binários, o que facilita bastante para os desenvolvedores que não estão habituados com estes procedimentos de compilação. São estes tópicos os mais numerosos, mas sempre que algum detalhe da estrutura do kernel é necessária para o entendimento do texto este é devidamente tratado como, por exemplo, o capítulo sobre dispositivos de armazenamento precedendo a configuração e ajuste do sistema de arquivos.

Em suma, este livro é voltado para o desenvolvedor que pretende conhecer como selecionar, configurar e empacotar um sistema Linux para uma plataforma específica, criando um sistema de arquivos completo voltado para as suas necessidades, fazendo-o iniciar corretamente e depurá-lo. Porém, não é intenção do autor abordar detalhes da estrutura do kernel, teóricas ou práticas, que permitam ao desenvolvedor intervir nas estruturas de baixo nível do sistema para, por exemplo, portar o sistema para uma nova arquitetura. Se este é o seu foco, esta não é a literatura correta, mas se o seu objetivo é condizente com o do livro esta é uma obra bastante recomendada pela riqueza de detalhes e qualidade do texto.

Building Embedded Linux Systems Karim Yaghmour ISBN 0-596-00222-X 416 Páginas – Editora O’Reilly Você pode encontrá-lo na Loja Internacional da O’Reilly (com desconto¹ de 35% para membros do Eletronica.org) e também na Livraria Tempo Real eLivraria Cultura. ¹ Para verificar como proceder clique aqui.

Roberto Alcântara
roberto@eletronica.org

Hoje em dia, o mercado oferece milhares de produtos que contêm um grande conjunto grande de sensores e atuadores, como automóveis, sistemas de segurança ou sistemas de telemetria. Integrar as informações destes sensores e atuadores não é uma tarefa fácil, já que muitas vezes é exigido um meio físico construído com uma fiação enorme, isto sem contar o número de conectores. Ora, fiação enorme implica numa linha de montagem mais cara, complexa e lenta, o que inviabiliza seu uso em larga escala. Para ter-se uma idéia, um carro luxuoso chega a conter 4km de fios, com o custo perto de US$ 300.

Motivados pelas aplicações intraveiculares, várias companhias vêm investindo no projeto de controladores que pudessem gerenciar o tráfego de informações com interfaces através de um meio físico reduzido, possivelmente um barramento serial, porém capaz de possibilitar a multiplexação dessas informações. A esta forma de conexão é dado o nome de “rede intraveicular” (In-Vehicle Networking).

O uso de uma rede intraveicular oferece muitos benefícios, dentre eles:
· requer um número bem menor de fios e conectores, diminuindo custos materiais e de instalação;
· possibilita o compartilhamento de sensores disponíveis na rede em diferentes medidas;
· flexibiliza o projeto, já que um novo sistema pode ser projetado apenas readaptando-se o software de controle.

Visando a uniformizar os projetos de redes intraveiculares, o mercado vem oferecendo diversos padrões, como CAN, SAE, VAN e ABUS, onde os dois primeiros são os mais populares. A SAE definiu três categorias de redes baseada nas aplicações. São elas:

Classe A: engloba aplicações que requerem baixa velocidade de comunicação (até 10Kb/s), como entretenimento, áudio, etc.. Geralmente é implementada com uma UART (Universal Asynchronous Receiver/Transmitter) genérica, como a bem conhecida RS-232.
Classe B: abrange aplicações de média exigência de velocidade (10Kb/s a 125Kb/s), como transmissões broadcast e monitoramento do ambiente (temperatura, pressão, etc.). Um exemplo deste protocolo é o SAE J1850
Classe C: designa aplicações que exigem grande velocidade de comunicação (acima de 125KB/s), como controle de servo-mecanismos em tempo real (suspensão inteligente, controle aerodinâmico, etc.). O protocolo predominante desta classe é o CAN 2.0.

CAN – Controller Area Network

O protocolo CAN foi desenvolvido por Robert Bosch e tem como principal aplicação a implementação de uma rede intraveicular Classe C, particularmente exemplificada na indústria automotiva, que se tem mostrada uma cliente em potencial do CAN. Basicamente, a especificação CAN prevê identificadores de mensagens que facilitam o controle do fluxo de informação pela fiação. Como características de extrema relevância do CAN, podemos citar um controle de alto nível na detecção/correção de erros, grande flexibilidade na topologia e arranjo da rede intraveicular e baixa latência na comunicação entre os componentes. Como exemplo desta última característica, citamos um sistema de prevenção de acidentes que deve monitorar, com baixa latência na aquisição de dados, para processar em tempo real diversas variáveis de diferentes origens, como sensores de posição e radar, potência do motor, poder de frenagem, etc..
Os principais benefícios fornecidos pelo protocolo CAN podem ser resumidos por:
· um padrão de comunicação facilita e torna econômica a tarefa de interfacear sensores e atuadores de diferentes fabricantes;
· o esforço computacional é diluído entre uma CPU principal e um periférico com inteligência de processamento, o que deixa a CPU livre para as tarefas de gerenciamento do sistema;
· com a integração dos componentes através de um barramento único, reduz-se drasticamente a quantidade de fios e, automaticamente, os custos materiais e de montagem da rede embutida;
· por ser um padrão com grande aceitação no mercado, o protocolo CAN incentiva a fabricação de circuitos integrados que irão abastecer a indústria, o que cria a perspectiva de redução de preços devido à concorrência iminente.
A figura 1 ilustra uma típica aplicação do CAN usando um arranjo tradicional de componentes de um automóvel, incluindo o motor, a transmissão e reservatório de combustível. Tal aplicação engloba o controle de direção ou injeção de combustível. Podemos imaginar duas situações. Na primeira, o motor transmite uma mensagem de informação de seu torque que, juntamente com informações de velocidade e aceleração, podem ser usadas pela transmissão para controle da direção. Na segunda, quando o motorista muda de marcha, a transmissão envia uma mensagem para que o motor possa regular a injeção de combustível.

Figura 1: Aplicação típica do protocolo CAN em uma rede embutida num automóvel.

A Intel foi a primeira companhia a implementar o CAN, em 1989, através do controlador 82526 (versão 1.2). O 82527 veio como uma adaptação à revisão 2.0 e, posteriormente, a família 87C196 surgiu permitindo implementações mais sofisticadas.

Controlador CAN 82527 da Intel

O 82527 foi o primeiro controlador da Intel com suporte para o CAN 2.0, sendo fabricado com o processo CHMOS III 5V e estando disponível com encapsulamento PLCC-44. Ele pode ser configurado para interfacear com CPUs usando 8 ou 16 bits de dados, multiplexados ou não com endereços. Possui também uma interface serial flexível, conhecida como SPI, que pode ser muito útil quando se torna dispensável o interfaceamento paralelo. O 82527 usa uma comunicação via mensagens de comprimento 8 bytes, podendo transmitir, receber ou filtrar mensagens de seu interesse, isto graças à utilização de máscaras especiais implementadas em hardware.
O diagrama em blocos do 82527 está resumido na figura 2. Como nela pode ser observado, estão integradas uma CPU com barramentos de dados e endereços de 8 ou 16 bits, uma RAM, duas portas de I/O e uma unidade de interface com o protocolo CAN. Basicamente, vide figura 3, as linhas de dados, endereços e controle fornecem a base mínima para a implementação de um módulo inteligente capaz de executar programas. As portas são responsáveis por receber informações de sensores ou transmitir comandos para atuadores. Finalmente, o controlador CAN permite a comunicação serial em rede, via protocolo CAN 2.0, de vários módulos inteligentes.

Figura 2: Diagrama básico do 82527. 
Figura 3: Exemplo típico de implementação com o 82527.

Alexandre Mendonça (alexmend@aquarius.ime.eb.br) e Ricardo Zelenovsky (zele@leblon.ime.eb.br) são professores do IME, autores dos livros “PC e Periféricos: um Guia Completo de Programação” e “PC: um Guia Prático de Hardware e Interfaceamento – 2a Ed.” (http://www.mzeditora.com.br) e colaboradores da Developers’ Magazine desde 1996.

Nesse conjunto de aplicações, destaca-se um grupo de sistemas que são limitados pelo tempo, os chamados sistemas em tempo-real. Como os sistemas anteriores, esses também realizam tarefas de controle e processamento de informações, mas com um diferencial: suas respostas ao ambiente devem ser retornadas em tempo hábil ou o sistema irá entrar em um estado inconsistente de funcionamento.

Um exemplo comum de sistema em tempo-real é o computador de controle de uma usina nuclear. As tarefas de controle dos processos desse tipo de sistema são extremamente complexas e exigem máxima confiabilidade. As ações realizadas pelo controle devem ser executadas em tempo correto ou um desastre ocorrerá. “Sistemas em tempo-real são aplicados ou estão engajados em atividades do mundo real, as quais são inerentemente complexas” (CARNEIRO, 2001, p.58). Será usado o termo sistema em tempo-real em um sentindo bem amplo, referindo-se ao sistema inteiro, incluindo o ambiente, o software e hardware do computador.

Os sistemas em tempo-real podem ser encontrados em várias outras áreas de aplicação, como:

• Sistemas de navegação para veículos;
• Controle de tráfego aéreo;
• Sistemas de monitoramento de vida;
• Controle de processos industriais;
• Sistemas distribuídos de multimídia.

Neste artigo, serão abordados os principais conceitos dos sistemas em tempo-real: suas características, classificação e principais linguagens de desenvolvimento.

1. CONCEITOS DE TEMPO-REAL

“O funcionamento correto de sistemas em tempo-real depende não somente do resultado lógico da computação, mas também do tempo em que os resultados são produzidos” (STANKOVIC, 1988, p.10).

Um sistema em tempo-real é basicamente composto por um sistema de controle, interfaces de entrada e saída e um ambiente, explicados a seguir:

• Sistema de controle – é responsável por responder aos estímulos do ambiente em tempo hábil. “É dito reativo porque sua tarefa primária é responder ou reagir aos sinais do ambiente” (SHAW, 2001, p.1).
• Interfaces de entrada e saída – são as portas de comunicação entre o sistema de controle e o sistema controlado. Geralmente, são sensores, atuadores, receptores de sinais de rádio, entre outros.
• Sistema controlado – é o ambiente com que o computador interage (cf. STANKOVIC, 1996, p. 206).

Então, sistemas em tempo-real são sistemas computacionais que monitoram, controlam ou respondem a ambientes externos. Além disso, devem cumprir várias restrições de tempo impostas pelo comportamento do sistema externo (cf. SHAW, 2001, p.1).

O fato de fornecerem resposta em tempo hábil requer que os sistemas em tempo-real tenham o comportamento determinístico. Além disso, é necessário que outros aspectos entrem na especificação de projetos em tempo-real. São eles:

• Previsibilidade – em vez de ser rápido (que é um termo relativo), a mais importante propriedade de um sistema em tempo-real deve ser sua previsibilidade, que definese como: seu comportamento funcional e temporal deve ser tão determinístico quanto impõe as especificações do sistema (cf. STANKOVIC, 1988, p.11). 
• Confiabilidade – está relacionada à exatidão no funcionamento do sistema, ou seja, a falha do sistema é que pode gerar uma resposta fora do tempo esperado;
• Desempenho – o sistema deve ser eficiente o suficiente para lidar com a complexidade inerente ao ambiente de comportamento em tempo-real;
• Compactação – geralmente as soluções de sistemas em tempo-real são embarcadas, o que implica recursos reduzidos de processamento, memória e fontes de alimentação.

1.2. Interações entre o Sistema de Controle e o Ambiente

O sistema de controle interage com o ambiente usando as informações disponibilizadas por vários sensores. É imperativo que o estado do ambiente, como percebido pelo sistema de controle, seja consistente como o real estado do ambiente. Então, o monitoramento periódico do ambiente e o processamento temporizado das informações dos sensores são necessários (cf. STANKOVIC, 1996, p. 206).

As restrições de tempo mais comuns para tarefas em sistemas em tempo-real são as periódicas, as aperiódicas e as esporádicas. Segundo STANKOVIC (1996, p. 206), estas são as definições para tarefas em sistemas em tempo-real:

• Tarefa periódica – é uma tarefa que é ativada a cada “T” unidades de tempo. O seu limite de execução para cada ativação pode ser menor, igual ou maior do que o período “T”.
• Tarefa aperiódica – é uma tarefa ativada em períodos indeterminados.
• Tarefa esporádica – é uma tarefa aperiódica com a restrição adicional de possuir um intervalo mínimo entre ativações de tarefas.

Analisando o exemplo dado por LI & YAO (2003, p.11) sobre as interações entre os sistemas de controle e sistemas controlados, vê-se que ele é baseado em um sistema de defesa em tempo-real para navios de guerra. O objetivo do sistema é destruir os projéteis lançados contra a embarcação, antes que eles a atinjam. O sistema é composto por um sistema de radar – que rastreia e procura por alvos em potencial e repassa a localização do alvo ao D&C constantemente – um sistema de Decisão e Comando (D&C) – que deve caracterizar o grau de ameaça, calcular a trajetória a partir das informações do sistema de radar e apontar as armas, através do sistema de controle de armamentos, para a área calculada e as ativar até que o alvo seja eliminado – e um sistema de controle de armamentos. O sistema de controle é o sistema D&C, os sistemas controlados são o sistema de radar e o sistema de controle de armamentos, que são também interfaces com o ambiente externo.

A comunicação entre o sistema de radar e o D&C é aperiódica. Apenas quando um alvo for detectado é que o radar irá passar suas informações para o D&C. Por outro lado, a comunicação entre o sistema de armamentos e o D&C, depois da detecção do alvo, é periódica, visto que o D&C deve constantemente atualizar a posição das armas, em altíssima freqüência.

2.TIPOS DE SISTEMAS EM TEMPO-REAL

Os sistemas em tempo-real podem ser classificados em relação ao cumprimento de seus prazos de resposta ao ambiente, os deadlines. Deadline é o tempo limite que o sistema deve responder e/ou atuar para garantir sua consistência, sendo uma meta que deve ser perseguida e alcançada sempre.

Alguns sistemas são mais tolerantes às perdas de deadlines, ou seja, eles continuam em funcionamento mesmo não retornando suas respostas em tempo correto. É claro que o acúmulo de faltas pode levar o sistema para um estado inconsistente. Geralmente, esses sistemas contam o número de faltas ocorridas e, a partir de certo valor, acionam uma rotina de proteção e/ou correção. “Esses sistemas são chamados de soft real-time, em que a perda ocasional de um deadline é aceitável” (TANENBAUM, 2001, p.19).

Um bom exemplo de sistema em tempo-real soft é um aparelho de DVD. O aparelho de DVD realiza algumas atividades, tais como ler e decodificar o disco DVD, enviar as informações de vídeo e som para as respectivas saídas e receber comandos através do controle remoto. É aceitável que o decodificador perca algum deadline quando o aparelho é submetido a uma rápida série de comandos do usuário. A penalidade é uma momentânea, mas visível, distorção do vídeo ou do áudio.

Por outro lado, existem sistemas que um deadline não alcançado significa grande prejuízo econômico e/ou humano. Esses sistemas são do tipo hard real-time; um sistema de navegação de mísseis teleguiados é um bom exemplo do mesmo. O sistema deve ser constantemente realimentado com novas posições, de modo que possa desviar dos obstáculos ambientais e ainda atingir seu alvo. Caso o comando de reposicionamento não seja processado no tempo desejado, o míssel poderá colidir com uma montanha, ou pior, com habitações civis. “Se a ação deve acontecer absolutamente em um certo momento (ou em certo intervalo), temse um sistema em tempo-real hard ” (TANEBAUM, 2001, p.19).

Não se tem como caracterizar, de modo preciso, um sistema em tempo-real como hard ou soft. A maioria dos sistemas se encontra em algum lugar entre essas duas definições (cf. SHAW, 2001, p.2). Um sistema em tempo-real seria uma composição de tarefas hard e soft.

O projetista deve ter essa idéia bem clara na mente quando for escolher a estratégia de escalonamento e prioridade dos processos do sistema. “Design ar prioridades de tarefas não é um exercício trivial, por causa da complexidade natural dos sistemas em tempo-real” (LABROSSE, 2001, p.73). Uma estratégia mal formulada pode acarretar em perdas contínuas de deadlines.

Por exemplo, o processo que controla os sensores de ambiente, responsáveis por detectar obstáculos, do míssel teleguiado deve ter maior prioridade do que o processo que faz a comunicação com a central base. É fácil perceber o porquê: se a leitura dos sensores é feita de forma “lenta”, o sistema de navegação estará sendo alimentado com dados antigos, o que acarretará em uma possível colisão não desejada. Um atraso na comunicação com a central base não significa um grande prejuízo para o objetivo do sistema, que é atingir o alvo.

3.CARACTERÍSTICAS DE UM SISTEMA EM TEMPO-REAL

Algumas características são inerentes aos sistemas de comportamento em tempo-real, porém nem todos os sistemas em tempo-real irão apresentar todas estas características. A seguir, algumas delas são apresentadas:

• Requisitos de tempo determinísticos – “ deadlines e outras asserções concernentes a tempo são expressas em termos de valores fixos e exatos, ao invés de medidas médias” (SHAW, 2001, pg. 3). O motivo é que variações no tempo de execução das tarefas significam falhas de sistema, principalmente se o sistema for hard.
• Execução Concorrente – Sistemas em tempo-real devem lidar com a concorrência natural das tarefas, que faz parte do mundo externo conectado ao sistema (cf. SHAW, 2001, p. 3). Além disso, a concorrência pode ser usada para aumentar o desempenho do sistema, usando-se processadores em paralelo.
• Confiabilidade e tolerância a faltas – “Confiabilidade pode ser entendida como a probabilidade de um sistema funcionar corretamente em um intervalo de tempo completo, o qual depende da aplicação em questão” (CARNEIRO, 2001, p. 6). Porém, nenhum sistema é perfeitamente confiável e falhas podem ocorrer. “Tolerância a faltas está relacionada com o reconhecimento e gerenciamento das falhas” (SHAW, 2001, p. 3).
• Tamanho e Complexidade – As dificuldades no desenvolvimento de software estão diretamente ligadas ao tamanho e à complexidade de programas. Sistemas em tempo-real são aplicados ou estão engajados em atividades do mundo real, as quais são inerentemente complexas (cf. CARNEIRO, 2001, p. 58). Esta complexidade é passada para o software de controle. Por isso, as linguagens de desenvolvimento para tempo-real devem fornecer facilidades para decompor sistemas complexos em módulos independentes, que são mais facilmente manipulados.
• Manipulação de Números Reais – Diversas atividades de controle industrial fazem uso de controle por realimentação, que manipula dados associados à saída do sistema, realimentado-os à entrada para posterior comparação e geração de um sinal de erro (cf. CARNEIRO, 2001, p. 59). Então, um sistema em tempo-real deve ser hábil a lidar com matemática complexa.

4. LINGUAGENS DE DESENVOLVIMENTO PARA APLICAÇÕES EM TEMPO-REAL

As linguagens serão apresentadas de acordo com suas facilidades para sistemas em tempo-real, não cabendo ao escopo deste trabalho um detalhamento mais profundo.

Real-Time UML

A Linguagem Unificada de Modelagem (UML) é uma linguagem usada para expressar construções e relacionamentos de sistemas complexos. Iniciou como uma resposta do Grupo de Modelagem de Objetos (OMG) a uma requisição de uma linguagem padrão de modelagem orientada a objetos.

Vem sendo usada em projetos de sistemas comercias, distribuídos, web services, dentre outros, com bastante sucesso. A UML possui um mecanismo de extensão da linguagem que permite flexibilizar sua notação para aplicações mais específicas.

A UML é mais completa do que outras linguagens no seu suporte para sistemas complexos e é particularmente preparada para sistemas embarcados em tempo-real (cf. DOUGLASS, 2001, p. 14).

Suas maiores características são:

• Modelo de objetos;
• Casos de uso e cenários;
• Modelagem comportamental com diagramas de estados;
• Empacotamento de vários tipos de entidades;
• Representação de tarefas e sincronização de tarefas;
• Modelos de topologia física;
• Modelos da organização do código fonte;
• Suporte a padrões de projetos orientados a objetos.

No trabalho de SELIC & RUMBAUGH (1998), encontram-se algumas extensões para modelagem de sistemas em tempo-real. O diagrama de estados da UML fornece poderosas ferramentas para o projetista de sistema modelar as restrições de tempo do sistema. E como o diagrama é uma máquina de estados finita, pode-se obter um modelo matemático de fácil comprovação do sistema.

OCCAM

OCCAM é uma linguagem para aplicações científicas e de engenharia, para processos de controle industrial e para sistemas embarcados. OCCAM foi originalmente projetado para transputer (contração entre transistor e computer), uma arquitetura microprocessada, desenvolvida pelo INMOS, que suporta concorrência e sincronização.

A OCCAM possui características especiais para solução de problemas de programação concorrente (cf. CARNEIRO, 2001, p.35) e a semântica formal da linguagem auxilia a transformação e validação dos programas em modelos matemáticos.

Em OCCAM, as partes de um programa são tomadas como processos que executam suas funções e terminam. Pode-se ter mais de um processo sendo executado concorrentemente e processos podem trocar mensagens entre si (cf. CARNEIRO, 2001, p.35).

A comunicação é feita através de um construtor especial da linguagem chamado canal. Um canal é um caminho unidirecional de comunicação entre dois processos concorrentes e é implementado na prática usando regiões alocadas de memória, se os processos estão residentes no mesmo transputer, ou por links de comunicação dos transputers, se os processos comunicantes estiverem em diferentes transputers.

HANDEL C

Handel – C é uma linguagem de programação parecida com C projetada para fornecer compilação de programas em implementações sincrônicas de hardware, geralmente baseadas em FPGA. Desta forma, desenvolvedores de software podem, com uma curva de aprendizagem curta, implementar projetos em hardware.

As implementações em hardware têm como principal vantagem a performance, isto é, é possível se conseguir um paralelismo verdadeiro em um programa escrito em Handel – C. Cada instrução é executada simultaneamente em blocos separados de hardware, a linguagem permite primitivas de sincronização entre blocos paralelos de execução chamadas canais de comunicação (cf. AUBURY et al, 2000, p.11).

Quando um bloco paralelo é encontrado, ocorre uma divisão na execução das instruções e cada novo ramo segue executando simultaneamente. Após o término da execução de cada ramo, o fluxo do programa segue de forma seqüencial. A Figura 1 ilustra a situação. O procedimento de comunicação através de um canal pode ser exemplificado da seguinte maneira: um ramo paralelo libera o dado sobre o canal e o outro ramo lê o dado deste canal; a comunicação através de canais é sincronizada (cf. CARNEIRO, 2001, p. 45). O paralelismo e concorrência são importantes pois os eventos do mundo real podem ocorrer simultaneamente.

ADA

A ADA é uma linguagem desenvolvida pelo Departamento de Defesa Americano com o intuito de prover uma solução robusta para projetos de aplicações críticas. Foi originalmente desenvolvida no início da década de 80 (ADA 83) e então revisada e melhorada para a linguagem ADA 95, que foi a primeira linguagem de programação orientada a objetos padronizada internacionalmente (ISO).

A ADA possui características fortes de modularização que auxiliam na construção de grandes sistemas, fornecendo ainda métodos de encapsulamento de informações. Além disto, a ADA disponibiliza recursos avançados de concorrência: as tarefas ADA podem comunicar entre si implicitamente, através de regiões compartilhadas de memória, ou explicitamente por meio de rendezvous.

O rendezvous em ADA possui as seguintes características: comunicação não armazenada e sincronizada, identificação assimétrica – a tarefa fonte conhece a identidade da tarefa destino, mas o contrário é falso, fluxo de dados bidirecional (cf. CARNEIRO, 2001, p. 36).

Em ADA, as primitivas de comunicação e sincronização são baseadas em passagens de mensagens, todas as ações de processos simples são atômicas, desde que não existam variáveis compartilhadas e o próprio processo não comunique durante a ação. Esta característica é importante para as fases de avaliação e confinamento de danos e recuperação de erros de sistemas tolerantes a faltas (cf. CARNEIRO, 2001, p. 37).

A ADA possui recursos de gerenciamento de tarefas inerentes a sua especificação, as tarefas em ADA possuem prioridades e seguem a política de escalonamento preemptivo, a tarefa em execução cede o direito de execução para a tarefa de maior prioridade e pronta para executar. Segundo ISO (2001), as implementações de ADA tem permissão de definir recursos adicionais e definir políticas de alocação correspondentes a estes. Tais recursos devem ter uma implementação definida na política de despacho de tarefas, que gerencia a alocação de tarefas nas filas de estado de tarefas.

Real-Time JavaTM

A Plataforma Java foi desenvolvida pela Sun Microsystems como uma solução portável, orientada a objetos, distribuída e segura para o desenvolvimento de aplicações comerciais. Devido a sua portabilidade, Java vem sendo utilizada em diversos ambientes, desde aplicações para dispositivos embarcados até aplicações corporativas (cf. GOSLING, 1996).

Os princípios que norteavam o projeto de Java eram discordantes com os requisitos de aplicações em tempo-real. A independência de sistema operacional e hardware implicaram em pouco detalhamento nas questões de comportamento de threads, sincronização, gerenciamento de memória e interrupções, entrada e saída.

Tendo em vista isso, a Java Community Process (JCP), a pedido da IBM, organizou um grupo de experts da indústria da computação para produzir e publicar a Especificação de Java para Tempo-Real (RTSJ). Os trabalhos do grupo foram focados em sete áreas principais: escalonamento de threads, gerenciamento de memória, sincronização e compartilhamento de recursos, gerenciamento de eventos assíncronos, transferência de controle assíncrona, terminação assíncrona de threads e acesso à memória física.

Segue algumas características interessantes de Real-Time Java encontradas em BOLLELA et al (2000): “A RTSJ definiu o conceito de objeto escalonável, que é um objeto que implementa a interface schedulable. A instância do objeto Scheduler é responsável por escalonar os objetos da classe schedulable. Existe espaço na especificação para o usuário definir seus próprios algoritmos de escalonamento, o padrão é o preemptivo com 28 prioridades. O gerente de memória heap de Java, comumente chamado de coletor de lixo, é considerado como um empecilho para a programação em tempo-real devido ao seu comportamento imprevisível. A solução encontrada foi permitir a alocação de memória fora da área de heap do coletor de lixo, isso é conseguido através de áreas de memória que possuem características específicas em relação a duração dos objetos alocados nela. Threads esperando por um recurso são organizadas seguindo a ordem de elegibilidade, ou seja, através da prioridade que foi designada pelo desenvolvedor do sistema. A RTSJ também definiu proteções contra o problema de inversão de prioridades, bastante comum em sistemas em temporeal”.

Referências

AUBURY, Matthew; PAGE, Ian; RANDALL, Geoff; SAUL, Jonathan; WATTS, Robin.
Handel-C Language Reference Guide. Oxford University Computing Laboratory, 1996.

BOLLELA, Greg; BROSGOL, Bem; FURR, Steve; HARDIN, David; DIBBLE, Peter;

GOSLING, James; TURNBULL, Mark. The Real-Time Specification for JavaTM.

Massachussetts: Addison-Wesley, 1 Ed. 2000.

CARNEIRO, P. Régis. Gerenciador de Processos para Aplicações em Tempo-Real: Uma Experiência com Arquitetura DSP (Processador de Sinal Digital), Fortaleza, 2001.

Dissertação de Mestrado em Engenharia Elétrica apresentada ao Departamento de Engenharia Elétrica da Universidade Federal do Ceará.

GOSLING, James; MCGIHON, Henry. The Java Language Enviroment, 1996. Disponível em http://java.sun.com/docs/white/langenv/ .

LABROSSE, Jean j. Embedded Systems Building Blocks. San Francisco: CMP Books, 2. ed. 2002.

LI, Qing; YAO, Caroline. Real-time concepts for Embedded Systems. San Francisco: CMP Books, 1. ed. 2003.

SHAW, Alan C. Real-time Systems and Software. New York: John Wiley & Sons, 1. ed. 2001.

SELIC, Bran; RUMBAUGH, Jim. Using UML for Modeling Complex Real-Time Systems. 1998.

STANKOVIC, John A. Misconceptions About Real-Time Computing. IEEE Computer: out. 1988.

STANKOVIC, John A. Real-Time and Embedded Systems. ACM Computing Surveys. V. 28, n. 1, mar. 1996.
TANENBAUM, Andrew S. Modern Operational Systems. New York: Prentice Hall, 3. Ed. 2000.

Este artigo é uma compilação, efetuada pelo autor, do capítulo 2 do seguinte trabalho: Estudo Comparativo de Kernels de Sistemas Operacionais em Tempo-Real – Fortaleza, 2005. Monografia de graduação do curso Tecnólogo em Telemática apresentada ao Centro Federal de Educação Tecnológica do Ceará.

Otávio Alcântara

Otávio Alcântara é Tecnólogo em Telemática pelo CEFET-CE e especializado em desenvolvimento de software em tempo real para sistemas embarcados.

A importância dessas abordagens pode ser entendida comparando-as a uma campainha. Se uma porta não tiver nenhum dispositivo para chamar a atenção (como uma campainha), é necessário ir até a porta para verificar se não existe ninguém à porta. Com uma campainha, precisa-se ir até a porta apenas quando a campainha toca. Caso tenha-se um mordomo, nem é necessário ir até a porta. Do mesmo modo, não é eficiente esperar que o microprocessador verifique se seus periféricos requerem atenção. Para isto existem as interrupções, que são como campainhas que avisam ao microprocessador que algum dispositivo necessita dele. Assim, o DMA pode ser comparado ao mordomo que vai abrir a porta deixando o microprocessador livre para outras tarefas. Ambas as abordagens têm vantagens e desvantagens, por isso é necessário conhecer-se bem cada uma delas.

1. Introdução

Veja bem: você tem que conectar 6 LEDs mas possui apenas três pinos do microcontrolador disponíveis. Utilizar outro microcontrolador não é sempre uma opção e outros circuitos decodificadores também não.

unsigned char leds;           // Os bits são os estados dos leds
void LEDs_refresh(void)
{
static unsigned char state;   // Taxa de atualização atual
OFF();                      // Coloca todos os pinos em alta impedância (entrada)
switch (state)
{
   default:
      CLR_0();                  // Coloca o pino 0 baixo
        if (leds &  1) {SET_1();} // Coloca o pino 1 alto para o led 1
        if (leds &  2) {SET_2();} // Coloca o pino 2 alto para o led 2
        state=1;                  // próximo estado
       break;
  case 1:
       CLR_1();                  // Coloca o pino 0 baixo
        if (leds &  4) {SET_0();} // Coloca o pino 0 alto para o led 3
        if (leds &  8 ) {SET_2();} // Coloca o pino 2 alto para o led 4
       state=2;                  //próximo estado
       break;
    case 2:
       CLR_2();                  // Coloca o pino 2 em nível baixo
       if (leds & 16) {SET_0();} // Coloca o pino 0 alto para o LED 5
       if (leds & 32) {SET_1();} // Coloca o pino 1 alto para o LED 6
       state=0;                 // Próximo estado
       break;
}//end switch
}
Esta função deve ser chamada com freqüência para evitar deixar visível a piscada dos LEDs. O melhor é utilizar a interrupção do timer.