asterix-super
(usa Ubuntu)
Enviado em 03/02/2012 - 10:12h
Qual o comprimento que usou nos cabos de teste?
Trançados ou não?
Pergunto isso porque transmitir em RS-232 a 115000bps é enjoado. Na verdade, na década de 90, onde houve necessidade, nunca consegui.
Tive problemas, e resolvemos transmitir em RS-485 a menos de 100 metros. Só foi possível trançando o par de cabinhos, e ainda assim, vinha pacotes truncados. Baixamos a velocidade para 38000bps coisa assim, e somente então funcionou com estabilidade.
Se puder baixar a velocidade você pode isolar o problema. As vezes, nem a própria UART do PC ou do equipamento dá conta dessa velocidade.
Você está usando direto /dev/ttySn ou está usando conversores serial/USB (/dev/ttyUSBn)?
Na minha experiência, esses conversores USB não funcionam muito bem, mesmo usando o melhor chip deles, que é o da FTDI.
Talvez porque faço comunicação muito simples, a 9600bps, sem paridade, sem qualquer controle, somente a 3 fios.
Quando acesso direto pela serial ttySn, a coisa flui BEEMM melhor.
Outra coisa, talvez esteja acontecendo isso com você:
No linux debian ou ubuntu, não sei porque ocorre isso, nas minhas máquinas, percebo um "lag" nos dados transmitidos/recebidos.
É como se enchesse um buffer virtual de dados. Eu teria que ir lendo, até que começa a ficar mais atual os telegramas que recebo.
Minha aplicação é balança rodoviária digital. Manda pacotes com leitura do peso, data e hora, de 1 em 1 segundo.
Eu usava o dosemu + aplicação Clipper para ler serial. Era o caminhão "pisar" na balança, que depois de mais de 30 segundos, ainda vinha leitura de 0 kgs. Foi feito então um loop na rotina de leitura, para ler mais rapidamente. Então o atraso da leitura correta do peso caiu para menos de 5 segundos, tempo suficiente para ir cadastrando o caminhão até a captura do peso estabilizado.
Migrei para um ERP feito em java, rodando sobre ubuntu (na época era ubuntu 8, hoje 10). O mesmo problema continuou. Melhorou um pouco usando biblioteca RxTx. O pessoal do java, para resolver, deve ter feito gambiarra parecida, fazer várias leituras até ir esvaziando "buffer" e capturar os pacotes mais frescos.
Parece que existe um buffer para comunicação serial, que fica disponível para máquinas virtuais como a do java ou emulador DOSemu. Mas tem que ir lendo, que ele vai esvaziando. Não encontrei nada que possa dar um "flush" ou limpeza no buffer. A máquina virtual não tem acesso a essa parte e não encontrei nada no linux, por enquanto.
Essa semana voltei a esse assunto, pois estou tentando comunicação com ZigBee, usando o Fractum UsBee Max e desta vez, quero testar com algo 100% linux. Testei puTTY, gtkterm, moserial, e o cuteCom, ambos terminais gráficos no Ubuntu 11. As vezes o zig reconhece o comando AT, as vezes não. E é através de USB. Agora estou tentando configurar direto, usando setserial, stty e mandando echos, mas sem sucesso, dá erro de acesso.
Não sei se no C do linux esse lag acontece.
