Question

I’m playing with an XBEE radio, I’m using Linux (Ubuntu 9.10) and the XBEE doesn’t appear to send NULL values through the serial port when using MY code. When I use the XCTU program(stock term emulator that comes with the XBEE on a seperate windows box), I see this output through the serial port when a new XBEE joins the network:

7E 00 20 95 00 13 A2 00 40 3B

etc… perfect. But, using MY code, when a new XBEE joins the network I see this:

7E 20 95 13 A2 40 3B

Here is how I’m opening the serial port

struct termios options;
int port;

port = open("/dev/ttyUSB0", O_RDWR | O_NONBLOCK);
tcgetattr(port, &options);
bzero(&options, sizeof(options));

options.c_cflag = B9600 | ~CRTSCTS | CS8 | CLOCAL | CREAD;

tcsetattr(port, TCSANOW, &options);

I have my theories about what that code does, but my theories are obviously wrong. I’m trying to open the port with 9600, 8N1, No Flow control. You can see I’m also using the serial->USB driver, but since I do seem to get data I’m pretty sure that part is working.

My guess is when I bzero options, I’m making 0x00 a control char? I’m not sure. When I DON’T bzero options I can only read 5 bytes at a time and I lose data. It feels like I’m having a flow control or a baud rate problem, so I bzero() and now I don’t get NULLs.

I’ve also just used Minicom on my Linux system and captured the output. I get the same information, no NULLs(this really messes up packet sizes for those unfamiliar with the protocol). Could my code have set the serial port into a state that minicom isn’t changing? I’m lost.

Thanks for the help!

Answer 1

The initialization of the c_cflags looks wrong, by using bitwise negation you basically set all the bits beside CRTSCTS:

options.c_cflag = ... | ~CRTSCTS | ...;

You should just leave out CRTSCTS if that flag should not be set.