USB-RS232 serial driver
I am writing a simple driver to talk to an electronic chess board.
Actually I hacked a serial com emulator called com.c which uses interrupt control. I can receive data no problem. I can write data into the tx buffer but it does not send! I noticed if I close the program, the tx buffer is written out and the chess board responds. I think I need to flag an interrupt to transmit. Which I do not know how to do in linux. Or maybe it is because I am using a usb-rs232 cable adapter. help..........don |
Do you need to flush the buffer after writing perhaps?
|
There are at least two possible things going wrong, here. Your program may be failing to send the data, the data may be incorrect and so does not elicit a response from the chess board. Have you tried a loopback cable, to see whether the data you think should be getting sent, actually is? It is possible that the chess board does not consider your message until it sees a line terminator (most commonly CF, LF or the two in combination). It is also possible that the serial port driver is not sending the data until it sees a line terminator, or has received a fflush().
--- rod. |
flushing
Quote:
thanks........don |
loopback
Quote:
I downloaded the gtkterm source, the danged serial function is 500 lines long! gtkterm works well, I think I will have to dissect it and find out what I am doing differently. I think it might be the USB-rs232 adapter cable. Do you know where I can find the definitions for the data structure sent to open() & tcsetattr() functions? Where do they document the programmers nuts & bolts stuff of linux? thanks............don |
A few indispensable online references for serial comm's:
Serial HOWTO Serial Programming HOWTO Serial Programmming Guide for POSIX Operating Systems Terminal Concepts in GNU/Linux The first two references specifically will answer your questions about open() and tcsetatr(). --- rod. |
update
Quote:
About your previous suggestions: * I made a loopback cable and tested it with gtkterm successfully. When using the loopback cable the serial program is definitely NOT sending anything. *fflush() man page says it will send whatever is in the tx buff, great. However the fflush arg is type FILE *stream and my serial port file descriptor is type int. [btw I use open().] Do you know of another way to open the serial port with a compatible file descriptor? Man page says fflush(NULL) should flush all open streams, but when tested, the serial program still did not transmit the tx buffer. *CR & LF I tested these options with gtkterm in hex mode. The chess board expects to see a CR (0x0d) at the end of the string. *tcflush() man page says it flushes the txbuffer but does not send. I tried it anyway without success. *tcflow() man page says this disables/enables output. It has no effect in my problem. *tcdrain() This is interesting. Man page says this function waits until the tx buffer is empty. When I call tcdrain() after I call write(), my serial program hangs. This confirms the tx buffer is not being emptied/sent. I need a way to tell the UART to send the contents of the tx buffer. I know this is done by flagging an interrupt. Any ideas on how to do this in Linux? thanks...........don |
Oops, you're right. Sorry about that. To flush, you call ioctl() on the filehandle with request = TCFLSH.
You may need to set some attributes to cause your serial port to ignore hardware handshaking/flow control. Code:
c_cflag &= ~CNEW_RTSCTS; I don't think the use of interrupts is part of the problem you're trying to solve. --- rod. |
Hi Rod. Thanks for the help. I hate to bother you with details, but I can't fine the definition of TCFLSH. It is not in termios.h (as documented) or the raft of header files I have included.
later.........don |
Simplest answer:
man ioctl ioctl() is a generic way of talking to various drivers. It is used to modify the behavior of the driver itself, and the various requests depend on the specific driver. In this case, it is a request to flush the transmit queue. Also, see http://www.easysw.com/~mike/serial/serial.html#5_1 --- rod. |
OK found the byte representation for TCFLSH. I will need to study this problem more. That easysw guy is good but his article is not definitive. Actually none of what I have found is. I will crack this problem when I get home next week and try it on another linux box.
thank you kindly........don |
All times are GMT -5. The time now is 01:26 PM. |