WirelessBR

5.8: Trabalho de programação

Assim como a implementação física, detalhada no decorrer do trabalho, a implementação do programa do microcontrolador, o firmware, foi realizada em etapas, através de ciclos de projeto, implementação e teste.

Os microcontroladores da família PIC possuem arquitetura RISC (Resumed Instructions Set Computer), o que significa que possuem poucas instruções em assembly para realizar todas as funções de programação.

O lado positivo desta arquitetura é que o custo desse tipo de microcontrolador é menor, e quando se programa em assembly (linguagem de montagem, a mais básica) apenas 35 instruções precisam ser aprendidas. No entanto existe uma grande desvantagem nessa arquitetura, mesmo as mais simples funções precisam ser implementadas pelo programador. Simples laços de repetição, chamadas de rotinas e funções, mudança de banco de memória e operações lógicas têm que ser construídas do zero.

Dedicando muita atenção ao trabalho de programação fica difícil pensar na estrutura global do programa, e uma linguagem de mais alto nível é extremamente necessária. Entre as linguagens disponíveis para microcontroladores de baixa capacidade estão a velha linguagem C, o Pascal, o C++ e a ainda mais velha BASIC. Dentre estas a linguagem C é a mais difundida, por ser uma linguagem de nível médio, ou seja, ainda muito ligada ao hardware, o que é bom quando para programar microcontroladores, ao mesmo tempo em que permite uma adequada estruturação do código.

Por ser padronizada (ANSI-C) e de implementação relativamente fácil, existem muitas opções de compiladores e ambientes de programação para microcontroladores PIC em linguagem C, alguns destes já bastante experimentados e robustos. Após certo tempo dedicado à programação em assembly, para uma boa compreensão do hardware utilizado, decidiu-se utilizar “C” como linguagem de desenvolvimento.

5.8.1: Utilização dos recursos do microcontrolador

O microcontrolador 16F628A foi escolhido pela sua vasta gama de recursos, como timers e comparadores, no entanto a utilização destes não é tão simples quanto o fabricante anuncia. Muitos dos recursos compartilham o mesmo hardware, se tornando excludentes, como o PWM, que quando ativado impede a utilização de um dos timers. Além disso, a seleção, configuração e utilização destes recursos é feita através de 22 registradores de 8 bits, configurados bit a bit.

Só para ligar o microcontrolador e fazer com que um led pisque vários registradores precisam ser iniciados corretamente, e o uso de um compilador C não livra o programador deste trabalho.

O desenvolvimento do TaT tem por objetivo utilizar racionalmente os recursos do microcontrolador, deixando espaço para que aplicações sejam construídas em cima do mesmo. Ponderou-se ao mesmo tempo o quanto aproveitar a capacidade do microcontrolador para reduzir a complexidade e custos de implementação do TaT.

5.8.2: Estruturação do programa

Para realizar a tarefa de programação, vários ambientes de desenvolvimento e diferentes compiladores foram considerados. O escolhido foi o SourceBoost IDE, que já integra o compilador C2C, assim como ferramentas para debug e editor com verificação de sintaxe. Este ambiente facilitou também a estruturação do programa,
tratando projetos como uma entidade composta de vários módulos que se relacionam entre si.

Os módulos foram definidos de forma que cada um realizasse funções afins, e tentando distribuir a complexidade do programa em partes aproximadamente iguais.
Grande esforço também foi desprendido em tornar o posterior desenvolvimento das aplicações independente do núcleo do sistema TaT, permitindo que estas sejam construídas como clientes do sistema, utilizando funções de alto nível que este provê através de uma interface (API – Application Program Interface).

Os módulos que compõe o programa são:

[Módulos omitidos: Produto pronto aguardando patrocínio pra ser lançado no mercado]

A maneira como estes blocos se relacionam, os eventos que os fazem trocar mensagens e a lógica do programa como um todo é muito difícil de descrever, seja com gráficos ou textualmente, uma vez que o sistema TaT juntamente com uma aplicação simples, como as que serão descritas mais à frente, possui aproximadamente 450 linhas de código C, resumido ao máximo por restrições de memória e processamento do microcontrolador.

Ainda assim, o fluxograma a seguir é uma tentativa de descrever o comportamento do sistema na chegada de um bloco de informação, sem incluir o comportamento da aplicação e respostas ao emissor:

[Figura omitida: Produto pronto aguardando patrocínio pra ser lançado no mercado]

Figura 23: Fluxograma lógico de uma recepção de frame

 

