Looking for debugging advice when communicating to arduino from C++ on linux

I'm having an issue where I can send commands to my arduino from my mac IDE using the serial monitor and everything works fine. However, when I connect the arduino to my linux computer and use the code I developed nothing happens. I'm using the following code to write to the arduino:

file = open("/dev/ttyACM0", 0_RDRW | 0_NOCTTY |  0_NDELAY);

struct termios options;
tcgetattr(file, &options);
cfsetispeed(&options, B9600);
cfsetospeed(&options, B9600);
options.c_flag |= (CLOCAL | CREAD);
tcsetattr(file, TCSANOW, &options);

I then use sprintf to formulate a send package called sendpack, and send it using:

ret = write(file,sendpack,17);

This code used to work for me but now it's not. The value of ret is 17, indicating it wrote those 17 bytes to the arduino but if it did then it should start driving my motors like it does when I send the command through the IDE on my mac.

Since write() returns the bytes written and not an error (-1) I'm guessing somehow the data in "sendpack" is possibly getting changed?

I've tried using echo to send a string to the arduino which didn't do anything, and when I used tail to try and listen to the arduino the terminal window just hangs. I can't install the IDE because I'm using an old version of ubuntu (8.04) and can't update ubuntu because other hardware I'm using won't work on newer kernels.

So any tips on what I can do to further debug this situation would be greatly appreciated.

Are you taking into account the fact the Arduino reboots when you open the serial port? Anything you send within the first second or so will be ignored.

Have the Arduino send an "I am ready" signal in setup(), and have your software wait for that signal before sending.

My code runs on an infinite loop and will keep sending data as long as I'm telling it to. If I send data too early with it stop it from communicating for the rest of the time or just miss the first couple packets of info?

MARSlabW:
My code runs on an infinite loop and will keep sending data as long as I'm telling it to. If I send data too early with it stop it from communicating for the rest of the time or just miss the first couple packets of info?

It'd just miss the first couple of packets. It's not that then...

There's lots and lots of tricks you can do in Linux. One of them involves a program called socat:

# socat -d -v -x PTY,link=/tmp/serial,wait-slave,raw /dev/ttyACM0,raw

Point your program to /tmp/serial instead of /dev/ttyACM0 and you should see all the data dumped to the screen.

apt-get cant install socat, it gives me a 404 error. Is there a version for hardy? Maybe some other software I can try instead?

Hardy?!?! My god, man! How ancient?! Try having a look here: https://launchpad.net/ubuntu/hardy/+package/socat I didn't look too deep, but you may find a version there that'll work?

Ok... are you sure the device is opening right, and that the baud is setting right? I would suggest you try minicom to communicate manually, but I doubt that'll install either...

Here's the code I use to open serial ports:

    _serial = open(device, O_RDWR | O_EXCL | O_NONBLOCK);
    if (!_serial) {
        errno = ENODEV;
        return -1;
    }
    tcgetattr(_serial, &tty);

    cfsetspeed(&tty, baud);
    cfsetispeed(&tty, baud);
    cfsetospeed(&tty, baud);
    tty.c_cflag = (tty.c_cflag & ~CSIZE) | CS8;
    tty.c_iflag =  IGNBRK;
    tty.c_lflag = 0;
    tty.c_oflag = 0;
    tty.c_cflag |= CLOCAL | CREAD;
    tty.c_cc[VMIN] = 1;
    tty.c_cc[VTIME] = 5;
    tty.c_iflag &= ~(IXON|IXOFF|IXANY);
    tty.c_cflag &= ~(PARENB | PARODD);
    tty.c_cflag &= ~CSTOPB;
    tcsetattr(_serial, TCSANOW, &tty);

baud is a numeric baud value instead of a Bxxxx value, but it should make no difference.

Thanks! The code you gave me seems to be working, and the socat link you gave me worked as well, so I have that tool available for when it stops working again.

I wish I could upgrade the OS, but the USB-CAN interface device I have will not run on newer kernels (I guess they want you to spend another $1000 to get the newer hardware) so I am stuck with hardy. I'd much rather be running a version that supports ROS Fuerte so I can use it for communication rather than UDP packets but you have to make do with what you got. Thanks again for the code, any idea why yours works and mine doesn't?

EDIT: I take that back, it worked one time I ran the code, but now it doesn't work. I'll have to look in to this further on Monday. Thanks again for your help.

EDIT2: After more messing around, I'm ashamed to say I think it was just a faulty USB cable, the new one works fine.