PADRÃO 485

A principal diferença entre RS-485 e RS-232 está no fato do RS-485 ser um padrão diferencial, enquanto que o RS-232 é referenciado ao comum (0V). No RS-232, o nível lógico 1 é interpretado como sendo qualquer tensão no intervalo [–15V;-3V], enquanto que tensões no intervalo [3V;15V] correspondem ao nível lógico 0. Tensões entre -3V e 3V não possuem nível lógico definido. Este tipo de interface é útil em comunicações ponto-a-ponto a baixas velocidades de transmissão. Entretanto, devido à grande faixa de variação dos sinais, faz-se necessário dispor de drivers de alto slewrate para se alcançar altas velocidades de comunicação. No mais, com o aumento do comprimento do cabo de comunicação, o padrão RS-232 se torna altamente susceptível a interferência eletromagnética e a retorno de sinal.

O RS-485 utiliza um princípio diferente. Um transceptor RS-485 traduz um sinal lógico TTL em dois sinais, denominados de A e B (ver Figura 1). O sinal A possui a mesma lógica do sinal TTL, enquanto que o sinal B é complementar. A informação do sinal de entrada está codificada na forma do sinal A-B, ou seja, da diferença entre os sinais A e B. Se esta diferença for superior a 200mV, então tem-se nível lógico 1. Caso a diferença seja inferior a -200mV, então considera-se nível lógico 0. No intervalo de -200mV a 200mV o nível lógico é indefinido, servindo também como meio de detecção de cabo solto, para alguns transceptores comerciais. Entretanto, deve-se ter algum cuidado com relação ao compartilhamento de referência de 0V entre dispositivos .

Uma das vantagens da transmissão diferencial é sua robustez a interferência eletromagnética. A conexão entre dispositivos RS-485 é feita por cabos de par trançado, com resistores de terminação para balanceamento. Dessa forma se um ruído é introduzido na linha, ele é induzido nos dois fios de modo que a diferença entre A e B é quase nula. Outra vantagem da transmissão diferencial é que diferentes potenciais de terra são, até certo ponto, ignorados pelos transmissores e receptores. Isso se torna importante quando tem-se que percorrer grandes distâncias ou mesmo em sistemas com diferentes fontes de alimentação. Cabos trançados com terminações corretas que minimizam reflexão do sinal permitem taxas de transferência de 10Mbps a distâncias de até 1 km.

O RS-485 é um padrão de comunicação multiponto, permitindo-se a conexão de até 32 dispositivos num simples cabo de par trançado. Dependendo do transceptor, pode-se conectar mais de 200 dispositivos, seguindo a topologia mostrada na Figura 2. Na verdade, a Figura 2 mostra a arquitetura mais comum de utilização do RS-485. A letras D e R indicam os drivers de transmissão e recepção de cada dispositivo, respectivamente. Uma observação a ser considerada é a impedância característica do cabo. Se o cabo for utilizado para transmissões com componentes espectrais a altas frequências, podem ocorrer reflexões do sinal em sua extremidade provocando inconsistência nos dados transmitidos. Para minimizar este efeito, deve-se adicionar resistores de terminação de valores iguais à impedância característica do cabo para que ele se comporte como um cabo infinito. Os valores típicos para essa resistência é de cerca de 120 Ω para cabos trançados, e de cerca de 54 Ω para cabos blindados. Apesar de típicos, estes valores podem ser diferentes pois dependem também dos requisitos de carga mínima dos transmissores. É importante também que existam apenas dois resistores, um em cada extremidade, que podem estar também dentro do último dispositivo conectado. Na prática, porém, para pequenas distâncias e baixas velocidades, a terminação não chega a ser algo crucial e a maioria dos circuitos funciona bem. Um outro artifício para minimizar a influência da reflexão dos sinais é por meio da redução forçada da banda passante. Isto já é feito em vários transceptores por meio de uma limitação do slew-rate.

A maioria dos sistemas com RS-485 utiliza uma arquitetura mestre/escravo para comunicação, onde apenas um único dispositivo (geralmente o PC), chamado mestre, envia periodicamente mensagens endereçadas aos escravos. Cada escravo por sua vez tem um único endereço e responde apenas a pacotes endereçados a ele. Além do mais, pode-se usar USARTS half-duplex ou full-duplex, como ilustrado pela Figura 3. Para tanto, as seguintes conexões físicas devem ser feitas:

§  Half-duplex: um único par trançado em que todos os dipositivos estão conectados no mesmo cabo trançado. Dessa forma, todos eles devem possuir transceptores com saídas tri-state, incluindo o mestre. A comunicação se dá em ambas direções e é importante evitar, por software, que mais de um dispositivo tenha o seu driver da transmissão habilitado ao mesmo tempo.

