soned wrote:Sim, eu estou usando um conversor usb-serial.

segue abaixo o código:
public void abrirPorta(String porta, Integer baudrate, Integer timeout) throws NoSuchPortException, PortInUseException, UnsupportedCommOperationException, IOException, TooManyListenersException{ this.porta = porta; CommPortIdentifier cp = CommPortIdentifier.getPortIdentifier(porta); portaSerial = (SerialPort)cp.open(this.getClass().getName(), timeout); portaSerial.setSerialPortParams(baudrate, portaSerial.DATABITS_8, portaSerial.STOPBITS_1, portaSerial.PARITY_NONE); LerDados(); } public void enviarUmaString(String msg) throws IOException, InterruptedException{ saida = portaSerial.getOutputStream(); saida.write(msg.getBytes()); // Thread.sleep(100); saida.flush(); // saida.close(); } public void LerDados() throws IOException, TooManyListenersException{ entrada = portaSerial.getInputStream(); portaSerial.addEventListener(this); portaSerial.notifyOnDataAvailable(true); threadLeitura = new Thread(this); threadLeitura.start(); } public void serialEvent(SerialPortEvent spe) { switch(spe.getEventType()){ case SerialPortEvent.BI: case SerialPortEvent.OE: case SerialPortEvent.FE: case SerialPortEvent.PE: case SerialPortEvent.CD: case SerialPortEvent.CTS: case SerialPortEvent.DSR: case SerialPortEvent.RI: case SerialPortEvent.OUTPUT_BUFFER_EMPTY: break; case SerialPortEvent.DATA_AVAILABLE: msgRecebida = ""; byte[] bufferLeitura = new byte[193]; try { Thread.sleep(500); while (entrada.available() > 0) { //node bytes fornece a qtde de bytes recebidos nodeBytes = entrada.read(bufferLeitura); msgRecebida = msgRecebida.concat(new String(bufferLeitura).substring(0, nodeBytes)); } observer.HasDataAvailable(); } catch (Exception ex) { System.out.println("Erro durante a leitura: " + ex); } break; } }

juliocbq wrote:

laudenpower wrote:Bom, vou desfiar meu rosário...
Tenho um servidor feito em vb que realiza uma consulta via serial rs485 para 5 dispositivos diferentes e com seus respectivos endereços.
Acontece que o meu objetivo é "tomar" o lugar de um desses 5 dispositivos, e para isso eu preciso emular o protocolo de comunicação dele.
A parte de emular o protocolo já foi realizada, porém o servidor realiza uma consulta de status dos dispositivos em um intervalo de 30ms entre um dispositivo e outro, e a consulta de status consiste em um pacote de 12 caracteres, onde está contido o endereço do dispositivo (para que o mesmo responda na sua vez).
Essa consulta é realizada em todos os dispositivos pelo servidor e quando acontece algo a algum dispositivo, esse deve responder assim que recebe o pacote de consulta contendo o seu endereço.
Então o dispositivo possui 30ms para realizar o envio do comando que indica a ocorrencia do evento nele (como o pressionamento de uma botoeira, por exemplo).
Nesse caso se o dispositivo demora mais de 30ms para devolver o comando referente ao evento ocorrido, o servidor acaba recebendo esse comando durante a consulta de outro dispositivo, invalidando assim o envio do dispositivo e quebrando o protocolo.

Resumindo: Preciso enviar um comando para o servidor numa faixa máxima de 30ms depois de receber o comando de consulta com o endereço do dispositivo emulado, pois se isso não acontecer o servidor passa a consultar o proximo dispositivo e o comando enviado é invalidado pelo servidor.

Tentei fazer isso em: Java, VB e delphi6 falhei miseravelmente em todos eles.

Nesse caso a forma que o C++ utiliza para manipular porta serial é a mesma do java (com rxtx), VB e delphi? (Nesse caso o C++ utiliza apenas a api do windows ou existe outra forma?).

Posso estar errado, mas não creio que o c++ vá resolver a sua situação. Todas essas opções que você usou(java, delphi, vb) usam a mesma api do windows internamente.

thingol wrote:Se seu dispositivo requer que a resposta seja enviada em no máximo 30 ms, eu diria que é necessário deixar só essa parte que recebe a requisição e envia uma resposta (qualquer que seja ela) em uma thread com a prioridade RealTime (as outras threads não devem usar essa prioridade).

Esse é um dos poucos casos em que é absolutamente necessário alterar a prioridade de uma thread.

Atenção! Atenção! Atenção! Essa thread deve fazer quase nada, exceto pelo fato de responder rapidamente à requisição do dispositivo. Qualquer regra de negócio, etc, deve ser feita fora dessa thread.

(Por que é que você não precisaria disso se sua thread ficasse escutando um socket ou esperando ler de um arquivo? É que nesses dois casos o Windows já eleva a prioridade da thread que está esperando ler de um socket, ou ler de um arquivo, para uma prioridade bem alta. Uma vez que o socket tenha sido lido ou o arquivo tenha sido lido, então a prioridade baixa automaticamente. Mas no caso de uma interface serial, isso não ocorre. )