Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. QSerialPort Issue:: reading an undesired write message.
QtWS25 Last Chance

QSerialPort Issue:: reading an undesired write message.

Scheduled Pinned Locked Moved Solved General and Desktop
qserialportreadyreadread serialwriteissue
4 Posts 3 Posters 1.1k Views
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • F Offline
    F Offline
    Factao
    wrote on 15 Feb 2019, 00:21 last edited by
    #1

    Hello,

    I didn't find anyone with the same issue, so I guess that I'm doing something wrong.

    I'm creating a QSerialPort , named COMRPI, in a QObject ,named m_arm, that is within a QApplication, named ArmApp. It is created within the constructor of m_arm:

     arm::arm():QObject()
     {   
         COMRPI=new QSerialPort("COM7");
         COMRPI->setBaudRate(115200);
         COMRPI->setDataBits(QSerialPort::Data8);
         COMRPI->setParity(QSerialPort::NoParity);
         COMRPI->setStopBits(QSerialPort::OneStop);
         COMRPI->setFlowControl(QSerialPort::NoFlowControl);
         if(!COMRPI->open(QSerialPort::ReadWrite))
         {
             qDebug()<<"Error ocured while opening COMRPI:"<<COMRPI->errorString()<<"Crash expected, deleting arm content to prevent most of memory leak.";
             delete COMRPI;
             delete m_hand;
         }
         else
         {
             std::cout<<"COMRPI is supposed to be operational."<<std::endl;
         }
     }
    

    After that, I'm running a function, member of ArmApp, named connectEverything:

    void ArmApp::connectEverything()
    {
       QObject::connect(this->m_controlWindow->ui->Actualisethearm,&QPushButton::pressed,this,&ArmApp::actualisationOfTheArm);
       QObject::connect(this->m_arm->COMRPI, &QIODevice::readyRead, this->m_arm, &arm::SerialPortReceiving);
       QObject::connect(this->m_arm, &arm::readingCompleted, &arm::InterpretingIncommingData);
    }
    
    

    The slot SerialPortReceiving is simply reading all that is present in the buffer and putting it in a string called m_buffe and InterpretingIncommingData, far from being complete, is just printing out m_buffer:

    void arm::SerialPortReceiving()
    {
        std::string NewData(COMRPI->readAll());
        m_buffer+=NewData;
        COMRPI->clear(QSerialPort::Input);
        emit readingCompleted();
    }
    void arm::InterpretingIncommingData()
    {
        std::cout<<m_buffer<<std::endl;
    }
    

    There is a widget with a push button, named actualisatethearm, emitting a signals that triggered the slot ActualisationOfTheArm, that is actually sending " EDFR/r" to the raspberry pi:

    oid ArmApp::actualisationOfTheArm()
    {
        //code of the actualisation
        std::cout<<"The arm is actualy being actualisate."<<std::endl;
        m_arm->COMRPI->write("EDFR\r");
    }
    

    Knowing that (Good point):
    -I'm able to receive the right message with the pi coming from the pc.
    -I'm able to receive the right message with the pc from the pi.
    -Everything, but the following issue, seems to work fine.

    Why is the message sent from the pc to the pi ( EDFR/r) triggered readyRead() signals, which is followed by the integration of a sent message that could compromised the received command?

    The integrity of the code implying the serial port is there, but don't mind to ask if you think that something required to a good understanding of this problems is missing.

    A J 2 Replies Last reply 15 Feb 2019, 04:40
    0
    • F Factao
      15 Feb 2019, 00:21

      Hello,

      I didn't find anyone with the same issue, so I guess that I'm doing something wrong.

      I'm creating a QSerialPort , named COMRPI, in a QObject ,named m_arm, that is within a QApplication, named ArmApp. It is created within the constructor of m_arm:

       arm::arm():QObject()
       {   
           COMRPI=new QSerialPort("COM7");
           COMRPI->setBaudRate(115200);
           COMRPI->setDataBits(QSerialPort::Data8);
           COMRPI->setParity(QSerialPort::NoParity);
           COMRPI->setStopBits(QSerialPort::OneStop);
           COMRPI->setFlowControl(QSerialPort::NoFlowControl);
           if(!COMRPI->open(QSerialPort::ReadWrite))
           {
               qDebug()<<"Error ocured while opening COMRPI:"<<COMRPI->errorString()<<"Crash expected, deleting arm content to prevent most of memory leak.";
               delete COMRPI;
               delete m_hand;
           }
           else
           {
               std::cout<<"COMRPI is supposed to be operational."<<std::endl;
           }
       }
      

      After that, I'm running a function, member of ArmApp, named connectEverything:

      void ArmApp::connectEverything()
      {
         QObject::connect(this->m_controlWindow->ui->Actualisethearm,&QPushButton::pressed,this,&ArmApp::actualisationOfTheArm);
         QObject::connect(this->m_arm->COMRPI, &QIODevice::readyRead, this->m_arm, &arm::SerialPortReceiving);
         QObject::connect(this->m_arm, &arm::readingCompleted, &arm::InterpretingIncommingData);
      }
      
      

      The slot SerialPortReceiving is simply reading all that is present in the buffer and putting it in a string called m_buffe and InterpretingIncommingData, far from being complete, is just printing out m_buffer:

      void arm::SerialPortReceiving()
      {
          std::string NewData(COMRPI->readAll());
          m_buffer+=NewData;
          COMRPI->clear(QSerialPort::Input);
          emit readingCompleted();
      }
      void arm::InterpretingIncommingData()
      {
          std::cout<<m_buffer<<std::endl;
      }
      

      There is a widget with a push button, named actualisatethearm, emitting a signals that triggered the slot ActualisationOfTheArm, that is actually sending " EDFR/r" to the raspberry pi:

      oid ArmApp::actualisationOfTheArm()
      {
          //code of the actualisation
          std::cout<<"The arm is actualy being actualisate."<<std::endl;
          m_arm->COMRPI->write("EDFR\r");
      }
      

      Knowing that (Good point):
      -I'm able to receive the right message with the pi coming from the pc.
      -I'm able to receive the right message with the pc from the pi.
      -Everything, but the following issue, seems to work fine.

      Why is the message sent from the pc to the pi ( EDFR/r) triggered readyRead() signals, which is followed by the integration of a sent message that could compromised the received command?

      The integrity of the code implying the serial port is there, but don't mind to ask if you think that something required to a good understanding of this problems is missing.

      A Offline
      A Offline
      aha_1980
      Lifetime Qt Champion
      wrote on 15 Feb 2019, 04:40 last edited by
      #2

      @Factao I don't fully understand your problem yet.

      • what do you do?
      • what do you expect to happen?
      • what happens instead?

      Regards

      Qt has to stay free or it will die.

      1 Reply Last reply
      1
      • F Factao
        15 Feb 2019, 00:21

        Hello,

        I didn't find anyone with the same issue, so I guess that I'm doing something wrong.

        I'm creating a QSerialPort , named COMRPI, in a QObject ,named m_arm, that is within a QApplication, named ArmApp. It is created within the constructor of m_arm:

         arm::arm():QObject()
         {   
             COMRPI=new QSerialPort("COM7");
             COMRPI->setBaudRate(115200);
             COMRPI->setDataBits(QSerialPort::Data8);
             COMRPI->setParity(QSerialPort::NoParity);
             COMRPI->setStopBits(QSerialPort::OneStop);
             COMRPI->setFlowControl(QSerialPort::NoFlowControl);
             if(!COMRPI->open(QSerialPort::ReadWrite))
             {
                 qDebug()<<"Error ocured while opening COMRPI:"<<COMRPI->errorString()<<"Crash expected, deleting arm content to prevent most of memory leak.";
                 delete COMRPI;
                 delete m_hand;
             }
             else
             {
                 std::cout<<"COMRPI is supposed to be operational."<<std::endl;
             }
         }
        

        After that, I'm running a function, member of ArmApp, named connectEverything:

        void ArmApp::connectEverything()
        {
           QObject::connect(this->m_controlWindow->ui->Actualisethearm,&QPushButton::pressed,this,&ArmApp::actualisationOfTheArm);
           QObject::connect(this->m_arm->COMRPI, &QIODevice::readyRead, this->m_arm, &arm::SerialPortReceiving);
           QObject::connect(this->m_arm, &arm::readingCompleted, &arm::InterpretingIncommingData);
        }
        
        

        The slot SerialPortReceiving is simply reading all that is present in the buffer and putting it in a string called m_buffe and InterpretingIncommingData, far from being complete, is just printing out m_buffer:

        void arm::SerialPortReceiving()
        {
            std::string NewData(COMRPI->readAll());
            m_buffer+=NewData;
            COMRPI->clear(QSerialPort::Input);
            emit readingCompleted();
        }
        void arm::InterpretingIncommingData()
        {
            std::cout<<m_buffer<<std::endl;
        }
        

        There is a widget with a push button, named actualisatethearm, emitting a signals that triggered the slot ActualisationOfTheArm, that is actually sending " EDFR/r" to the raspberry pi:

        oid ArmApp::actualisationOfTheArm()
        {
            //code of the actualisation
            std::cout<<"The arm is actualy being actualisate."<<std::endl;
            m_arm->COMRPI->write("EDFR\r");
        }
        

        Knowing that (Good point):
        -I'm able to receive the right message with the pi coming from the pc.
        -I'm able to receive the right message with the pc from the pi.
        -Everything, but the following issue, seems to work fine.

        Why is the message sent from the pc to the pi ( EDFR/r) triggered readyRead() signals, which is followed by the integration of a sent message that could compromised the received command?

        The integrity of the code implying the serial port is there, but don't mind to ask if you think that something required to a good understanding of this problems is missing.

        J Offline
        J Offline
        J.Hilk
        Moderators
        wrote on 15 Feb 2019, 05:22 last edited by
        #3

        @Factao

        Why is the message sent from the pc to the pi ( EDFR/r) triggered readyRead() signals, which is followed by the integration of a sent message that could compromised the received command?

        maybe the pi is set to echo mode as well, und sends back all received packages, a common debug option.


        Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct


        Q: What's that?
        A: It's blue light.
        Q: What does it do?
        A: It turns blue.

        F 1 Reply Last reply 16 Feb 2019, 00:50
        6
        • J J.Hilk
          15 Feb 2019, 05:22

          @Factao

          Why is the message sent from the pc to the pi ( EDFR/r) triggered readyRead() signals, which is followed by the integration of a sent message that could compromised the received command?

          maybe the pi is set to echo mode as well, und sends back all received packages, a common debug option.

          F Offline
          F Offline
          Factao
          wrote on 16 Feb 2019, 00:50 last edited by
          #4

          @aha_1980 I'm expecting to read and write data with a serial port, but, for some reason, the data sent by my pc is also read by my pc, so the problems is that the data sent is somehow triggering the readyRead signals.

          @J-Hilk I noticed that ,effectively, the echo wasn't turned off on the pi. For whatever reason, it completely broke my programs when I'm turning it of, so I'm going to install qt and try again on the pi before calling it a win.

          1 Reply Last reply
          0

          3/4

          15 Feb 2019, 05:22

          • Login

          • Login or register to search.
          3 out of 4
          • First post
            3/4
            Last post
          0
          • Categories
          • Recent
          • Tags
          • Popular
          • Users
          • Groups
          • Search
          • Get Qt Extensions
          • Unsolved