§  Full-duplex: usa-se dois pares trançados em que os escravos transmitem para o mestre através do segundo par trançado. Essa solução geralmente permite comunicação multiponto em sistemas que foram originalmente projetados para RS-232 com pequenas modificações no software mestre. Outro fato é que o mestre também não precisa colocar a saída do seu transceptor em estado de alta impedância.

TRASPECTORES RS-485

É possível encontrar no mercado vários transceptores de RS-485 e até circuitos prontos para determinadas aplicações. No LCVC(LARA) tem-se utilizado os integrados DS485 e ST485, da National Semiconductor e STMicroeletronics, respectivamente. Estes dispositivos são bastante populares devido principalmente ao baixo custo. Entretanto, dispositivos mais caros como o LTC485 (Linear Technology) e o MAX485(Maxim) possuem outras características, tais como maiores taxas de comunicação e número de dispositivos. Estes mesmos fabricantes possuem uma linha mais extensa de dispositivos, com características de full-duplex, opto-isolamento, conversão RS232/485, etc.

A Figura 1 mostra o diagrama dos circuitos integrados DS485 e ST485. A diferença básica entre eles está somente nas suas características elétricas, bem como nas taxas de velocidade máxima: até 2,5 Mbps para o DS485 e até 30 Mbps para o ST485. O pino RE habilita o driver de recepção R, sendo ativo no nível 0. O pino DE habilita o driver de transmissão D (ativo em 1). Normalmente esses dois pinos são conectados juntos de forma que o transceptor esteja apenas recebendo ou transmitindo. Os pinos RO e DI representam saída da recepção e driver de entrada respectivamente, e trabalham com níveis lógicos TTL (0 a 5V). Já as saídas A e B para o barramento operam com tensão diferencial entre seus terminais. O transceptor normalmente é alimentado com 5V CC.

Para que um dispositivo transmita um dado pelo barramento é necessário elevar para 5V o pino DE, fazendo com que RE seja desabilitado, para então transmitir a informação necessária pelo pino DI. Com o final da transmissão, deve-se desabilitar DE e reabilitar RE, de forma que o transceptor volte ao modo de recepção. Esta habilitação pode ser feita via software, controlando pinos de um microcontrolador ou de uma porta de comunicação de um microcomputador; ou mesmo através de um hardware construído especialmente para detectar início de transmissão para o formato de dados utilizado (e.g., UART).

Um problema que pode ocorrer com um barramento RS-485 que dispõe apenas de resistores determinação é que, quando todos os dispositivos estão em modo de recepção, o nível lógico do barramento pode ficar indefinido [2]. Para garantir que o barramento fique sempre em nível lógico 1, que corresponde ao estado default NRZ das USARTs conectadas ao barramento, deve-se adicionar um resistor pull-up ao pino A e um de pull-down no pino B, conforme ilustra a Figura 4. Esses resistores devem ter valores iguais para não alterar o balancemento da linha de transmissão.

UM SIMPLES CONVERSOR RS-232/RS-485 PARA PC

Em muitos casos, em uma rede RS-485, um dos dispositivos da rede pode ser um microcomputador PC. Vários projetos desenvolvidos no LCVC (LARA) fizeram uso de microcomputador PC como mestre do barramento RS-485. As razões para isto vão desde a necessidade de coleta de dados para análise no MATLAB [5] até o controle avançado em tempo real [6]. Para tanto, faz-se necessário dispor de um transceptor RS-232/RS-485, uma vez que as portas seriais de microcomputadores PC usam o padrão físico RS-232, inclusive para controle de fluxo. Este transceptor, cujo esquemático é mostrado na Figura 5, utiliza um circuito integrado DS485 (conversor RS-485/TTL) e um circuito integrado MAX232 (conversor RS-232/TTL). A habilitação de transmissão pelo barramento RS-485 seria feito por meio do sinal RTS da porta serial do PC, também utilizando o MAX232 como interface. Se o microcomputador ficar em uma das extremidades do barramento pode-se incluir, por meio de jumpers, o resistor de terminação, e também, se for o caso, os resistores de pull-up e pull-down. A seção seguinte discutirá um software para realizar esse controle de escrita e leitura no PC em Linux.

PROTOCOLOS E CONFIGURAÇÕES DE SOFTWARE

Pelo fato da grande maioria dos dipositivos possuírem UARTs e quando taxas de até 115200 bps são suficientes para a aplicação em questão, o formato de dados NRZ comum em UARTs é uma boa opção para sincronização de bits, quando da utilização de transmissão assíncrona (ver Figura 6). De acordo com o modelo OSI, este é ainda um aspecto da parte física de uma rede de comunicação, e que ainda não garante a idoneidade dos dados transmitidos. Para tanto, faz-se necessário empregar um protocolo de comunicação. Quando se refere a sistemas embarcados micro controlados, estes protocolos implementam em geral a camada de enlace. Um protocolo bastante empregado na indústria é o MODBUS. No LCVC (LARA), muitos trabalhos são realizados a partir do protocolo descrito em.

