Sequential work with the port

[maratk1n]

did I misunderstand?

Not certainly in that way.
In fact, device->open()/close() is just the emission of a signal. I emit a signal switchStateSig, then the slot switchState in the thread of the device is called. I do not control this, I just go further in the thread of the algorithm.
I can not call directly, because the device and the algorithm are in different threads, so I had to connect them with a signal and a slot.
This should work like this: from the thread of the algorithm, I call the open/close of the device, I wait for an answer, and only then I go further. Now I just emit a signal and, without waiting for an answer, I go forward. This is very bad. This is the first problem.

The second problem is that the function waitForReadyRead() unpredictably breaks the whole program. I tried to do this, but I did not get a single byte. Apparently, something is blocked:

void ms_delay(int ms){
    QElapsedTimer ms_timer;
    ms_timer.start();
    while(ms_timer.elapsed() < ms){}
    return;
}
 
QByteArray ComPort::requestResponse(const QByteArray &data)
{
    mutex->lock();
    qDebug() << "-------------------------";
    if(!serial->isOpen())
        open();
    int attempts = 1;
    QElapsedTimer waitTimer;
    readBuf.clear();
    while (attempts <= 3) {
        if (serial->isWritable())
        {
            serial->write(data);
            waitTimer.restart();
            while (waitTimer.elapsed() < 333){
                ms_delay(5);
                readBuf += serial->readAll();
                if (readBuf.size() == 4){
                    close();
                    mutex->unlock();
                    return readBuf;
                }
            }
            readBuf.clear();
            qDebug() << "Timeout...";
            close();
            open();
            attempts++;
        }
        else
        {
            qDebug() << "Port is not written";
            close();
            mutex->unlock();
            return 0;
        }
 
    }
    close();
    mutex->unlock();
    return 0;
}

void ms_delay(int ms){
    QElapsedTimer ms_timer;
    ms_timer.start();
    while(ms_timer.elapsed() < ms){}
    return;
}

QByteArray ComPort::requestResponse(const QByteArray &data)
{
    mutex->lock();
    qDebug() << "-------------------------";
    if(!serial->isOpen())
        open();
    int attempts = 1;
    QElapsedTimer waitTimer;
    readBuf.clear();
    while (attempts <= 3) {
        if (serial->isWritable())
        {
            serial->write(data);
            waitTimer.restart();
            while (waitTimer.elapsed() < 333){
                ms_delay(5);
                readBuf += serial->readAll();
                if (readBuf.size() == 4){
                    close();
                    mutex->unlock();
                    return readBuf;
                }
            }
            readBuf.clear();
            qDebug() << "Timeout...";
            close();
            open();
            attempts++;
        }
        else
        {
            qDebug() << "Port is not written";
            close();
            mutex->unlock();
            return 0;
        }

    }
    close();
    mutex->unlock();
    return 0;
}

To copy to clipboard, switch view to plain text mode 

[high_flyer]

So let me see if I understand:
Calling the QDevice::waitForReadRead() is not relible on windows, so you don't call it and want to have some other function to call instead that delivers the same functionality.
Is that correct?
(All the story around it, how things in other threads are, are not the problem, more the motivation, as far as I can see)

If so, did you try what I offered in my last post, and if you did, what was the problem?

[maratk1n]

Is that correct?

Yes that's right. This is problem number 1. I have not tried your method yet, because no access to the board. I would like to monitor the reception with time, because if my request does not reach board for some reason, she will not answer me, no matter how much time I wait. For this reason, I make repeated requests after the timeout.

All the story around it, how things in other threads are, are not the problem, more the motivation, as far as I can see.

I can not say with certainty. But I tried to call directly device->switchState(7, true); from algorithm, which got the error that you can not call the methods of another thread, being not in the main thread. Therefore, I connected them with signals.

[high_flyer]

because if my request does not reach board for some reason, she will not answer me, no matter how much time I wait. For this reason, I make repeated requests after the timeout.

or you can set a timeout as well.

[maratk1n]

or you can set a timeout as well.

So, how can I do this?..

[high_flyer]

So, how can I do this?..

there are several ways...
Probably the least "intrusive" would be to have a timer run and you can check the elapsed time in your while() loop where you are checking the available bytes from the serial device.
Once the timeout is reached you simply return from your custom waitForReadRead() with false.

[maratk1n]

there are several ways...
Probably the least "intrusive" would be to have a timer run and you can check the elapsed time in your while() loop where you are checking the available bytes from the serial device.
Once the timeout is reached you simply return from your custom waitForReadRead() with false.

Thank for you answer. But I already tried to do this way, the port "was silent".
http://www.qtcentre.org/threads/6904...574#post301574

[high_flyer]

Thank for you answer. But I already tried to do this way, the port "was silent".

Do you mean by that the the port didn't answer within the time you specified?
If yes, then try prolonging the timeout.

[maratk1n]

Do you mean by that the the port didn't answer within the time you specified?
If yes, then try prolonging the timeout.

I tried to increase. Ping using the function waitForReadRead() was 2-5 milliseconds. With the use of a timer, the board absolutely did not answer anything for 333 milliseconds and more. I concluded that data reception is somehow blocked.