c++ - > Linux termios -> seriele data syncen op newline

[tomsema]

Beste Tweakers,

Ik ben een applicatie aan het ontwikkelen dat seriele adc data via rs232 inleest en vervolgens parsed.
In mijn applicatie gebruik ik de read functie om de rs232 data via de device file in te lezen.

in een termios struct configureer ik de seriele poort:

C++:

 fd = open(dev, O_RDWR | O_NOCTTY );

   if(fd < 0) {
      perror("open");
      exit(1);
   }

   memset(&tty, 0 , sizeof(tty));

   //set baudrate
   cfsetospeed (&tty, B115200);
   cfsetispeed (&tty, B115200);

   tty.c_cflag         &=  ~PARENB;     //Make 8n1
   tty.c_cflag         &=  ~CSTOPB;
   tty.c_cflag         &=  ~CSIZE;
   tty.c_cflag         |=  CS8;
   tty.c_cflag         &=  ~CRTSCTS;    //no flow control
   tty.c_lflag          =   0;          //no signaling chars, no echo, no canonical
   tty.c_oflag          =   0;          //no remapping, no delays
   tty.c_cc[VMIN]       =   1;          //minimal amount of bytes
   tty.c_cc[VTIME]      =   0;

   tty.c_cflag         |=  CREAD | BRKINT | CLOCAL;         //turn on read ignore c
   tty.c_iflag         &=  ~(IXON | IXOFF | IXANY);         //turn off sw en flow c
   tty.c_lflag         &=  ~(ICANON | ECHO | ECHOE | ISIG); //make raw
   tty.c_oflag         &=  ~OPOST;                          //make raw

   //flush port
   tcflush( fd, TCIFLUSH );

   if (tcsetattr(fd, TCSANOW, &tty) != 0) {
      perror("tty");
      exit(1);
   }

De read functie blockt net zolang tot dat aan deze voorwaarden wordt voldaan. Ik maak nu gebruik van non-canonical processing en read net zo lang tot dat ik de complete chunk aan data (840 bytes) binnen heb.

Iedere chunk aan data dat door de rs232 apparaat word verstuurd eindigd met een \n. Is het mogelijk mijn tty config zo aan te passen dat de read functie pas returned als het \n karakter voorbij komt?

[Rmg]

Daar zul je de read functie voor moeten aanpassen. En waarschijnlijk ook de buffergrootte als de chunks die je krijgt groter zijn dan 840 bytes.

[JeromeB]

Canonical input processing lijkt me dan het handigst.

[farlane]

Ehm, non-canonical canonical input leest tot aan een line terminating character en \n is dat, dus volgens mij doet het standaard al wat je wilt.

[edit]
@EddoH Natuurlijk, ik was abuis

[ Voor 18% gewijzigd door farlane op 09-05-2014 13:00 ]

[EddoH]

@farlane: je bedoelt canonical input. JeromeB heeft gelijk.

@ts:

code:

Macro: tcflag_t ICANON
This bit, if set, enables canonical input processing mode. Otherwise, input is processed in noncanonical mode

[tomsema]

maar kan evt adc data dan niet per ongeluk worden geprocessed?

[EddoH]

Dat ligt eraan hoe het verstuurd wordt. Ik neem aan dat het al ASCII is anders slaat die \n als terminating character ook nergens op.

[JeromeB]

Eventueel kun je een ander scheidingsteken instellen (VEOL als ik het me goed herinner).

Overigens vind ik het zelf handig om boost te gebruiken. Je kunt dan gewoon een async_read_until doen en je hoeft je niet meer druk te maken over speciale settings.

[tomsema]

De ontwikkelaar van het apparaat heeft er voor gekozen de het line feed karakter te gebuiken om het einde van de datachunk aan te geven. ADC data is gewoon raw data. VEOL kan alleen bij canonical processing worden gebruikt. Denk dat ik Boost maar ga gebruiken.

[ Voor 22% gewijzigd door tomsema op 09-05-2014 17:28 ]

[EddoH]

Dat zou raar zijn aangezien een adc waarde van 12 dan een einde van een datachunk aan zou geven. Lijkt me niet de bedoeling. Ik vermoed dat de data gewoon ascii gecodeerd is.

Een boost async_read_until zou dan trouwens hetzelfde probleem geven.

[ Voor 17% gewijzigd door EddoH op 09-05-2014 18:11 ]

[farlane]

EddoH schreef op vrijdag 09 mei 2014 @ 18:09:
Dat zou raar zijn aangezien een adc waarde van 12 dan een einde van een datachunk aan zou geven. Lijkt me niet de bedoeling. Ik vermoed dat de data gewoon ascii gecodeerd is.

Een boost async_read_until zou dan trouwens hetzelfde probleem geven.

Je wilt niet weten hoeveel van dat soort pareltjes van (zelfbedachte) protocollen er rond zwerven.

[EddoH]

Dat is helaas ook weer waar...
Ben nu eigenlijk wel benieuwd naar welk apparaat/protocol het hier om gaat