Considerações para o projeto de protocolos

Quando deseja implementar seu próprio protocolo, um projetista deve levar em conta alguns aspectos. Na verdade, a definição do protocolo depende fortemente da aplicação. Se for utilizada a arquitetura mestre/escravo, em que cada escravo tem um endereço único e responde apenas a pacotes endereçados a ele, o protocolo torna-se simplificado, visto que elimina a necessidade de algoritmos de detecção de colisão, re-transmissão e algoritmos complicados de controle de acesso ao meio presentes em alguns sistemas distribuídos. Mesmo assim, o formato das mensagens deve levar em conta a aplicação. Por exemplo, se as informações de interesse trafegam no sentido dos escravos para o mestre, o mestre pode apenas enviar um byte contendo o endereço e um comando para o escravo, e este poderá responder com um ou mais bytes. Uma sugestão quando se tem mensagens que variam de tamanho é a utilização de um cabeçalho de um ou dois bytes, por exemplo contendo, além do endereço e um comando, o tamanho da mensagem que está sendo transmitida. Um byte de CRC também pode ser anexado ao final da mensagem como medida da integridade da mensagem. Este é o formato usado no MODBUS.

Algumas precauções devem ser tomadas quando utliza-se a arquitetura mestre/escravo. Se for desejada a propriedade plug-and-play ao sistema, pode ser interessante que o mestre, quando não tiver solicitando informações dos escravos já detectados, possa varrer o barramento enviando mensagens de checagem para detectar (i) a retirada de um dispositivo da rede e (ii) a entrada de um novo dispositivo. Também pode-se definir mensagens de broadcast, para as quais todos os escravos recebem a mesma informação do mestre, que pode ser uma configuração geral ou sincronização de relógios. O mestre também deve sempre esperar a resposta do escravo antes de enviar outro pacote, afim de evitar colisões. O projetista deve também considerar alguma falha que possa ocorrer no sistema, seja na transmissão ou nos dispositivos da rede. Assim o mestre não pode ficar indefinidamente esperando uma resposta de um escravo, nem o escravo do mestre. Se isto ocorrer, tem-se uma situação de bloqueio do sistema. Ao invés disso, deve-se estipular um tempo de espera máximo para chegada de uma mensagem de retorno (se o mestre solicitou uma do escravo) ou de conclusão da mensagem (mestre ou escravo). Este cuidado deve ser levado em conta também caso uma mensagem chegue incompleta, devendo-se aguardar um tempo limitado por cada byte esperado. Em situações de falha na comunicação, sugere-se que o dispositivo descarte a mensagem parcialmente recebida ou com erro de CRC, sinalizando ao mestre esta situação. Em geral isto é feito por meio de uma mensagem de reconhecimento (ACK). Se tal mensagem não for enviada por quem recebeu a mensagem, então o dispositivo que a enviou pode concluir que houve falha de comunicação. Nestes casos, pode-se tentar retransmitir a mensagem até um certo número de vezes. Se a falha se mantiver, então conclui-se que o dispositivo está em falha permanente.

Controle de acesso por software ao barramento RS-485

No caso de microcontroladores ligados diretamente ao transceptor de 485 ou no caso de utilização do conversor RS-232/RS-485 com controle pelo RTS, o procedimento de acesso ao barramento para escrita é feito por software. Em ambos os casos é preciso setar o pino DE do transceptor antes da transmissão e mantê-lo em nível alto até o fim da mesma.

Em microcontroladores esse procedimento torna-se bem simples, dada a facilidade em se ativar e desativar uma das saídas digitais, e também porque a maioria dos microcontroladores com UART possuem interrupções para indicar o fim de uma transmissão, que ocorre quando o buffer de transmissão fica vazio.

Já em microcomputadores PC o procedimento é o mesmo, sendo que o controle é feito pelo pino RTS da porta serial. Se a aplicação for desenvolvida em linguagem C, por exemplo, o acesso a saída RTS pode ser feito utilizando a API do sistema operacional, inclusive para espera do fim da transmissão. Ao passar por APIs, o programa pode ter comportamento pouco determinístico, principalmente em se tratando de sistemas operacionais que não sejam tempo real. Isto ainda fica pior com o Windows, que com as versões 2000/XP impossibilitaram o acesso ao hardware por programas que se executam no modo usuário. O mesmo somente pode ser feito no modelo kernel via device drivers. Para tanto, existem alguns device drivers para acesso ao hardware tais como GiveIO1 ou PortTalk2. Entretanto, o tempo necessário para troca de informações do software do usuário com o device driver é ainda não determinístico, dificultando, por exemplo, o tempo máximo de espera por uma mensagem.