Olá
[quote=securitynews]exemplo, preciso conversar com 500 placas?
a unica solução eficiente que encontrei com o java foi essa, interrogar as placas de tempo em tempo.
Utilizo checksum para validar a comunicação!
a uma distancia de quase 1 km usando rs485 raramente discarto um mensagem.
nosso protocolo é utilizado em catracas do Beto Carreiro, Parque do gugu, e outro varios lugares, e é eficiente!
agora me interessei em descobrir o porque das perdas de bytes que o Luca citou utilizando pooling?![/quote]
Há muitos anos atrás, ainda no tempo do DOS, a gente usava Laplink que era um programa muito rápido para fazer transferência serial entre PCs. Naquele tempo ainda não havia redes TCP/IP e nem mesmo o Windows for Workgroups havia sido lançado com aquele protocolo de rede proprietário da Microsoft. A gente fazia transferências entre PCs usando cabo serial e quando disponível, cabo paralelo.
Neste tempo, fiz um programa de transferência serial de arquivos que funcionava como o Laplink mas que tinha a opção de comprimir os dados de arquivos grandes antes de transmitir. Precisava do máximo de velocidade possível.
A gente programava direto mexendo mais próximo do hardware possível. Na época a gente entendia que quando se fazia polling para verificar se estavam chegando novos bytes, o programa precisava parar enquanto esperava e a gente precisava otimizar o uso dos clocks da CPU para fazer coisa tais como por exemplo calcular ou verificar o CRC (não acreditava em cheksum para transferir arquivos) ou mover os bytes que chegavam para algum buffer.
Na verdade o Joe Campbell, um dos mais conhecidos autores de livros sobre comunicação serial, autor do clássico C Programmer’s Guide to Serial Communications, ensinava como fazer mas desaconselhava o uso das interrupções devido a excessiva proximidade com o hardware. Mas na época o bom era ser escovador de bits e meu programinha (quase todo em Assembler) se metia nas profundezas do inferno como outros autores como por exemplo o Mark Nelson recomendava no Serial Communications: A C++ Developer’s Guide. Um dos livros que tenho, de autoria do Peter Gofton, compara o uso de pooling e interrupções com um telefone sem campainha com o qual você precisaria a toda hora tirar do gancho para ver se tem novas ligações e outro com campainha alertando para novas ligações. Palavras dele: “I strongly recommend that you use interrupts whenever possible.”
Sobre a questão da possibilidade de perder bytes quando se faz pooling a explicação é muito simples mas para entender é preciso lembrar que antigamente os computadores eram mais lerdos e o sistema operacional DOS não era multi tarefa. Pooling significa de vez em quando perguntar a porta se chegou um byte e se chegou, fazer alguma coisa com ele. Este fazer alguma coisa com ele é que podia demorar mais do que a chegada do próximo byte e a nova consulta a porta.
No meu problema era usado o RS232 programando diretamente na UART e usando DOS em que isto era possível facilmente. A solução era do tipo de http://www.beyondlogic.org/serial/serial1.htm#30 que também fala da questão de pooling x interrupts.
Pensando melhor no problema e no hardware atual com os atuais sistemas operacionais multi tarefa, talvez não seja necessário ir tão fundo, principalmente para se comunicar com dispositivos relativamente lentos como leitoras de cartões, etc. Na época a gente queria transmitir com o máximo baud possível (115200 bps).
Vi agora em http://www.cic.unb.br/~bordim/TD/Arquivos/G10_Monografia.pdf uma comparação do RS232 com o RS485 e percebi enormes diferenças. Não conheço a RS485 e não sei dizer se seria possível obter vantagens usando interrupções. Se fosse o caso, provavelmente precisaria no Windows de um device driver do tipo do PortTalk de http://www.beyondlogic.org/porttalk/porttalk.htm ou algum outro se fosse no Linux. Mas se funciona bem tal como está então não se mexe.
Espero ter explicado apesar de que pode ter ficado meio confuso por ter editado várias vezes.
[]s
Luca
