Как разрулить потоки

[Sphynx]

Ну вот собственно вы тоже пришли к такому-же выводу, что нужно дать поработать другим потокам. так вот как это сделать ?

[Old]

Ну вот собственно вы тоже пришли к такому-же выводу, что нужно дать поработать другим потокам. так вот как это сделать ?

Стоп.
Все что вы хотите сделать легко делается в одном потоке с GUI. Все делается асинхронно - на сигналах, главное нигде не делать sleep, что-бы неблокировать цикл обработки событий.

[Bepec]

Да создайте вы поток, в нём создайте порт и вытяните из него:
1) сигнал readyRead(QByteArray). (подцепиться к сигналу порта readyRead, в приватном слоте вытаскивать QByteArray данные и отправлять данным сигналам)
2) слот send(QByteArray). (Пихать полученный массив в порт)
А потом спокойно работайте.

Запрашивать через send, ответы получать через readyRead.

[Sphynx]

Я не особо программист, и это моя первая программа на С++, раньше писал только на асме для мк.
Мне кажется я так и сделал как вы написали. Расскажу чуть подробней.
Создал класс MCU через который предполагается вести весь обмен с устройством.
Реализовал функции Send() и Read().
С интервалом по таймеру:

Код

C++ (Qt)
mcu->send("команда");
if (mcu->read()==m_ok)
    {
    //тут вывожу результат
    }
 

Так вот по таймеру все работает. Но сделал тоже самое по нажатию на кнопку и обнаружил что mcu->read() вызывается дважды, что портит правильный прием данных.

[Old]

Я не особо программист, и это моя первая программа на С++, раньше писал только на асме для мк.
Мне кажется я так и сделал как вы написали. Расскажу чуть подробней.
Создал класс MCU через который предполагается вести весь обмен с устройством.
Реализовал функции Send() и Read().
С интервалом по таймеру:
mcu->send("команда");
if (mcu->read()==m_ok)
    {

    }

Если вы хотите работать синхронно, то воспользуйтесь методом:
bool QSerialPort::waitForReadyRead(int msecs)
для ожидания появления данных от устройства. Этот метод ждет указанный интервал времени и возвращает true, если данные пришли (и их можно читать) или false - если время истекло.

[Sphynx]

Ожидание данных реализовано внутри функции Read, и если данные не придут функция вернет m_timeout.

[Old]

Ожидание данных реализовано внутри функции Read, и если данные не придут функция вернет m_timeout.

При синхронном варианте нельзя нормально организовать отсылку запросов как от таймера, так и от кнопки GUI.
Отправляйт запрос и ждите сигнала readyRead, а в слоте обработчике читайте ответы.

[Sphynx]

Тогда это портит всю картину ) Получается перед каждым вызовом mcu->Read я должен проверять какие-то флаги готовности. По идее это все должно происходить внутри самой mcu->Read, иначе какой тогда смысл от всего этого бреда с ооп и классами )

[Bepec]

Этот бред придуман для асинхронности и прочих полезных плюшек. А Qt добавляет отсутствие головной боли и синхронизации потоков.

[Old]

Тогда это портит всю картину ) Получается перед каждым вызовом mcu->Read я должен проверять какие-то флаги готовности. По идее это все должно происходить внутри самой mcu->Read, иначе какой тогда смысл от всего этого бреда с ооп и классами )

Да не нужно ничего проверять. Вот kuzulis привел пример кода.
Если у вас устройство может не вернуть ответ на некоторые запросы, то достаточно хранить очередь запросов и проверять пришел на него ответ или сработал таймаут. Это все хорошо прячется в классе устройства (то самое ООП).

[Sphynx]

В приведенном примере внутри принимаемого пакета должна хранится информация о запросе, иначе не разобрать на что это был ответ. У меня этого нет, т.е. на отправленную команду может прийти просто "ОК", поэтому нужно следить за последовательностью сообщений.

[Old]

В приведенном примере внутри принимаемого пакета должна хранится информация о запросе, иначе не разобрать на что это был ответ. У меня этого нет, т.е. на отправленную команду может прийти просто "ОК", поэтому нужно следить за последовательностью сообщений.

Да, очередь запросов позволит это легко отслеживать. Вместо прямой отправки запроса в устройство, он помещается в очередь. Далее запросы отправляются из очереди, после отправки запускается таймер таймаута и ждем, что придет раньше. Если сигнал readyRead читаем ответ, если таймаут - сообщаем об ошибке. Дальше удаляем из очереди текущий запрос и переходим к следующему.

[Sphynx]

Хорошо, допустим я сделал очередь из запросов. Вот сработал таймер и отправил свой запрос в очередь внутри класса mcu. Теперь нам нужно из класса mcu достать полученный ответ, какой функцией ? Я вызываю mcu->Read(), которая сама читает порт, отслеживает таймауты и следит за ошибками. Но вот пользователь нажимает кнопку, снова отправляется запрос в очередь и нам опять нужно доставать ответ mcu->Read(). Функция все-равно может быть вызвана дважды, очередь запросов не решает проблему.

[Bepec]

Вы немного не догоняете механики. Он не отправляет запрос, а помещает его в очередь. А там уже менеджер, выждав таймаут ответа от текущего(или получив ответ), отправит его следующим.

Вы держитесь за свою ущербную схему с таймером. А мы предлагаем вам перейти на асинхронную работу по сигналам.

[Old]

Хорошо, допустим я сделал очередь из запросов. Вот сработал таймер и отправил свой запрос в очередь внутри класса mcu. Теперь нам нужно из класса mcu достать полученный ответ, какой функцией ? Я вызываю mcu->Read(), которая сама читает порт, отслеживает таймауты и следит за ошибками. Но вот пользователь нажимает кнопку, снова отправляется запрос в очередь и нам опять нужно доставать ответ mcu->Read(). Функция все-равно может быть вызвана дважды, очередь запросов не решает проблему.

Если завтра минутка появится набросаю я вам рабочий примерчик.