I have issue with reading and writing from/to QSerialPort. I read what I have written. Here is some example code that proves that. Maybe I need to write and read from different channels. Code's provided below thx in advance. Provided log of the program with image.
Log of the program here
MainWindow.h
#ifndef MAINWINDOW_H
#define MAINWINDOW_H
#include <QMainWindow>
#include <QSerialPort>
#include <QTimer>
#include <QDebug>
class MainWindow : public QMainWindow
{
Q_OBJECT
public:
MainWindow(QWidget *parent = 0);
~MainWindow();
private:
QSerialPort *serialPort;
QTimer* sendTimer;
QByteArray receiveDataBuffer;
private slots:
void onReadyRead();
void onSendDataTimeout();
};
#endif // MAINWINDOW_H
MainWindows.cpp
#include "mainwindow.h"
MainWindow::MainWindow(QWidget *parent)
: QMainWindow(parent),
serialPort(new QSerialPort),
sendTimer(new QTimer)
{
sendTimer->setInterval(1000);
serialPort->setPortName("COM5");
serialPort->setBaudRate(QSerialPort::Baud115200);
serialPort->setParity(QSerialPort::Parity::NoParity);
serialPort->setDataBits(QSerialPort::DataBits::Data8);
serialPort->setStopBits(QSerialPort::StopBits::TwoStop);
serialPort->open(QSerialPort::OpenModeFlag::ReadWrite);
connect(serialPort,&QSerialPort::readyRead,this,&MainWindow::onReadyRead);
connect(sendTimer,&QTimer::timeout,this,&MainWindow::onSendDataTimeout);
sendTimer->start();
}
MainWindow::~MainWindow()
{
}
void MainWindow::onReadyRead()
{
receiveDataBuffer.append(serialPort->readAll());
if (receiveDataBuffer.contains('^') && receiveDataBuffer.contains('$') && receiveDataBuffer.lastIndexOf('$') < receiveDataBuffer.lastIndexOf('^')) {
QByteArray extractedByteArray;
for(int i = receiveDataBuffer.lastIndexOf("$") ; i < receiveDataBuffer.lastIndexOf("^") + 1 ; i++){
extractedByteArray.append(receiveDataBuffer[i]);
}
qDebug()<<"Received:"<<extractedByteArray<<endl;
receiveDataBuffer.clear();
}}
void MainWindow::onSendDataTimeout()
{
qint64 result = serialPort->write("$10,0,123,123^");
bool flush = serialPort->flush();
result != -1 && flush ? qDebug()<<"Data sent"<<endl:qDebug()<<"Failed to send data"<<endl;
}
main.cpp
#include "mainwindow.h"
#include <QApplication>
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindow w;
w.show();
return a.exec();
}
First of all, try to connect the different signals that are emitted when you read/write that from your port.
For instance to check that the data has been sent properly, according to the documentation you can use the signal QIODevice::bytesWritten:
The signal is emitted every time a payload of data has been written to the device's current write channel. The bytes argument is set to the number of bytes that were written in this payload.
connect(serialPort,&QSerialPort::bytesWritte, this, [](const qint64 bytes) {
qDebug() << "Sent data: " << bytes << " bytes.";
});
To read the data, as you already did, you need to check the QIODevice::readyRead signal:
This signal is emitted once every time new data is available for reading from the device's current read channel. It will only be emitted again once new data is available, such as when a new payload of network data has arrived on your network socket, or when a new block of data has been appended to your device.
Regarding the problem you described, the first step to do is to ensure that your decive has not been configured to work in echo-mode. To turn it off, you will need to check your device interface.
If this is not the problem, check the available ports by using `QSerialPort::availablePorts and ensure that you are connecting to the right one. For example, to connect to the first port, you can do something like this and check that the configuration is compatible with your device:
auto serialInfo = QSerialPortInfo::availablePorts();
serialPort->setPort(serialInfo[0])
auto ret = serialPort.open(QSerialPort::ReadWrite)
&& serialPort.setBaudRate(QSerialPort::Baud38400)
&& serialPort.setDataBits(QSerialPort::Data8)
&& serialPort.setStopBits(QSerialPort::OneStop)
&& serialPort.setParity(QSerialPort::NoParity);
qDebug() << "Port has been configured properly?: " << ret;
If the problem persist, you can get the native handler and modify its properties by calling QSerailPort::handle().
If the platform is supported and the serial port is open, returns the native serial port handle; otherwise returns -1.
The last option, it does not work in all platforms. Worse scenario, take a look into the official docs of termios. It provides a low-level interface that allows you to enable/disable the echo mode.
struct termios options;
tcgetattr(file, &options);
cfmakeraw(&options);
options.c_lflag &= ~(ECHO | ECHOE); // Add or disable the flags
tcsetattr(file, TCSANOW, &options);
The problem was in
serialPort->setStopBits(QSerialPort::StopBits::TwoStop);
The other device was connected to serial port with QSerialPort::StopBits::OneStop.
So changing the stop bits serialPort->setStopBits(QSerialPort::StopBits::OneStop);
solved the problem and there were no echoes anymore.Thx.
Related
i am making a Tail Log application. It is executing perfectly but the output window is not showing any results.
Below is the code:
LogTail.cpp
#include "logtail.h"
#include <QApplication>
#include <QTextEdit>
#include<QDebug>
//start id=constructor
LogTail::LogTail(QString fn) {
//if (fn == QString()) {
// fn = "C:/Users/arpit.k/OneDrive - Accord Software & Systems Pvt. Ltd/Documents/QT/LogTail3/sample.log";
// }
connect (this, SIGNAL(readyReadStandardOutput()),
this, SLOT(logOutput())); /* When there is input ready, call this slot.*/
QStringList argv;
argv << "-f" << fn; /* tail -f filename */
start("tail", argv); /* Returns immediately, and now there is a child process running, "attached"
to this process. When this process exits, the child tail process will also terminate. */
}
LogTail::~LogTail() {
terminate(); /* Attempts to terminate this process. */
}
//end
//start id=logOutput
// tail sends its output to stdout.
void LogTail::logOutput() { /* Slot called whenever there is input to read. */
QByteArray bytes = readAllStandardOutput();
QStringList lines = QString(bytes).split("\n");
foreach (QString line, lines) {
//qDebug() << line;
emit logString(line);
}
}
//end
main.cpp
#include "logtail.h"
#include <QTextEdit>
#include <QApplication>
int main (int argc, char* argv[]) {
QApplication app(argc, argv);
QStringList al = app.arguments();
QTextEdit textEdit;
textEdit.setWindowTitle("Debug");
textEdit.setWindowTitle("logtail demo");
QString filename = "sample.log";
if (al.size() > 1) filename = al[1];
LogTail tail(filename); /* Create object, starts process too. */
tail.connect (&tail, SIGNAL(logString(const QString&)),
&textEdit, SLOT(append(const QString&)));
textEdit.show();
return app.exec();
}
Note: sample.log file contains some log data
Output window doesn't show any logs:
(https://i.stack.imgur.com/ENhqs.png)
I need it to display recent 10 Log lines!
Assuming you are subclassing from QProcess (you should post a complete minimal example in order to get an accurate answer).
You are starting the process in the constructor of LogTail, 'tail' will probably output some data or some events that will trigger readyReadStandardOutput before you have the chance to connect the signal in the main function.
readyReadStandardOutput will be triggered only once as you never cleared the input buffer (you never had the chance to read the available data).
So in order to make your example work you should call logOutput after you start the process.
Anyway I will suggest you to implement differently, I would call start from outside or at least outside the constructor, that way your object will be more scalable.
I have used Qt with an Arduino UNO to build a data acquisition system. Now I want to migrate that to Qt with an AVR ATmege32u4 microcontroller.
Please look at the code below. I am reading incoming serial data with Qt triggered by the ReadyRead signal, then printing those data to the Qt debug window. This works fine with Qt+UNO, but not Qt+32u4. I rule out any problems with the 32u4 (e.g. bad chip) because the data are printed fine to the serial port monitor in the Arduino IDE.
My questions are:
(1) why does the program work for one AVR device and not the other?
(2) how can I make the program work for the 32u4 microcontroller?
Arduino code (simplified to highlight the problem):
void setup(){
Serial.begin(115200);
while(!Serial){}
}
void loop(){
// wait for incoming serial data from Qt (code not shown)
// record data
// send data back. In this example, send back some text: "abababab"
for(unsigned int i=0;i<4;i++){
Serial.write{0x61}; // "a"
Serial.write{0x62}; // "b"
}
}
Relevant Qt code:
#include "mainwindow.h"
#include "ui_mainwindow.h"
#include <QString>
#include <QDebug>
#include <QStringList>
#include <QtSerialPort>
#include <QDataStream>
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
microcontroller = new QSerialPort(this);
// initialize the serial port (baud rate, parity etc.)
connect(microcontroller, &QSerialPort::readyRead, this, &MainWindow::readData);
void MainWindow::readData(){
serialData += microcontroller->readAll();
qDebug() << serialData;
}
You can't open the same COM port twice. If it is open by the Arduino IDE, it won't work on your Qt app.
Also, you should post a MCVE. It's hard to tell what could be wrong if you don't show us the code.
I have a modal dialog called by:
qDebug() << "Creating LoginStatusDialog";
dlgConnectStatus = new LoginStatusDialog(login, key, auth);
qDebug() << "Done LoginStatusDialog, setting modal";
dlgConnectStatus->setModal(true);
qDebug() << "Done setting modal, executing";
int res = dlgConnectStatus->exec();
qDebug() << "dlgConnectStatus result = " << QString::number(res);
//see below for debug info and output
This calls a custom constructor which executes this below
LoginStatusDialog.cpp (extract):
LoginStatusDialog::LoginStatusDialog( QString _login, QString _key, QString *_auth_tok, QWidget *parent) :
QDialog(parent), ui(new Ui::LoginStatusDialog), login(_login), key(_key)
{
ui->setupUi(this);
Return_Object = new ReturnObject(ReturnCode::netcon_LoginSuccess, QString(""));
if (Return_Object->getCode() == ReturnCode::netcon_LoginSuccess) {
qDebug() << "pre close";
close();
//accept - hangs
//done(0); - hangs
qDebug() << "post close";
}
}
LoginStatusDialog header
#ifndef LOGINSTATUSDIALOG_H
#define LOGINSTATUSDIALOG_H
#include <QDialog>
#include <QtCore>
#include <QtGui>
#include <QtWidgets>
#include <thread>
#include "returnobject.h"
#include "datamanager.h"
namespace Ui {
class LoginStatusDialog;
}
class LoginStatusDialog : public QDialog
{
Q_OBJECT
public:
// explicit LoginStatusDialog(QWidget *parent = 0);
LoginStatusDialog( QString _login, QString _key, QString *_auth_tok, QWidget *parent = 0);
~LoginStatusDialog();
private:
Ui::LoginStatusDialog *ui;
QString login, key;
ReturnObject *Return_Object;
void initGui();
};
#endif // LOGINSTATUSDIALOG_H
Debug info
Debugging starts
Creating LoginStatusDialog
pre close
post close
Done LoginStatusDialog, setting modal
Done setting modal, executing
//remains open
By doing some research, several SO posts refer to using done(), close(), accept() to close the dialog
Using a CONNECT() uses the close() method to close the dialog, but attempting to manually close it has no success.
It was suggested to use a timer task, but that just does not seem like the actual way to close the dialog.
Any thoughts?
This seems more like a general design issue. If you truly want it done that way you could use a timer. But a simple redesign may be more helpful.
If you only want the dialog to be shown when an error occurs why not only show it only then?
Return_Object = new ReturnObject(ReturnCode::netcon_LoginSuccess, QString(""));
if (Return_Object->getCode() != ReturnCode::netcon_LoginSuccess)
{
dlgConnectStatus = new LoginStatusDialog(Return_Object);
dlgConnectStatus->setModal(true);
int res = dlgConnectStatus->exec();
//...
}
This way, the dialog who is responsible for only showing the information will only do this. Show the login error. It just seems like a design flaw for creating a dialog then immediately closing it (especially considering that the good case should be your default case).
If you have extra things the Dialog is doing you should consider how much of that code really needs to be in a class intended to be for showing information.
Calling close from constructor is wrong, cause your dialog is showing after constructor ends, so your check can't close dialog, that wasn't showed. You need to call close after(in) QDialog::showEvent. Or, just as I say in your first theme - you can use timer loop.
I use the following code to talk to a USB-serial port device:
#include "masterthread.h"
#include <QtSerialPort/QSerialPort>
#include <QTime>
#include "Windows.h"
#include "Psapi.h"
#include <QDebug>
QT_USE_NAMESPACE
MasterThread::MasterThread(QObject *parent)
: QThread(parent), waitTimeout(0), quit(false)
{
}
MasterThread::~MasterThread()
{
mutex.lock();
quit = true;
cond.wakeOne();
mutex.unlock();
wait();
}
void MasterThread::run()
{
bool currentPortNameChanged = false;
QSerialPort serial;
serial.setPortName("COM3");
serial.setBaudRate(57600);
serial.setStopBits(static_cast<QSerialPort::StopBits>(1));
serial.setDataBits(static_cast<QSerialPort::DataBits>(8));
serial.setParity(static_cast<QSerialPort::Parity>(0));
serial.open(QIODevice::ReadWrite);
//Tell the serial port connected device to start talking
//--------------------------------------
const char init[] = { 0x0d, 0x0d, 0x0d };
serial.write(init, sizeof(init));
const char* cmd = "mavlink stop\n";
serial.write(cmd, strlen(cmd));
serial.write(init, 2);
cmd = "uorb start";
serial.write(cmd, strlen(cmd));
serial.write(init, 2);
cmd = "sh /etc/init.d/rc.usb\n";
serial.write(cmd, strlen(cmd));
serial.write(init, 4);
serial.waitForBytesWritten(100);
int i = 0;
int j = 0;
forever
{
//Write test data out
//-----------------------------
QByteArray test(2000, 't');
serial.write(test);
bool check = serial.waitForBytesWritten(100);
if (!check)
{
qDebug() << "FAIL: " << j++;
}
if (serial.waitForReadyRead(20))
{
QByteArray responseData = serial.readAll();
while (serial.waitForReadyRead(10))
responseData += serial.readAll();
QString response(responseData);
qDebug() << response;
}
QThread::msleep(20);
//Print memory usage
//---------------------------------------------------
if (i++ % 10 == 0)
{
PROCESS_MEMORY_COUNTERS memcount;
if (!GetProcessMemoryInfo(GetCurrentProcess(), &memcount, sizeof(memcount))) return;
qDebug()<<"----------------------------" << memcount.WorkingSetSize / 1024 << "KB memory used";
}
} // end foever
qDebug() << "Exiting forever loop";
}
with a simple main.cpp as:
#include <QApplication>
#include "masterthread.h"
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
MasterThread thread;
thread.start();
return app.exec();
}
But the memory usage keeps increasing, like 5~10MB per hour as if there are some leakage.
The device is suppose to be connected for days and weeks...
What am I doing wrong here? I am on Qt5.6 windows7 debug
Many Qt Components have an implicit dependency on its event loop.
While you are starting the main threads event loop with the call to app.exec(); you are not handling events generated by the QObjects created in the QThread MasterThread thread;. The details and nuances of Event handling in Qt are very well described on this page: https://wiki.qt.io/Threads_Events_QObjects#Threads_and_QObjects
But the solution boils down to: if you want to be able to process queued up Qt events in a thread where you are processing some long-running task you should call QCoreApplication::processEvents(); from time to time. This will prevent Qt events from endlessly queueing up.
EDITED after looking on the code Qt 5.7,5.6,5.5 and reading docs.
As an answer is already accepted, I would just add some thoughts here as it's too long for comments.
Keep things short - an answer you accepted is wrong..
There are two sides of the story. And as SO answers often taken 'as it is as long as they work' I'd like to explain myself...
If you look on a code provided - there is nothing wrong with it. All objects are properly stack allocated and should be destroyed automatically.
Point is that QtSerial uses deleteLater() and then a question - how to delete those allocations properly.
If any module/object/code uses deleteLater() it requires an event loop, if deleteLater() called on a thread without event loop, object will be deleted after thread is terminated. As long as there is no event loop running for code above, processEvents will no work.. actually processEvents() is not something which is used for this, because a whole idea to return from the context which is called deleteLater() and have a next run, and that's checked in the Qt Source Code, so calling processEvent() straight after without incrementing loop count will do nothing at all, that's why answer you accepted is totally wrong.
Conclusion:
If any object requires event loop running it should be EXPLICITELY stated in the documentation as there is nothing wrong in using QIODevice in sync mode outside event loop.
So at my opinion,point is - its a bug in the QT Serial itself which I suggest you report.
In general it's really wrong practice for Qt to run never-ending loops..
It's much much better and cleaner to use QObject Worker tactic which is pushed to the thread, have proper even loop running etc.
For small 'threaded' tasks it's much better to use QtConcurrent.
Proper Workaround:
you will have a thread with properly running event loop and a timer firing at 20ms to do your things
// main thread:
class Worker: public QObject {
public:
Worker();
public slots:
onInit() {
// initialize everything
startTimer(20);
}
protected:
void timerEvent(..) {
// do your things every 20ms
}
}
...
QThread * pWorkerThread = new QThread();
pWorkerThread->setObjectName(QString("Serial"));
Worker * pWorker = new Worker();
Worker->setObjectName(QString("Common Storage Impl"));
Worker->moveToThread(WorkerThread);
connect(pWorkerThread, SIGNAL(started()), pWorker, SLOT(onInit()));
connect(pWorkerThread, SIGNAL(finished()), pWorker, SLOT(deleteLater()));
connect(pWorkerThread, SIGNAL(finished()), pWorkerThread, SLOT(deleteLater()));
pWorkerThread->start();
...
I want to use QSerialPort to read data transmitted from a device. The device transmits a frame of 4000 data bytes each time. I try with the following simple code
QSerialPort *serialPort;
char receivedData[4000];
int numRead = 0;
MainWindow::MainWindow(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::MainWindow)
{
ui->setupUi(this);
/* Initialize serial port*/
serialPort = new QSerialPort(this);
QString portName = "COM6";
qint32 baudRate = 460800;
serialPort->setPortName(portName);
serialPort->setBaudRate(baudRate);
serialPort->setDataBits(QSerialPort::Data8);
serialPort->setParity(QSerialPort::NoParity);
serialPort->setStopBits(QSerialPort::OneStop);
serialPort->setFlowControl(QSerialPort::NoFlowControl);
serialPort->setReadBufferSize(4000);
if (!serialPort->open(QIODevice::ReadOnly)) {
qDebug() << "Cannot open comport";
}
connect(serialPort, SIGNAL(readyRead()), this, SLOT(serialReceived()));
}
void MainWindow::serialReceived()
{
numRead = serialPort->read(receivedData, 4000);
serialPort->flush();
}
The problem is: it always shows that only 512 data bytes are read. How can I read the whole 4000 bytes data frame? (when I'm using Matlab to read this 4000 bytes frame, it's working fine)
There's no limit, but you don't necessarily receive all data in single chunk.
You have to keep listening until you have the number of bytes you're waiting for (or a timeout).
void MainWindow::serialReceived()
{
receivedData.append(serialPort->readAll());
if(receivedData.size() >= 4000) {
// we're full
}
}
You generally have to read out the data in a loop (to ensure you get it all), here is a snippet of example code this is equivalent to your serialReceived() function, except it emits the data using emit rxDataReady(newData); to whoever is listening...
void QSerialPortReader::handleReadyRead()
{
QByteArray newData;
// Get the data
while (mp_serialPort->bytesAvailable())
{
newData.append(mp_serialPort->readAll());
}
emit rxDataReady(newData);
}
edit
Although I don't do any max size checking... but that is trivial to add if you need it (i.e. just use read(..., spaceAvail) instead of readAll and then decrement spaceAvail...