Прошу не бить ногами, т.к. с Qt и С++ на вы.
Пишу прогу для связи компа с девайсом (светодиодный дисплей).
Решил пойти по путе наименьшего сопротивления, потому что новичек и в качестве примера использовал консольные reader и writer.
реализовывается протокол по принципу запрос-ответ.
Данные отправляются успешно, а вот считываются совсем наоборот, т.е. не считываются: либо таймаут, либо массив нулевой длины.
Шишку набил уже большую, а вот где грабли не пойму.
QT 4.6.3
QSerialDevice 0.4.1

    this->serial->setDeviceName("COM1");
    this->serial->open(AbstractSerial::ReadWrite | AbstractSerial::Unbuffered);
    this->serial->setBaudRate(AbstractSerial::BaudRate1200);
    this->serial->setParity(AbstractSerial::ParityNone);
    this->serial->setDataBits(AbstractSerial::DataBits8);
    this->serial->setStopBits(AbstractSerial::StopBits1);
    this->serial->setTotalReadConstantTimeout(100);
    this->serial->setFlowControl(AbstractSerial::FlowControlOff);

    QByteArray cmd = "/xED/x01/x02";
    this->serial->writeAll(cmd);
    //Девайс команду глотает, следовательно в порт данные пишутся

    //далее надо узнать что он ответил
    //отдадочный вечный цикл

while (1)
    {
    if ((serial->bytesAvailable()>0) || (serial->waitForReadyRead(5000)))
    {
    QByteArray ba1 = this->serial->readAll();
    qDebug() << "Readed is : " << ba1.size() << " bytes";
    ui->textEdit->insertPlainText(QString(ba1));
}  else
    
    //Независимо от того что и сколько отправлено - попадаю сюда.
    {qDebug() << "Timeout";
    qDebug() << serial->bytesAvailable();}
}

1. Используй QSerialDevice 2.0 http://gitorious.org/qserialdevice/qserial...ive-tarball/2.0
2. Вместо while(1) используй сигналы/слоты.
Для своих целей можешь даже взять сразу пример /tests/guiapp и в нем поотсылать попринимать команды.
А потом, если получится - просто изменишь его или по аналогии сделаешь свое приложение.
3. Поточнее узнай, нужно ли в конце команды отправлять символ '\r' (типа эквивалентно нажатию Enter в терминале).
4. Всегда проверяй возвращаемые значения вызовов open(), setXXX().
5. Не используй AbstractSerial::Unbuffered

Наконец то Nokia клонировала репозиторий QSerialDevice 2.0 в Gerrit!!!

Ура, товарищи! За это не грех хряпнуть!

а что это означает ? )

То, что оно теперь будет как аддон к Qt,
также то, что принадлежит Нокии теперь (вроде) и то, что они будут помогать в развитии.

Вот тут : # git clone ssh://codereview.qt-project.org:29418/playground/qtserialport.git
будет вестись первоначальная разработка и потом, как я понял,
оно будет отсюда коммитится на Gitorious для публичного доступа.

Т.е. доступ к codereview.qt-project.org имеют только те участники, которые зарегистрировались в Gerrit и приняли CLA
они могут коммитить и вносить изменения в проекты.
т.е. теперь на Gitorious MR будут отключены - а вся разработка через Gerrit ведется.

Я сам еще не въехал в весь это процесс, так что пока это все что я понял

Вот тут еще можно почитать.

Сообщение отредактировал kuzulis - 9.2.2012, 10:24

WinXP
Qt 4.8.0
QSerialDevice 2.0

Пытаюсь собрать dll статической сборкой Qt, выдает больше сотни ошибок следующего вида:

release/serialport.o:serialport.cpp:(.text+0x6fb): undefined reference to `_imp___ZN9QIODevice12readLineDataEPcx'
release/serialport.o:serialport.cpp:(.text+0x77c): undefined reference to `_imp___ZNK9QIODevice11canReadLineEv'

C дефолтным Qt'ом все собирается нормально.

Так же необъяснимая проблема с приложением в котором использую библиотеку.
Используя дефолтный Qt все собирается и работает без проблем.
Собираю приложение статически (при чем независимо подсовываю ли я ему нестатически собранный SerialPort.dll, или же статически собранный на Qt4.7) - работает только отправка в порт, но данные с порта никакие не принимаются.

Разбирайтесь сами со статической сборкой. Я ради этого не буду у себя собирать Qt статически.
Используйте дебагер.

kuzulis,

Добрый день. Перешел на QSerialDevice 2.0. Не могу найти аналог setTotalReadConstantTimeout. Как мне теперь можно подождать фиксированное время, перед чтением? Реализовать самому?



Почему Вы советуете его не использовать?

Спасибо.

Теперь нет ничего, что связано с таймаутами, т.к. их использование фризит EventLoop при чтении.
Теперь поведение такое же как и в сокетах, т.е. данные рассматриваются просто как непрерывный поток,
и где там у них начало, где конец - это все решает пользователь.

Примерное решение с ожиданиями см. тут: http://forum.vingrad.ru/forum/topic-344976.html#


Потому, что в этом режиме класс сам автоматически буферизирует входящие даные, т.е. сам вычитывает из UART и кладет в свой кольцевой внутренний буфер.
А вызов read(), readAll() читает эти данные, которые уже готовы, из внутренего буфера.
Т.е. этот подход увеличивает производительность и быстродествие (т.е. также сокеты также работают)

kuzulis, а метод waitForReadyRead(int msec) фризит EventLoop? там ведь внутри select с таймаутом.