Russian Qt Forum

Использую QextSerialPort для работы с COM портом.
Есть клсс PortListener у него есть
такой слот

C++ (Qt)
void PortListener::onReadyRead()
{
    emit DataRead(port->readAll());
}

Который связан таким образом с QextSerialPort.

C++ (Qt)
connect(port/*QextSerialPort*/, SIGNAL(readyRead()), this, SLOT(onReadyRead()));

Также генерирует сигнал DataRead собственно с данными полученными по COM порту.
На другом концу весит некий девайс с которым нужно общаться по определенному протоколу.

А теперь собственно вопрос.
Как лучше всего(и правильнее) реализовать взаимодействие с ним.

Щас у меня так сделано(скорее всего это очень криво)

C++ (Qt)
 
void MainWindow::on_Sync_clicked()
{
    ui->Sync->setEnabled(false);
    PortSettings comPortSettings;
    comPortSettings.BaudRate=BAUD9600;
    comPortSettings.DataBits=DATA_8;
    comPortSettings.FlowControl=FLOW_OFF;
    comPortSettings.Parity=PAR_NONE;
    comPortSettings.StopBits=STOP_1;
    listener->open(ui->comPorts->currentText(),comPortSettings);
    listener->SendCommand(QByteArray(512,0x00));
 
}
void MainWindow::DataRead(const QByteArray& data) // слот которые соединен с сигналом DataRead у PortListener
{
  qDebug(data);
  QByteArray buf=data.toHex();
  switch(state)
    {
    case NOTSYNCKED:
      {
        if(buf.contains("0d0a3e")) {
            state=SYNCKED;
            listener->SendCommand(QByteArray::fromHex("4200c20100"));
            Sleep(300);
            listener->setBaudRate(BAUD115200);
            listener->SendCommand(QByteArray::fromHex("0d"));
 
          }
        break;
      }
    case SYNCKED:{
        if(buf.contains("0d0a3e")) {
            state=READY;
            SendBinary("fw.bin");
            Run();
          }
      }
 
    default:
      break;
    }
}
 

Что хотелось бы, чтобы была возможность и асинхронно работать и при этом оставить возможность синхронной работы.
например чтобы можно было сделать вот так(как еще один вариант)

C++ (Qt)
void MainWindow::on_Sync_clicked()
{
    ui->Sync->setEnabled(false);
    PortSettings comPortSettings;
    comPortSettings.BaudRate=BAUD9600;
    comPortSettings.DataBits=DATA_8;
    comPortSettings.FlowControl=FLOW_OFF;
    comPortSettings.Parity=PAR_NONE;
    comPortSettings.StopBits=STOP_1;
    listener->open(ui->comPorts->currentText(),comPortSettings);
    listener->SendCommand(QByteArray(512,0x00));
QEventLoop eventLoop;
    connect( listener->port,SIGNAL(onReadyRead()),&eventLoop, SLOT(quit()));
    eventLoop.exec();
 listener->SendCommand(QByteArray::fromHex("4200c20100"));
            Sleep(300);
            listener->setBaudRate(BAUD115200);
            listener->SendCommand(QByteArray::fromHex("0d"));
}

Sleep в основном потоке детектед. Ну что сказать - учи потоки :D

Да да Sleep, но тут эта функция выполняеться один раз.
Но собственно я по этом тоже справшивал как бы организовать синхронную работу)

Юзать отдельный поток для работы с портом

C++ (Qt)
Юзать отдельный поток для работы с портом

И чем это поможет? (я имею введу что мне это даст, я правда хочу понять)

ты замораживаешь главный поток слипом, что есть плохо, от этого надо избавляться. Ибо все это время (да, пока что небольшое) приложение выглядит зависшим

Краткий ликбез. Ибо я ем кильку в томатном соусе и добр.

Поток - это там где исполняются твои команды.
У каждого приложения минимум 1 поток.
Именно 1 поток отрисовывает ГУИ(интерфейс).
Но если 1 будет рисовать, а второй работать с портом ПАРАЛЛЕЛЬНО, это же лучше 1? :)

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

А чем оно "лучше"? Только тем что "так часто делают"?  :)

Так или иначе приходится ждать "ответа с той стороны" - наверное под синхронностью понимается "модальность" этого ожидания, типа дождались и потом продолжаем заниматься свои делом. Тогда можно действовать через QApplication::processEvents - и подобрать нужный флажок-параметр. А sleep конечно плохо

Если много рисовать, или ждать. То 1 поток это плохо :D Это аксиома, подтверждения не требующая :D

Не спорю, в 1 поток создать работоспособную прекрасную программу возможно. Но позже вылезают обидные косячки :D

Один тут давеча тоже выдвигал аксиомы - у него подучились?  :)

Насколько я понял, человек спрашивает не об этом. Лучше ли читать в др нитке - но то уже др вопрос. А спрашивалось как не отдавать управление, тут без разницы в какой нитке читатель, все равно придется крутить вторичный цикл

Igors не забываем - каждый советует так, как сам бы поступил :D

Способов реализации - море. Я выбираю несколько потоков.

Что даст - возможность работать с портом "без оглядки" на отображение. Синхронность или асинхронность сам определишь :)

Что даст реализация без потоков на таймерах - хз. Даст реализацию работы с портом без потоков :D

