2

I am trying to figure out how to get information from my Arduino Mega 2560 through the USB port to a C program running in Xubuntu.

I'm trying to put together the simplest possible example to be used as a starting point.

The Arduino IDE comes with some nice basic examples, one of which is Graph, which simply prints the value from a potentiometer or other analog sensor:

void setup() {
  Serial.begin(9600);
}

void loop() {
  Serial.println(analogRead(A0));
  delay(2);
}

No problems there, but as for the program that will be running on my computer and receiving the data, here's what I have so far(updated after reading this and doing some more digging):

/* prints the output from an Arduino running the "Graph" example.
 */

#include <stdio.h>
#include <sys/fcntl.h>
#include <termios.h>

int main(void)
{
  int fd = 0;
  char buffer[32];
  int n;
  fd = open("/dev/ttyACM0", O_RDWR | O_NOCTTY | O_NDELAY);
  while(1)
  {
    read(fd, buffer, sizeof(buffer));
    n = atoi(buffer);
    printf("%d\n", n);
  }
  close(fd);
}

This almost works, but it appears to be missing more messages than it's getting and a lot of the messages are incomplete.

There are several options and flags that can be set along the way and I'm having trouble determining which ones to set.

Ultimately, I plan on using various sensors running through my Arduino to control SDL-based applications running on my computer, but as soon as I can just get that string then I should be back in familiar territory.

Duovarious
  • 109
  • 7

2 Answers2

0

Your buffer can (and is likely to) contain more than one message. It may also contain an incomplete message (read() call may return earlier than it reads all the data you ask for).

For example, if the data you receive is a stream of '\n'-separated (or '\0', or space, or whatever else) numbers in textual form, your buffer may end up looking like 0123\n4567\n89ab. Then, when you call atoi(), it converts 0123 to 123 and you skip to the next iteration of the loop while abandoning all the data that is left in the buffer.

Roman Dmitrienko
  • 3,375
  • 3
  • 37
  • 48
  • That makes sense, but even when the buffer is the exact same length as the message, I tend to end up with two fragments from two messages. I haven't found a way to synchronize the communication. – Duovarious Dec 25 '12 at 07:37
  • You may be losing something between the moment when device starts sending data and the moment when you begin reading it, so you get out of sync. Are there any delimiters between numbers in the stream? – Roman Dmitrienko Dec 25 '12 at 07:50
  • I suspect they're separated by '\n' but I'm not sure. – Duovarious Dec 25 '12 at 08:10
  • How do you know that you end up with two fragments from two messages in the buffer, then? You need to sort it out first. Afterwards, to get in sync with the stream, you'll be able to read and drop all chars prior to (and including) the first found delimiter (`'\n'` or whatever else) to get rid of any old partial messages in the buffer, if any. – Roman Dmitrienko Dec 25 '12 at 08:15
0

This is what I was looking for.

Duovarious
  • 109
  • 7