We ran into somthing similar and scratched our heads about it for AY too
long before realizing that
we needed to put the port in binary mode via the following bit of code:
struct termios options;
tcgetattr( rtio_port, &options );
cfmakeraw( &options );
options.c_cflag |= CS8 | CLOCAL | CREAD;
tcsetattr( port, TCSANOW, &options );
Mircea Ciocan wrote:
On 1/27/2011 2:34 PM, Toan Pham wrote:
I had this same problem 2 years ago when i was using the ACM_CDC
driver to interface with a uC using LUFA usb library. As far as i can
remember, I sniffed the data using usb_mon and saw that the data came
through; but somehow the character (13 ordinal) got filtered out
through usb serial, cdc or tty layer. I wasn't sure the real cause,
and so I programmed the uC to add 48 to all transfer byte, and
subtract 48 on the host application.
It would be nice to know the root cause.
thank you,
-toan
This specific character is the End Of File (EOF ) character, and
usually it is interpreted depending on how a file is open, in "text
mode" or in "binary mode", if your file is open in text mode and have
binary stuff in it like EOF than you're doomed, this is ground for
VERY interesting and hard to kill bugs.
I don't know how is the Linux default behavior of "w" fopen()
parameter because I open them explicitly with "wb" or "wt" since 15yrs
when I had this problem as well.
Cheers,
Mircea
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