А никто еще не посоветовал использовать QtSerialPort (http://qt-project.org/wiki/QtSerialPort_Russian) вместо QextSerialPort, т.к. последний имеет очень кривую архитектуру. :)

И если будешь использовать QtSerialPort - то никакие потоки не нужны.

QtSerialPort вроде под Qt 5.0 пишется. И ещё в процессе разработки, не?

Я лично использую свою самописную библиотечку - ибо все имеющиеся для qt (типа Qext и прочая) жутко глючили и хреново передавали :D

под 4.7.4 тоже робит ) И отлично так робит, зуб даю :)

А ты почитай по ссылке что я дал, и все узнаешь  :)

Сколько всего на отвечали))
1) Спасибо за ссылку на QtSerialPort посмотрю что да как.
2) По поводу Sleep это просто была временная заглушка.
3) Объясните пожалуйста как(и чем) помогли бы дополнительные потоки в работа частично синхронно, а частично асинхронно.
Грубо говоря мне вначале надо выполнить синхронно некоторую инициализацию на стороне девайся, а потом я бы хотел асинхронно кидать и ловить от него сообщения.

Порт работает асинхронно так то, но программно ты можешь что угодно написать. Флаги/стражи в вперёд.

Уже пояснял:


Если это не понятно, то запусти Тотал коммандер. И попытайся скопировать какой-нить большой файл. И у тебя будет открыт второй поток, который отрисует окошечко для копирования, который ты можешь остановить/притормозить/перемещать, независимо от основного потока.

Да понимаю я что-такое поток.
Щас объясню что непонятно.

У нас есть функция записи в порт. У нас есть слот который вызваться когда нам приходят данные. Они работаю асинхронно, это понятно.
Дальше если мы будем ждать в on_Sync_clicked() когда нам придет что-то в порт, то понятно что мы этого некогда не дождемся, так-как у нас один поток.
Это все понятно.
Не доконца ясно почему нам помогает QEventLoop(точнее вот эта конструкция

C++ (Qt)
QEventLoop eventLoop;
    connect( listener->port,SIGNAL(onReadyRead()),&eventLoop, SLOT(quit()));
    eventLoop.exec();

), eventLoop же не создает отдельного потока(почему он может получить сигнал onReadyRead())
Понял почему, он запускает цикл ожидания события.

Дальше из этого всего вытикает вопрос, как делать синхронно, Я так понимаю вы предлагате такую вещь,
Мы переносим класс PortListener в отдельный поток, в функции MainWindow::on_Sync_clicked()(в которой нам нужно поработать синхронно) мы расставляем например мютексы(тут опять вопрос, медь если мы там поставим мютекс то GUI поток зависнит, и как нам ждать результат )

Еще раз я понимаю что-такое потоки, но не понимаю как ОНИ НАМ ПОМОГУТ.
Можете описать что в каждом потоке вы предлагате мне сделать.

Ну так если не нравится - никто не мешает "проиктировать" самому  :)

Очень даже дождемся если будем ждать примерно так

C++ (Qt)
// какие-то действия, напр инициализация
connect( listener->port,SIGNAL(onReadyRead()),&eventLoop, SLOT(quit(), Qt::QueuedConnection));
...
while (true) {
 QApplication::processEvents(..);
 ..
 if (flagQuit) break;
}
// продолжаем делать что хотели
 

Сигнал с QueuedConnection - это event которое придет в свой eventLoop (в данном случае главной нитки) если мы скажем ему обрабатывать события (processEvents). Надо только в слоте quit его опознать, (напр взвести флажок) чтобы "вытикать" из цикла while  :)

Уважаемый a1ien. Вы знаете определение потока. Вы молодец :)

Но вы видимо слабо знаете сигнал-слотовую архитектуру и межпотоковое взаимодействие. Советую их вам подучить, а так же почитать Бланшета.

Bepec, вы типичный троль с вами общаться даже не хочеться.

Igors,
Это наоборот было в позитивном ключе сказано, то есть я только рад что много ответов.
Спасибо большое вам а ваши ответы они дают направление куда стоит копать.

C++ (Qt)
// какие-то действия, напр инициализация
connect( listener->port,SIGNAL(onReadyRead()),&eventLoop, SLOT(quit(), Qt::QueuedConnection));
...
while (true) {
 QApplication::processEvents(..);
 ..
 if (flagQuit) break;
}
// продолжаем делать что хотели

Я так понимаю что это почти тоже самое, что и мой код с

C++ (Qt)
QEventLoop eventLoop;
    connect( listener->port,SIGNAL(onReadyRead()),&eventLoop, SLOT(quit()));
    eventLoop.exec();

Просто другая реализация, а нету более красивого примера с идеологической точки зрения?)

С идеологической все это "вторичный цикл событий", который широко используется, и это нормальная практика. Однако запускать свой локальный eventLoop обычно невыгодно, т.к. UI остается замороженным, приходится прилагать усилия чтобы прервать операцию и.т.п. Практичнее создать локальный объект, у него слот, он и получит сигнал в текущем eventLoop.

Спасибо большое. Вопрос можно считать закрытым.

И тут троллем обзывают :D

Видимо что-то с кармой, или с желанием спрашивающих узнать ответ на свой вопрос :)