Enviando carácter pela serial

Ola pessoal estou tentando comunicar um equipamento via serial, não estou conseguindo fazer funcionar a rotina para envio de caractere.

#include <errno.h> // Error number definitions
#include <fcntl.h>
#include <math.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <termios.h>
#include <time.h> // time calls
#include <unistd.h> // Requerido pelo write()
#include <mysql/mysql.h>
#include <sys/types.h>
#include <sys/signal.h>
#include <sys/stat.h>

#define BAUDRATE 115200
#define SERIALPORT "/dev/ttyS0"
#define on 1
#define ON 1
#define true 1
#define TRUE 1
#define off 0
#define OFF 0
#define false 0
#define FALSE 0

#include "seriallib.h"

int fd:

main(){
fd = OpenSerial(SERIALPORT);
SetupSerial(fd,BAUDRATE,8,1,'n');
SendSerialString(fd,"#IH,01,O,1,1,*\n");
}

Não está enviando nada...

Já até setei stty -F /dev/ttyS0 115200 no shell

A biblioteca está aqui "paulbourke.net/libraries/seriallib.h"

Amigo tenta colocar a velocidade da porta para 9600 provavelmente dá certo. Eu pelo menos nunca consegui enviar nada (ou quando até chega, aparece caracter estranho) usando 115200.

Fica a dica e feliz ano novo.

O equipamento utiliza esta velocidade, não tenho como reduzir.

Preciso saber se o source está funcional...

Olha, desculpa nao poder ajudar mais é que estou estudando a linguagem C++ não conheço a fundo por isso não tenho base para lhe indicar onde possa estar o erro.

Só por curiosidade, que tipo de equipamento é esse que voce tá enviando esta informação?

O equipamento é uma placa de I/O

Mas você já experimentou
#define BAUDRATE 9600 em vez de 115200 ?

Às vezes a insistência vale a pena, já que há instrução para enviar 8 bits por vez.

9600 não vai dá, por que irei comunicar com 99 placas de I/O's ao "mesmo tempo"
Consegui utilizando 115200 baudrate e a biblioteca seriallib.h...

Valew pessoal...

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.