0

I am trying to use QString functions to process frames received via serial in quite fast succession. I am running into problems where the functions such as mid() seem to stop working when called too quickly in rapid succession. I wrote a small test program to test it and am still having the problem. Is there a way I can make this work for calls in rapid succession or are there alternative functions I can try using? The code looks like this:

for(i = 0; i < 200; i++){
  status = interfaceObject.recieveBlocking(&frame);
  if(status == 0){
    ui->statusWindow->append(frame.data + "\r");
  }
  qApp->processEvents();
}

and the receiving function like this:

int interface::recieveBlocking(struct frameStructure *frame){

  if(serialPort.waitForReadyRead(100)){
    QString read = serialPort.readLine().trimmed().simplified();
    int length;
    QString data;
    QString id;
    bool extended;
    if(read.left(1) == "t"){
      extended = false;
      id = read.mid(1,3);
      length = read.mid(4,1).toInt();
      data = read.mid(5).trimmed();
      if(read.length() < 5 || ((data.length()/2) < length))return 3;
    }else if(read.left(1) == "T"){
      extended = true;
      id = read.mid(1,8);
      length = read.mid(9,1).toInt();
      data = read.mid(10).trimmed();
      if(read.length() < 10 || ((data.length()/2) < length))return 3;
    }else{
      return 3;
    }
    frame->id = id;
    frame->length = length;
    frame->data = data;
    frame->extended = extended;
    return 0;
  }else{
    return 1;
  }
}

The serial getting set looks like this (sent at about 80 frames per second):

T18340418800009A1940000000
T1834041B83CD011CF00000000
T1834041F8596A090000CCF4FF
T1834042184C4300007A110600
T1834042280000000000000000
T18340423899115C00FFA75B00
T18340424833F304002C2C0100
T18340425800000006000000FB
T18340418800009A193F000000
T180C041880000000000002500
T18340418800009A193F000000
T18340418800009A193F000000
T180C041880000000000002500
T18340418800009A193F000000
T1834041B83CD011CF00000000
T1834041F85C870900003FF7FF
T1834042181D1900007A110600
T1834042280000000000000000
T18340423866465C00FFA75B00
T183404248CC4C030063C80000
T18340425800000006000000FB
T18340418800009A193F000000
T180C041880000000000002500
T18340418800009A193F000000
T18340418800009A193F000000
T1834041B83CD011CF00000000
T1834041F816020700004FF9FF
T1834042181185FFFF7A110600
T1834042280000000000000000
T18340423899115C00FFA75B00
T183404248FF1F040050FA0000
T18340425800000006000000FB
T180C041880000000000002500
T18340418800009A193F000000
T18340418800009A193F000000
T180C041880000000000002500
T181404188C300000000000000
T182C041881E00000000000000
T18340418800009A193F000000
T183C04188002C000000000000
T1824041880036000000000000
T18340418800009A193F000000
T1834041B83CD011CF00000000
T1834041F8CA82060000F5F5FF
T183404218B8E0FFFF6B100600
T1834042280000000000000000
T18340423899115C0099115C00

The output in the textBrowser looks like this:

0000000000002600 T18340418800009A193E000000

0000000000002500

00009A193E000000

00009A193E000000

3ED013CF00000000

6F4082FA0064E7FF T1834042181F2200001C0B0600 T1834042280000000000000000 T18340423832BB640032BB6400 T18340424899790200FB950000

00000006000000FB T180C041880000000000002500

00009A193E000000 T18340418800009A193E000000

0000000000002500

00009A193E000000

00009A193E000000

3ED013CF00000000

CC4A83FA0020EFFF T183404218DE6D00009A130600

0000000000000000 T18340423832BB640032BB6400 T183404248FF1F0400F9F90000 T18340425800000006000000FB

0000000000002500

0036000000000000 T18340418800009A193E000000

00009A193E000000

0000000000002500

00009A193E000000

3ED013CF00000000

083683FA00E7EBFF T1834042187FF8FFFFA9140600

0000000000000000 T1834042386686640066866400 T183404248CC4C030086C80000 T18340425800000006000000FB

00009A193E000000

0000000000002500

00009A193E000000

00009A193E000000

3ED013CF00000000

211384FA0074E9FF

C20E00004B0E0600 T1834042280000000000000000 T18340423832BB640032BB6400 T183404248CC4C0300A9C80000

00000006000000FB T180C041880000000000002500

00009A193E000000 T18340418800009A193E000000

0000000000002500

00009A193E000000

00009A193E000000

3ED013CF00000000

AECA82FA00D7E9FF T183404218911C00002C0C0600 T1834042280000000000000000 T1834042386686640032BB6400 T183404248CC4C0300FAC70000 T18340425800000006000000FB

0000000000002500

C300000000000000 T182C041881E00000000000000

00009A193E000000 T183C04188002F000000000000 T1824041880036000000000000 T18340418800009A193E000000
englemon
  • 41
  • 2
  • 3
    Avoid using the waitXXX methods, they are blockers, instead use signals. – eyllanesc Jul 18 '18 at 16:28
  • Is `serialPort` an instance of `QSerialPort`? If so then your calls to `serialPort.readLine()` assume the data returned (if any) is a complete line. I don't think there are any such guarantees. – G.M. Jul 18 '18 at 16:49
  • The way I understood it is that readLine reads until a \r character. There is a \r at the end of each packet that is sent. so it shouldn't keep reading past a packet. – englemon Jul 18 '18 at 19:02
  • I obviously didn't understand how readLine() worked. I now at least know where to look to fix it. Thanks – englemon Jul 18 '18 at 19:12
  • Don’t use QString (unicode strings) but QByteArray (plain data) when implementing a protocol like this. – Frank Osterfeld Jul 19 '18 at 07:53

0 Answers0