5.9: Protocolo de rede

Terminada a construção física do sistema TaT, o trabalho de desenvolvimento passa a ser a implementação do protocolo de rede.

Por protocolo de rede entende-se o algoritmo da camada física juntamente com a camada de enlace do modelo OSI (Open System Interconnect), responsável por montar e desmontar os frames que carregam a informação.

Lembrando que a rede elétrica é uma rede de difusão (todos os dispositivos captam um sinal injetado), o protocolo de rede deve garantir que dispositivos possam ser identificados univocamente, que não ocorram transmissões simultâneas e que haja confiabilidade na transmissão.

Não é uma tarefa simples, ainda mais devido ao fato de que informação pode ser perdida e distorcida no meio do caminho e isso não deve afetar o funcionamento do algoritmo.

5.9.1: Protocolo próprio ou padronizado

Uma solução é adotar um protocolo já existente, de forma que o trabalho se resume ao estudo e implementação deste.

As vantagens desta ação incluem a robustez de um sistema exaustivamente planejado e testado, redução do tempo e esforço de criação do sistema, possível de compatibilidade com dispositivos de outros fabricantes, a existência de uma metodologia eficiente de desenvolvimento de aplicações, a possibilidade de pesquisa com especialistas, melhoria da imagem do produto, etc.

Mas protocolos padronizados são genéricos, ou seja, feitos para atender a uma gama muito ampla de aplicações, e por isso são grandes e complexos, de difícil implementação e possuem desvantagens como a necessidade de adaptar o sistema de transmissão ao protocolo, a falta de suporte a características específicas do
sistema e inflexibilidade (padrões não podem ser alterados). Outras mais indiretas são o preço, em caso de protocolo proprietário, atrelamento a fornecedores e falta de segurança (protocolos abertos).

5.9.1.1: Padrões disponíveis

Existem protocolos de comunicação para todos os gostos, com diferentes níveis de abstração que padronizam desde apenas a comunicação física até às aplicações que vão rodar em cima do sistema.

Na área de transmissão de dados via rede elétrica os principais utilizados são:

•  LonWorks – um sistema operacional completo desenvolvido pela Echelon Corp. que atualmente é um padrão aberto sob a norma EIA 709. É um verdadeiro gigante e sua implementação exige hardware dedicado, construído apenas pela própria Echelon. Suporta taxas de até 2,5Mbps em teoria, mas os produtos atuais (PLT22) só implementam 5kbps.

•  CEBus – (Consumer Electronics Bus) protocolo de rede regulamentado pela EIA 600 (EIA - Electronic Industries Alliance), voltado especificamente para automação residencial, transmissões são feitas a uma taxa real de 7kbps (a taxa nominal é 10kbps, mas inclui paridade e sincronia), atende às regulamentações da América do norte apenas e possui incompatibilidades entre dispositivos de diferentes fabricantes que implementam o protocolo. Criado há 15 anos ainda está em desenvolvimento. [ 7 ]

•  HomePlug – Suporta transmissão de áudio e vídeo (taxas elevadas), mas é um padrão privado da HomePlug Powerline Alliance e apenas seus sócios podem implementa-lo.

•  BACnet® – Desenvolvido pela ASHRAE (American Society of Heating, Refrigerating, and Air-Conditioning Engineers) é um padrão aberto, seu desenvolvimento teve início em 1987 e terminou em 1996. Sua desvantagem é
  que os associados envolvidos direcionaram o mesmo para seus produtos. Sua maior falha foi a tentativa de criar um protocolo de automação predial absoluto, regulamentando as aplicações e não permitindo inovações.

•  X10 – Específico para controle de dispositivos pela rede elétrica, mas somente os emissores de sinal podem ser implementados pelo público geral, os receptores só podem ser produzidos pela própria X10 Ltda., é também unidirecional, e assim sujeito a erros de transmissão, ainda que existam produtos com capacidade bidirecional surgindo. Sua taxa de transmissão é de apenas 120bps (15 bytes p/ segundo).

•  MODBus – Protocolo industrial de pedido/resposta que trabalha através de códigos de função específicos. Utilizando este protocolo, pode-se controlar até 247 dispositivos, e sua simplicidade o fez objeto de estudo deste trabalho, como possível implementação, mas é definido para redes Ethernet e  serial  RS485  apenas. [ 7 ]
  

