MODELAGEM

O objetivo é criar um driver infravermelho para linux, rodando em um processador StrongARM 1110 e fornecer uma abstração orientada a objetos para os desenvolvedores dos protocolos de comunicação.

Para taxas de transmissão baixas, até 115.2 kbps, a operação se dá utilizando transmissão assíncrona de caracteres, com start e stop bits. Neste modo, a camada física opera essencialmente como um modem, convertendo os bits da UART diretamente em pulsos de luz. Neste caso, o protocolo IrLAP incorpora um conjunto de mecanismos que são usados para agrupar os dados em frames para ser usado pelos outros protocolos.

Ao ultrapassar a velocidade de 115.2 kbps, o IrDA incorpora mais mecanismos para prover frames. Entre 115.2 kbps e 1.152 Mbps é utilizado o protocolo HDLC (High-level Data Link Control) e há controle de erro, feito pelo padrão CCITT de 16 bits.

Para taxas de transferência de 4 Mbps, a camada física do IrDA emprega esquemas de codificação mais sofisticados, similares aos conceitos encontrados em equipamentos de LAN. O mais importante é o PPM (Pulse Position Modulation) no qual grupos de pulsos de sinalização são transmitidos para representar 2 bits.

A velocidade máxima que o processador StrongARM AS-1110 suporta é 4Mbps, porém foi definido que a velocidade será de no máximo 115.2 kbps. Portanto poderemos apenas fornecer funções que lêem e escrevem um byte, e o protocolo superior que deverá se encarregar de agrupar os dados em frames para posterior processamento. Forneceremos também funções para configurar a velocidade (entre 9600 bps e 115.2 kbps). Segundo a especificação do processador StrongARM, o formato de transmissão deve produzir 8 bits de dados, 1 start bit, 1 stop bit e sem paridade, como mostrado na figura 1. Logo, estes parâmetros não podem ser configurados pelo usuário. O tipo de modulação utilizado é o padrão Hewlett-Packard Serial Infrared (SIR). Faremos também o controle de fluxo, este que não tem suporte nativo do StrongARM, mas o iPAQ 3600 através de dois Internal GPIOs (General Purpose IO), implementa o CTS (Clear To Send) e o RTS (Request To Send), GPIO25 e GPIO26 respectivamente para o RS-232C. Porém não foi encontrada a documentação confirmando que estes dados são transmitidos pelo infravermelho. Caso o infravermelho não transmita, será necessário implementar o controle de fluxo por software (Xon, Xoff), porém a interface para o usuário será a mesma, ou seja, apenas chamar um método que retorna se é possível ou não continuar a transmição de dados. Para implementar isto a idéia inicial é dividir o byte a ser enviado em dois e enviar pelo infravermelho 4 bits de dados de cada vez, para nos outros 4 bits termos espaço para usar como controle. Mas isto será transparente para o usuário. O hardware possui uma FIFO de 12 entradas para recepção e um registrador de status com um bit que indica quando este buffer está “quase” cheio (Receive FIFO Service Request Flag). Não é possível determinar exatamente quanto é este “quase” (segundo a própria documentação do hardware). Então ao receber um dado verificamos este bit e caso esteja setado, mandamos um comando Xoff para a outra ponta indicando para parar de transmitir. O protocolo superior tem acesso a este dado e sempre antes de enviar um novo dado verifica o status deste atributo. Ao esvaziar o buffer, enviamos um Xon e a comunicação continua normalmente.

Figura 1

A programação de um driver para linux é feita em C, utilizando programação estruturada. Porém é necessário fornecer uma interface orientada a objetos. Faremos uma abstração de Device, conforme figura 2. Na classe IR_Device temos um construtor e um destrutor. Temos também um sendByte e receiveByte que implementam a transmissão e recepção de dados, byte a byte. O método flowControlStatus indica o status do controle de fluxo, ou seja, se o outro lado está ou não aceitando dados (Xon ou Xoff). Os métodos setBaudRate e getBaudRate controlam a velocidade de transmissão. E o método getStatus verifica se os dispositivos infravermelhos estão se comunicando (a princípio pela verificação da portadora do sinal, mas até agora nao foi encontrada documentação sobre isto. Caso nao seja, será necessário um pequeno protocolo para verificar isto). O driver vai possuir um objeto estatico do tipo IR_Device acessivel a quem for usa-lo.

Figura 2