As vantagens de adotar um protocolo pronto incluem redução de trabalho e tempo de desenvolvimento, compatibilidade com outros fabricantes e maior aceitação de mercado. No entanto, todos os protocolos e padrões estudados, sem exceção, regulamentam a forma de transmissão e também a camada física, e a implementação de qualquer um implicaria em projetar novamente o sistema TaT para atender seus requisitos.

Para não alterar o sistema, os poucos protocolos que não estão atrelados a questões legais por serem privados total ou parcialmente, não seriam plenamente implementados e possuiriam problemas com incompatibilidade e confiabilidade, o que levou à criação de um protocolo próprio.

5.10: Implementação de um protocolo próprio

A implementação de um protocolo próprio tem como vantagem principal a total adaptação deste ao sistema, e outras como independência de padrões, liberdade de
inovação (futuramente) e a possibilidade de encorpar o mesmo à medida que seja necessário, não sendo necessário implementar tudo logo no começo.

O protocolo criado é simples, minimalista, e mesmo suportando o desenvolvimento de aplicações sobre si seu principal objetivo é servir de experiência.

5.10.1: Descrição do protocolo

Suponha que uma mensagem de texto deve ser enviada de um emissor a um destinatário específico. Não basta jogar os bytes correspondentes no meio físico, é necessário algum tipo de protocolo comum a todos os dispositivos que dê sentido à informação. O primeiro passo consiste em injetar na rede uma seqüência de bits que identifique unicamente o destinatário, já que o meio é comum a todos, para que este passe a copiar as informações subseqüentes. Então tem inicio a transmissão de ‘pacotes de informação’ que contém o texto em questão e também informações relativas à detecção de erros (CRCs), ao início e término da transmissão, às ações
de retransmissão frente a erros, à confirmação de recepção e ao controle de quem pode transmitir a cada instante.

Pensando em todas as aplicações de automação residencial em que se deseja utilizar os módulos TaT, que são simples, concluiu-se que os pacotes de informação (frames) teriam um tamanho reduzido, e pensando na dificuldade de implementação e em criar uma comunicação de comportamento previsível, que este tamanho seria
fixo.
Assim cada frame possui seis bytes, sendo o último o verificador de integridade calculado a partir dos primeiros, e o primeiro o número de identificação do dispositivo. Os quatro bytes intermediários correspondem à informação definida pela aplicação, como comandos, requisições, números e mensagens.

O tamanho foi escolhido baseado na premissa de que quase toda a informação trocada entre dispositivos em uma residência, sendo relativa a eventos discretos, caberia em quatro bytes, requerendo o trânsito de um único frame. O byte de identificação garante a identificação única de mais de 250 dispositivos ligados à mesma rede, o número não é exato, pois alguns bytes serão reservados.

O byte de verificação de integridade é calculado através do conhecido algoritmo de detecção de erros chamado Checagem de Redundância Cíclica (CRC) de 8 bits, com polinômio gerador X8+X2+X1+X0. A maneira como este algoritmo funciona e como foi implementado estenderia muito este trabalho, logo basta dizer que ele é capaz de detectar todos os erros de um único bit, todos os erros que afetarem um número impar de bits, todos os erros de rajada (blocos de bits) com menos de 8 bits afetados e a maioria dos erros restantes.

O cálculo e o de CRC, juntamente com uma lógica de retransmissão em caso de detecção de falha garantem a confiabilidade do protocolo. O último requisito é o controle de acesso ao meio, que define o momento em que cada dispositivo pode enviar um frame no intuito de evitar colisão, uma sobreposição de sinais que corrompe os dados. Alguns já foram estudados no decorrer do curso [ 9 ], como Token-Passing e CSMA.

O controle CSMA (Carrier-Sense Multiple Access) é suportado pelo sistema TaT, pois este já verifica a presença de portadora para a recepção, e pode fazê-lo antes da transmissão. Mas o CSMA só é eficiente quando também possui detecção de colisão (CSMA/CD), e o sistema TaT não possui fisicamente essa capacidade.

O protocolo Token-Passing, que consiste em passar a permissão de transmissão de dispositivo a dispositivo é muito lento quando existem vários na rede, já que cada um tem que aguardar a passagem da permissão por todos os outros.

Decidiu-se então deixar para o futuro a implementação de um verdadeiro controle de acesso ao meio, realizando agora apenas um controle simples, baseado na premissa de que em uma rede apenas uma central de controle irá existir. Só a central pode transmitir a qualquer momento, os outros dispositivos limitam-se a responder à central imediatamente após um comando. Como a central só acessa um nó de cada vez, não ocorrem colisões.