Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: QSerialDevice - Библиотека для работы с COM-портами
Форум на CrossPlatform.RU > Административный > Crossplatform.ru - все о нем > Обсуждение исходников с сайта
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9
kuzulis
13.12.2011, 20:19
Цитата
kuzulis, Подскажи это нормально что при использовании qserialdevice 2.0, для работы с usb serial если открыть порт и выдернуть usb устройство, то в основном процессе почему-то перестают выполняться все ивенты таймеров... они срабатывают только при любом ручном GUI ивенте.

Это в Linux? Не знаю, я не выдергивал в 2.0 шнурок :)
Но по-моему это таже самая проблема что и раньше.

Цитата
Или мы возвращаемся к схожей нерешенной ситуации что была в прошлой версии ?

Скорее всего.

Как один из вариантов ее решения можно попробовать создать еще один QSocketNotifier, только для отлова IO exception, и назвать его типа exceptionNotifier. Плюс - добавить переменную-счетчик ошибок и, если exceptionNotifier срабатывает подряд, к примеру, 10 раз - то считаем, что шнурок выдернули и закрываем порт.
Но минус этого способа в том, что закрывать порт будет "нижний" уровень engine библиотеки, при этом, верхний уровень не узнает что порт был закрыт.

Другой вариант - это создать дополнительный класс типа SerialPortWatcher, который будет завязан на libudev или просто мониторить наличие файла в /dev. И если файл устройства исчезает из системы - то делать close(). В этом случае закрывать будет верхний уровень библиотеки.

В общем - нефик выдергивать шнурок.
shurilnik
14.12.2011, 18:19
Цитата(kuzulis @ 13.12.2011, 20:19) *
Цитата
Или мы возвращаемся к схожей нерешенной ситуации что была в прошлой версии ?

Скорее всего.

Да, так и есть. :-) Я уже разобрался и все порешал для своих нужд.

Цитата(kuzulis @ 13.12.2011, 20:19) *
Как один из вариантов ее решения можно попробовать создать еще один QSocketNotifier, только для отлова IO exception, и назвать его типа exceptionNotifier. Плюс - добавить переменную-счетчик ошибок и, если exceptionNotifier срабатывает подряд, к примеру, 10 раз - то считаем, что шнурок выдернули и закрываем порт.
Но минус этого способа в том, что закрывать порт будет "нижний" уровень engine библиотеки, при этом, верхний уровень не узнает что порт был закрыт.

На мой взгляд не очень изящный вариант... почему 10 раз, а не 20, как бы не совсем однозначный...

Цитата(kuzulis @ 13.12.2011, 20:19) *
Другой вариант - это создать дополнительный класс типа SerialPortWatcher, который будет завязан на libudev или просто мониторить наличие файла в /dev. И если файл устройства исчезает из системы - то делать close(). В этом случае закрывать будет верхний уровень библиотеки.

Именно так я и сделал, я переделал SerialDeviceEnumerator (из прежней версии qserialdevice) убрал все кроме мониторинга, исправил ошибку с нечтением сокета приводившую к 100% загрузке проца заюзал для этих целей. Спасибо за совет. Исправление в оригинальном (неурезанном serialdeviceenumerator) я сделаю позже и тогда пришлю merge request, ща просто времени нету.

В общем-то получилось все класно. Этот класс отслеживает на уровне udev появление исчезание устройств, посылает сигнал наверх где при помощи SerialPortInfo::availablePorts() опрашивается и отслеживается что за изменение произошло и закрываются/открываются порты. Не надо мутить никакие таймера думать как часто надо это делать... появилось устройсво - отработало. исчезло - отработало. все остальное время лишней митусни не выполняется.... :-)

Цитата(kuzulis @ 13.12.2011, 20:19) *
В общем - нефик выдергивать шнурок.

Ну не надо быть таким категоричным... :-)
Задачи бывают разные, вот у меня устройство которое занимается диагностикой других приборов которые имеют на борту ftdi через которую осуществляется весь обмен более высокого уровня. Диагностируемый прибор может подключаться/отключаться в любой момент. Когда подключено идет периодический обмен данными, а потом прибор может быть спонтанно выдернут... Ну не будет пользователь делать "safe remove" как на компе для флешек (кстати часто и там не делают). Поэтому ситуация когда я подключил устройство, открыл порт, выдернул и прога подвисла - неприемлема.
А закрывать/открывать порт перед каждым периодическим обменом тоже не выход. Не предскажешь в какой момент произойдет отключение.
В любом случае спасибо за советы и быструю реакцию :-)
kuzulis
14.12.2011, 20:12
Цитата
В любом случае спасибо за советы и быструю реакцию :-)

Да пожалуйста. Ты главное MR не забуть послать :)
Так сказать, на будущее.
shurilnik
15.12.2011, 17:47
Цитата(kuzulis @ 14.12.2011, 20:12) *
Да пожалуйста. Ты главное MR не забуть послать :)

Сделал. :)
kuzulis
15.12.2011, 17:58
Цитата(shurilnik @ 15.12.2011, 18:47) *
Сделал. :)


Ок. Спасибо. Я уже влил твой MR в Master ветку.
Доверяю не проверяя. :)
shurilnik
17.12.2011, 12:52
kuzulis, Я все забывал написать, у тебя в либе под линуксом не работает установка customBaudRate. Это касается и 0.4 версии и новой, вот сейчас только заметил в новой.
Визуально оно вроде как бы и работает т.е. делаешь setBaud и потом опрашиваешь и все вроде хорошо, показывает что установлена эта скорость, но реальный обмен на этой скорости не происходит.
Я попозже сделаю мерж реквест изменений которые решают эту проблему(в обе ветки). Но хотел бы чтобы ты все-таки просмотрел код и убедился что так действительно надо делать.
Во всяком случае я могу подтвердить что после моих изменений обмен на нестандартной скорости точно идет.
kuzulis
17.12.2011, 13:59
Кстати, shurilnik,

не хочешь ли стать контрибьютором (вкладчиком) этой библиотеки в Нокиа?

Если да (типа будешь учавствовать в её развитии, коммитить баги, фичи и т.п.),

то зарегистрируйся на их Jira баг-трекере: https://bugreports.qt.nokia.com/secure/Sign...33;default.jspa

И дай мне сюда затем полное имя твоей учетной записи.
Я его перешлю Нокиевцам и они для тебя создадут задачу на https://bugreports.qt.nokia.com
о том, чтобы ты принял их соглашение CLA.

т.е. они в данный момент собирают подписи всех участников, чтобы начать импорт QSerialDevice 2.0
в свой репозиторий и старта процесса интеграции в Qt.

Подробнее см. тему тут
там вроде самое начало обсуждения о принятии библиоттеки в Qt.
В общем, смотри эту ссылку на топик, а также последуюшие топики в той теме.

Суть в том, что если я сейчас приму твой MR для QSerialDevice 2.0 - то ты автоматически становишься
участником всей этой затеи с интеграцией.

Т.к. ты вливаешь свою часть кода в библиотеку, то необходимо и твое разрешение на начало
интеграции в Qt. Иначе Нокиевцы не начнут старт.

Так что: или ты регистрируешься в Jira и соглашаешься с CLA и я мержу твой реквест
или ты не регистрируешься и не соглашаешься, но тогда я твой реквест
переделываю "типа от себя" и добавляю от себя, т.е. о том, что он твой никто не узнает :)

Если ты согласен, то ОБЯЗАТЕЛЬНО начни с этого
т.е. делай как там написано.
shurilnik
19.12.2011, 10:49
Цитата(kuzulis @ 17.12.2011, 13:59) *
Кстати, shurilnik,
не хочешь ли стать контрибьютором (вкладчиком) этой библиотеки в Нокиа?

Эм, сложный вопрос :)

Цитата(kuzulis @ 17.12.2011, 13:59) *
Если да (типа будешь учавствовать в её развитии, коммитить баги, фичи и т.п.),

Я могу комитить баги, если встречу их по мере использования библиотеки для своего девайса, но я не уверен что у меня будет время заниматься развитием библиотеки фичами и т.д.

Цитата(kuzulis @ 17.12.2011, 13:59) *
Я его перешлю Нокиевцам и они для тебя создадут задачу на https://bugreports.qt.nokia.com
о том, чтобы ты принял их соглашение CLA.

Правильно ли я понял что они при этом могут давать мне другие задачи по самой библиотеке ? Я просто боюсь что я не смогу оперативно на это дело реагировать...
Или как там все это происходит ?

Цитата(kuzulis @ 17.12.2011, 13:59) *
Суть в том, что если я сейчас приму твой MR для QSerialDevice 2.0 - то ты автоматически становишься
участником всей этой затеи с интеграцией.
Т.к. ты вливаешь свою часть кода в библиотеку, то необходимо и твое разрешение на начало
интеграции в Qt. Иначе Нокиевцы не начнут старт.

Я как бы не возражаю и разрешаю :)

Цитата(kuzulis @ 17.12.2011, 13:59) *
Так что: или ты регистрируешься в Jira и соглашаешься с CLA и я мержу твой реквест
или ты не регистрируешься и не соглашаешься, но тогда я твой реквест
переделываю "типа от себя" и добавляю от себя, т.е. о том, что он твой никто не узнает :)

Я никогда не учавствовал в таких опернсорс проектах, как бы оно то и можно было бы, если меня не будут грузить задачами, а я сам если что-то найду - закомичу...
Как ты сам то посоветуешь сделать ?
kuzulis
19.12.2011, 10:59
Цитата
Правильно ли я понял что они при этом могут давать мне другие задачи по самой библиотеке ? Я просто боюсь что я не смогу оперативно на это дело реагировать...
Или как там все это происходит ?

Скорее всего. Я сам ХЗ как там оно.

Цитата
Я как бы не возражаю и разрешаю

Ну я то это понимаю. Но типа им нужно "официальное" согласие.

Цитата
Я никогда не учавствовал в таких опернсорс проектах, как бы оно то и можно было бы, если меня не будут грузить задачами, а я сам если что-то найду - закомичу...
Как ты сам то посоветуешь сделать ?

Да я тоже не участвовал.
Скорее всего я придержу твой MR до момента начала интеграции.
А там - посмотрим. В общем, разберемся.

Давай как пока подождем что они скажут.

shurilnik
19.12.2011, 15:11
Цитата(kuzulis @ 19.12.2011, 10:59) *
Скорее всего я придержу твой MR до момента начала интеграции.
А там - посмотрим. В общем, разберемся.

Давай как пока подождем что они скажут.

Хорошо, пиши если что.
Гость
29.1.2012, 0:33
Прошу не бить ногами, т.к. с 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();}
}
kuzulis
29.1.2012, 11:38
Цитата(Гость @ 29.1.2012, 1:33) *
Прошу не бить ногами, т.к. с Qt и С++ на вы.
Пишу прогу для связи компа с девайсом (светодиодный дисплей).
Решил пойти по путе наименьшего сопротивления, потому что новичек и в качестве примера использовал консольные reader и writer.
реализовывается протокол по принципу запрос-ответ.
Данные отправляются успешно, а вот считываются совсем наоборот, т.е. не считываются: либо таймаут, либо массив нулевой длины.
Шишку набил уже большую, а вот где грабли не пойму.
QT 4.6.3
QSerialDevice 0.4.1

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
kuzulis
8.2.2012, 21:06
Наконец то Nokia клонировала репозиторий QSerialDevice 2.0 в Gerrit!!!

Ура, товарищи! За это не грех хряпнуть! :rolleyes:
Алексей1153
9.2.2012, 7:54
а что это означает ? )
kuzulis
9.2.2012, 10:10
То, что оно теперь будет как аддон к Qt,
также то, что принадлежит Нокии теперь (вроде) и то, что они будут помогать в развитии.

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

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

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

Вот тут еще можно почитать.
Fitz
9.2.2012, 19:02
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) - работает только отправка в порт, но данные с порта никакие не принимаются.
kuzulis
9.2.2012, 19:57
Цитата(Fitz @ 9.2.2012, 20:02) *
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 статически.
Используйте дебагер.
silver47
16.2.2012, 7:59
kuzulis,

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

Цитата(kuzulis @ 29.1.2012, 14:38) *
5. Не используй AbstractSerial::Unbuffered


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

Спасибо.
kuzulis
16.2.2012, 10:05
Цитата(silver47 @ 16.2.2012, 8:59) *
Не могу найти аналог setTotalReadConstantTimeout. Как мне теперь можно подождать фиксированное время, перед чтением? Реализовать самому?

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

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

Цитата(silver47 @ 16.2.2012, 8:59) *
Почему Вы советуете его не использовать?

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

Гость
7.4.2012, 14:24
kuzulis, а метод waitForReadyRead(int msec) фризит EventLoop? там ведь внутри select с таймаутом.
kuzulis
7.4.2012, 17:48
Цитата(Гость @ 7.4.2012, 15:24) *
kuzulis, а метод waitForReadyRead(int msec) фризит EventLoop? там ведь внутри select с таймаутом.


Да. Фризит.
Гость
7.4.2012, 20:39
kuzulis, спасибо за ответ. А чем плохим может обернуться для Event Loop'a такой фриз? Для примера. Есть однопоточное приложение, которое использует QSerialPort(QSerialDevice) в драйвере кассового аппарата. Используется waitForReadyRead() для реализации таймаутов перед приемом ответов от кассы. Вы бы не соватовали так делать, а использоваться QTimer? И если нет, то почему?
kuzulis
7.4.2012, 22:50
Цитата(Гость @ 7.4.2012, 21:39) *
kuzulis, спасибо за ответ. А чем плохим может обернуться для Event Loop'a такой фриз? Для примера. Есть однопоточное приложение, которое использует QSerialPort(QSerialDevice) в драйвере кассового аппарата. Используется waitForReadyRead() для реализации таймаутов перед приемом ответов от кассы. Вы бы не соватовали так делать, а использоваться QTimer? И если нет, то почему?

Потому, что от этого фризится GUI, и использовать QSerialDevice с waitForReadyRead() нужно в другом потоке, чтобы этого не происходило.
Гость
8.4.2012, 11:19
kuzulis, и в очередной раз спасибо за ответ. Как раз хотел спросить про потоки, потому что у меня по протоколу работы с кассой самый большой таймаут ожидания ответа = 10 секунд, но ответ, как правило, приходит за доли секунды. Тоесть при использовании QTimer мне пришлось бы каждый раз ждать 10 секунд, либо ломать протокол, что тоже не выход. Но если в Qt на каждый поток свой EventLoop, то да, waitForReadyRead() можно без проблем использовать.
romeodka
15.5.2012, 4:21
Доброе время суток.
Подскажите пожалуйста в чем может быть дело.
Поставил себе qt-sdk-win-opensource-2010.05 и скачал отсюда QSerialDevice. Начинаю компилировать библиотеку, все идет нормально и потом вылазит окно "Не удалось найти программу, пожалуйста, укажите её" и предлагает указать какую то программу.
И что надо указать? и так и должно быть? и вообще что делать?

У меня стоит Win Xp Sp2
вот то что в консоли пишет
Раскрывающийся текст
Выполняется сборка проекта BuildLibrary...
Запускается "c:/qt/2010.05/qt/bin/qmake.exe" D:/progects/serialDevice/qserialdevice-qserialdevice/BuildLibrary.pro -r -spec win32-g++ CONFIG+=release
Reading D:/progects/serialDevice/qserialdevice-qserialdevice/src/src.pro

Процесс "c:/qt/2010.05/qt/bin/qmake.exe" завершился нормально.
Запускается "C:/Qt/2010.05/mingw/bin/mingw32-make.exe" -w
mingw32-make: Entering directory `D:/progects/serialDevice/qserialdevice-qserialdevice'

cd src\ && C:/Qt/2010.05/mingw/bin/mingw32-make -f Makefile 

mingw32-make[1]: Entering directory `D:/progects/serialDevice/qserialdevice-qserialdevice/src'

C:/Qt/2010.05/mingw/bin/mingw32-make -f Makefile.Release

mingw32-make[2]: Entering directory `D:/progects/serialDevice/qserialdevice-qserialdevice/src'

C:\Qt\2010.05\qt\bin\moc.exe -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"c:\Qt\2010.05\qt\include\QtCore" -I"c:\Qt\2010.05\qt\include" -I"qserialdevice" -I"qserialdeviceenumerator" -I"c:\Qt\2010.05\qt\include\ActiveQt" -I"build\moc" -I"c:\Qt\2010.05\qt\mkspecs\win32-g++" -D__GNUC__ -DWIN32 qserialdevice\abstractserial.h -o build\moc\moc_abstractserial.cpp

g++ -c -O2 -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"c:\Qt\2010.05\qt\include\QtCore" -I"c:\Qt\2010.05\qt\include" -I"qserialdevice" -I"qserialdeviceenumerator" -I"c:\Qt\2010.05\qt\include\ActiveQt" -I"build\moc" -I"c:\Qt\2010.05\qt\mkspecs\win32-g++" -o build\obj\abstractserial.o qserialdevice\abstractserial.cpp

C:\Qt\2010.05\qt\bin\moc.exe -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"c:\Qt\2010.05\qt\include\QtCore" -I"c:\Qt\2010.05\qt\include" -I"qserialdevice" -I"qserialdeviceenumerator" -I"c:\Qt\2010.05\qt\include\ActiveQt" -I"build\moc" -I"c:\Qt\2010.05\qt\mkspecs\win32-g++" -D__GNUC__ -DWIN32 qserialdevice\abstractserialengine.h -o build\moc\moc_abstractserialengine.cpp

g++ -c -O2 -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"c:\Qt\2010.05\qt\include\QtCore" -I"c:\Qt\2010.05\qt\include" -I"qserialdevice" -I"qserialdeviceenumerator" -I"c:\Qt\2010.05\qt\include\ActiveQt" -I"build\moc" -I"c:\Qt\2010.05\qt\mkspecs\win32-g++" -o build\obj\abstractserialengine.o qserialdevice\abstractserialengine.cpp

C:\Qt\2010.05\qt\bin\moc.exe -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"c:\Qt\2010.05\qt\include\QtCore" -I"c:\Qt\2010.05\qt\include" -I"qserialdevice" -I"qserialdeviceenumerator" -I"c:\Qt\2010.05\qt\include\ActiveQt" -I"build\moc" -I"c:\Qt\2010.05\qt\mkspecs\win32-g++" -D__GNUC__ -DWIN32 qserialdevice\nativeserialengine.h -o build\moc\moc_nativeserialengine.cpp

g++ -c -O2 -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"c:\Qt\2010.05\qt\include\QtCore" -I"c:\Qt\2010.05\qt\include" -I"qserialdevice" -I"qserialdeviceenumerator" -I"c:\Qt\2010.05\qt\include\ActiveQt" -I"build\moc" -I"c:\Qt\2010.05\qt\mkspecs\win32-g++" -o build\obj\nativeserialengine.o qserialdevice\nativeserialengine.cpp

g++ -c -O2 -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"c:\Qt\2010.05\qt\include\QtCore" -I"c:\Qt\2010.05\qt\include" -I"qserialdevice" -I"qserialdeviceenumerator" -I"c:\Qt\2010.05\qt\include\ActiveQt" -I"build\moc" -I"c:\Qt\2010.05\qt\mkspecs\win32-g++" -o build\obj\abstractserialnotifier.o qserialdevice\abstractserialnotifier.cpp

g++ -c -O2 -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"c:\Qt\2010.05\qt\include\QtCore" -I"c:\Qt\2010.05\qt\include" -I"qserialdevice" -I"qserialdeviceenumerator" -I"c:\Qt\2010.05\qt\include\ActiveQt" -I"build\moc" -I"c:\Qt\2010.05\qt\mkspecs\win32-g++" -o build\obj\nativeserialengine_win.o qserialdevice\nativeserialengine_win.cpp

g++ -c -O2 -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"c:\Qt\2010.05\qt\include\QtCore" -I"c:\Qt\2010.05\qt\include" -I"qserialdevice" -I"qserialdeviceenumerator" -I"c:\Qt\2010.05\qt\include\ActiveQt" -I"build\moc" -I"c:\Qt\2010.05\qt\mkspecs\win32-g++" -o build\obj\nativeserialnotifier_win.o qserialdevice\nativeserialnotifier_win.cpp

C:\Qt\2010.05\qt\bin\moc.exe -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"c:\Qt\2010.05\qt\include\QtCore" -I"c:\Qt\2010.05\qt\include" -I"qserialdevice" -I"qserialdeviceenumerator" -I"c:\Qt\2010.05\qt\include\ActiveQt" -I"build\moc" -I"c:\Qt\2010.05\qt\mkspecs\win32-g++" -D__GNUC__ -DWIN32 qserialdeviceenumerator\serialdeviceenumerator.h -o build\moc\moc_serialdeviceenumerator.cpp

g++ -c -O2 -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"c:\Qt\2010.05\qt\include\QtCore" -I"c:\Qt\2010.05\qt\include" -I"qserialdevice" -I"qserialdeviceenumerator" -I"c:\Qt\2010.05\qt\include\ActiveQt" -I"build\moc" -I"c:\Qt\2010.05\qt\mkspecs\win32-g++" -o build\obj\serialdeviceenumerator.o qserialdeviceenumerator\serialdeviceenumerator.cpp

g++ -c -O2 -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_NO_DEBUG -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"c:\Qt\2010.05\qt\include\QtCore" -I"c:\Qt\2010.05\qt\include" -I"qserialdevice" -I"qserialdeviceenumerator" -I"c:\Qt\2010.05\qt\include\ActiveQt" -I"build\moc" -I"c:\Qt\2010.05\qt\mkspecs\win32-g++" -o build\obj\serialdeviceenumerator_p_win.o qserialdeviceenumerator\serialdeviceenumerator_p_win.cpp

ar -ru build\release\libqserialdevice.a build/obj/abstractserial.o build/obj/abstractserialengine.o build/obj/nativeserialengine.o build/obj/abstractserialnotifier.o build/obj/nativeserialengine_win.o build/obj/nativeserialnotifier_win.o build/obj/serialdeviceenumerator.o build/obj/serialdeviceenumerator_p_win.o 

mingw32-make[2]: Leaving directory `D:/progects/serialDevice/qserialdevice-qserialdevice/src'

mingw32-make[1]: Leaving directory `D:/progects/serialDevice/qserialdevice-qserialdevice/src'

mingw32-make: Leaving directory `D:/progects/serialDevice/qserialdevice-qserialdevice'

ar: creating build\release\libqserialdevice.a

Процесс "C:/Qt/2010.05/mingw/bin/mingw32-make.exe" завершился нормально.
kuzulis
15.5.2012, 10:29
Цитата
И что надо указать? и так и должно быть? и вообще что делать?

С перва наперво - разобраться что ты делаешь, и жмакать по кнопочкам в QtCreator
нужно не бездумно, а сначала узнав их предназначение и внимательно читать подсказки (хинты).

Далее, QSerialDevice больше не подерживается, вместо него стартовал новый
проект QtSerialPort.
Тем более, что ты использовал очень старую версию QSerialDevice.

Используй QtSerialPort и не пугайся что там написано, что оно только для Qt5, оно
также и для Qt4 работает.



gpepsi
12.6.2012, 21:48
kuzulis, попробовал собрать через командную строку - не варится

валит что-то типа
WARNING: d:\3RDPARTY\qt\qtserialport\.qmake.cache:1: Unmatched quotes are deprecated.


в debug появилась SerialPortd1.dll, но в релизе ничего нет
kuzulis
13.6.2012, 20:21
Цитата
qmake serialport.pro CONFIG+=release
nmake


Цитата
валит что-то типа

так и должно валить
asket
19.7.2012, 14:27
kuzulis, я скомпилировал Вашу сборку в каталоге C:\QtSDK\Desktop\Qt\, создав две папки qtserialport и qtserialport-build, в build я вижу src\debug и src\release - там serialport1.dll и libSerialPort1.a, теперь я хочу собрать тестовое приложение, а он ругается на отсутствие <QtAddOnSerialPort/serialportinfo.h>, где он должен быть? Его не автоматом копирует?
kuzulis
19.7.2012, 17:58
Цитата(asket @ 19.7.2012, 15:27) *
я скомпилировал Вашу сборку в каталоге C:\QtSDK\Desktop\Qt\

Вот не нужно так делать. Собирай где-нить в любом другом месте.

Цитата(asket @ 19.7.2012, 15:27) *
<QtAddOnSerialPort/serialportinfo.h>, где он должен быть? Его не автоматом копирует?

На ВиКи все подробно описано как надо собирать и устанавливать.
asket
20.7.2012, 8:55
Цитата(kuzulis @ 19.7.2012, 17:58) *
Цитата(asket @ 19.7.2012, 15:27) *
я скомпилировал Вашу сборку в каталоге C:\QtSDK\Desktop\Qt\

Вот не нужно так делать. Собирай где-нить в любом другом месте.

Цитата(asket @ 19.7.2012, 15:27) *
<QtAddOnSerialPort/serialportinfo.h>, где он должен быть? Его не автоматом копирует?

На ВиКи все подробно описано как надо собирать и устанавливать.


При попытке собрать сборку у меня ругается на отсутствие вышеупомянутых заголовочных файлов, мне пришлось в serialport.pro закоментировать сборку тестовых приложений и примеров, я запутался и не могу понять, собираю по Вашей же инструкции в wiki, а получается какая-то фигня. Ну хорошо такой вопрос, обязательно ли под windows использовать именно nmake, я использовал make, а при выполнении make install появляется сообщение, что нечего ему там делать? Ввожу команды в консоле minigw, который идет в составе QtCreator
kuzulis
20.7.2012, 14:08
Цитата(asket @ 20.7.2012, 9:55) *
При попытке собрать сборку у меня ругается на отсутствие вышеупомянутых заголовочных файлов.

Удали все что собирал ранее, очисти все требуемые директории в Qt \lib \bin \include \mkspecs\features от
библиотеки, удали исходники QtSerialPort из директории SDK.

Цитата(asket @ 20.7.2012, 9:55) *
, мне пришлось в serialport.pro закоментировать сборку тестовых приложений и примеров, я запутался и не могу понять, собираю по Вашей же инструкции в wiki, а получается какая-то фигня.

Есть небольшая проблема, если ты хочешь собрать и установить и Release и Debug версии.
Там нужно сначала собирать по отдельности в разные директории сборки (например отдельно в serialport-build-release и serialport-build-debug с соответствующими ключами для qmake). А уже потом, после сборки, по очереди из этих директорий выполнить установку.

Цитата(asket @ 20.7.2012, 9:55) *
Ну хорошо такой вопрос, обязательно ли под windows использовать именно nmake, я использовал make, а при выполнении make install появляется сообщение, что нечего ему там делать? Ввожу команды в консоле minigw, который идет в составе QtCreator

nmake в случае, если у тебя MSVC компилятор, если-же MinGW - то просто make.
asket
23.7.2012, 10:47
kuzulis, вроде получилось у меня так, я создал 3 каталога serialport-src, где лежат исходники и serialport.pro, и два Build и Release:
сначала в каждом из каталогов build и release сделал make, а затем в подкаталогах /src этих же каталогов debug и release осушествил make install, вот тогда начинает копошиться с копированием в Qt-директорию. Что-то не соответствует Вашим инструкциям в wiki по части make install.
asket
24.7.2012, 13:36
kuzulis, каким образом можно остлеживать изменение списка портов? В предыдущей Вашей версии QserialDevice я делал с помощью сигнала hasChanged(QStringList) класса SerialDeviceEnumerator, а в этой - как? Впечатление складывается, сильно урезали QSerialDevice, к которому я так привык..
kuzulis
24.7.2012, 20:49
Цитата(asket @ 24.7.2012, 14:36) *
kuzulis, каким образом можно остлеживать изменение списка портов? В предыдущей Вашей версии QserialDevice я делал с помощью сигнала hasChanged(QStringList) класса SerialDeviceEnumerator, а в этой - как? Впечатление складывается, сильно урезали QSerialDevice, к которому я так привык..


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

UPD: Или можешь взять код отслеживания из QextSerialPort - там он попроще.
asket
25.7.2012, 8:36
Цитата(kuzulis @ 24.7.2012, 21:49) *
Цитата(asket @ 24.7.2012, 14:36) *
kuzulis, каким образом можно остлеживать изменение списка портов? В предыдущей Вашей версии QserialDevice я делал с помощью сигнала hasChanged(QStringList) класса SerialDeviceEnumerator, а в этой - как? Впечатление складывается, сильно урезали QSerialDevice, к которому я так привык..


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

UPD: Или можешь взять код отслеживания из QextSerialPort - там он попроще.


Тем не менее, спасибо за труд. :)
Удачи Вам!
silver47
20.8.2012, 8:54
2 kuzulis,
Добрый день. У меня вопросик по поводу QtSerialPort.

Собрал как указанно в WIKI под винду в release версии:
qmake ../serialport/serialport.pro CONFIG+=release
make
make install


собрал простенький проект
widget.h
#include <QWidget>
#include <QtAddOnSerialPort/serialport.h>

QT_USE_NAMESPACE_SERIALPORT
class Widget : public QWidget{
    Q_OBJECT
    SerialPort          *port;
...
}


widget.cpp
port = new SerialPort;


На что получаю ошибку:
release/widget.o:widget.cpp:(.text+0x147f): undefined reference to `_imp___ZN7QtAddOn10SerialPort10SerialPortC1EP7QObject'
release/widget.o:widget.cpp:(.text+0x2adf): undefined reference to `_imp___ZN7QtAddOn10SerialPort10SerialPortC1EP7QObject'

В чем я мог ошибиться?

Спасибо.
kuzulis
20.8.2012, 21:05
Цитата
CONFIG += serialport
silver47
21.8.2012, 7:44
kuzulis, Да было включено в проект. Сейчас все очистил и пересобрал заново, но консоль запустил от имени системного администратора. Заработало. Спасибо.
fikos
18.9.2012, 8:24
Полистал тему вроде не нашел. Может ли библиотека работать с RS 485? Заранее спасибо.
kuzulis
18.9.2012, 9:45
Цитата
Может ли библиотека работать с RS 485?

Вопрос не корректный.

Ответить могу и ДА и НЕТ.

Litkevich Yuriy
18.9.2012, 11:24
Цитата(fikos @ 18.9.2012, 11:24) *
Может ли библиотека работать с RS 485?
RS 485 - электрический интерфейс, а не логический.
igor_bogomolov
18.9.2012, 12:16
Цитата(Litkevich Yuriy @ 18.9.2012, 12:24) *
RS 485 - электрический интерфейс, а не логический.
Не очень понял, что ты имел в виду. В RS485 логика отличается. Как минимум нужно уметь управлять направлением передачи данных, т.к. RS485 полудуплексный и по умолчанию всегда настроен на приём данных.
По мне, библиотека поддерживающая RS485 должна уметь автоматически менять direction при отправке данных и возвращать его, когда отправка закончилась. Плюс к этому, нужен некий функционал, с помощью которого можно было бы объяснить, как этот самый direction менять. Плюс нужно иметь возможность задать паузу между окончанием передачи данных и изменением direction. Плюс нужна функция меняющая режимы работы между RS232/485.
Если бы всё это было, тогда я был бы счастлив и сказал бы, что такая библиотека поддерживает RS485 :)
kuzulis
18.9.2012, 12:39
Цитата(igor_bogomolov @ 18.9.2012, 13:16) *
Как минимум нужно уметь управлять направлением передачи данных,.

Не факт. Все зависит от типа Чипа, обеспечивающего RS-485. В некоторых чипах нет необходимости заботится о переключении направления - они это делают автоматически (можно сказать, что все это делают)

Цитата(igor_bogomolov @ 18.9.2012, 13:16) *
т.к. RS485 полудуплексный и по умолчанию всегда настроен на приём данных

Не правда. Возможен и полный дуплекс (так называемый RS485 4w).

Цитата(igor_bogomolov @ 18.9.2012, 13:16) *
По мне, библиотека поддерживающая RS485 должна уметь автоматически менять direction при отправке данных и возвращать его, когда отправка закончилась. Плюс к этому, нужен некий функционал, с помощью которого можно было бы объяснить, как этот самый direction менять. Плюс нужно иметь возможность задать паузу между окончанием передачи данных и изменением direction. Плюс нужна функция меняющая режимы работы между RS232/485.

Это платформо/чипо зависимые фичи, они не входят в функционал, т.к. различные производители по-разному это реализуют.
Например, в девайсах от MOXA под Linux (если не изменяет память), режим RS232/485 меняется через ioctl(), и т.п.

Цитата
Если бы всё это было, тогда я был бы счастлив и сказал бы, что такая библиотека поддерживает RS485 :)

Значит не поддерживает.



igor_bogomolov
18.9.2012, 13:35
Цитата(kuzulis @ 18.9.2012, 13:39) *
Не факт. Все зависит от типа Чипа, обеспечивающего RS-485. В некоторых чипах нет необходимости заботится о переключении направления - они это делают автоматически (можно сказать, что все это делают)
Значит мне не повезло. У меня на железке две разные микрухи обеспечивающие RS485 и в обоих direction нужно менять руками. При этом еще по разному. Возможно из-за того, что эти микрухи совмещают возможности RS232/422/485.
Цитата(kuzulis @ 18.9.2012, 13:39) *
Не правда. Возможен и полный дуплекс (так называемый RS485 4w).
Возможен, кто ж спорит :). Есть так же RS422, который так же является полнодуплексным. Но RS485 всётаки считается полудуплексным и если он расширен до 4w то это, обычно, явно уточняется.
По крайней мере, я всегда так думал. Может и не правильно, большого значения это не имеет.
Цитата(kuzulis @ 18.9.2012, 13:39) *
Это платформо/чипо зависимые фичи, они не входят в функционал, т.к. различные производители по-разному это реализуют.
Согласен. Поэтому я и написал
Цитата
Плюс к этому, нужен некий функционал, с помощью которого можно было бы объяснить, как этот самый direction менять
В простейшем случае - это может быть просто регистрация callback'a в которой пользователь сам реализует, как меняется direction. При этом сама библиотека конечно же должна предоставлять возможность управлять линиями последовательного порта.
Litkevich Yuriy
19.9.2012, 5:54
Цитата(kuzulis @ 18.9.2012, 15:39) *
Возможен и полный дуплекс (так называемый RS485 4w).
что-то я не припомню такого в стандарте. Есть версия стандарта:
Цитата(igor_bogomolov @ 18.9.2012, 16:35) *
Есть так же RS422, который так же является полнодуплексным.
который просто содержит 2 канала RS485.
Цитата(igor_bogomolov @ 18.9.2012, 15:16) *
Плюс к этому, нужен некий функционал, с помощью которого можно было бы объяснить, как этот самый direction менять.
ну вот это пожалуй единственный нюанс, который бы расширял библиотеку до поддержки электрического интерфейса. Хотя, по моему, все современные микросхемы USB-RS485 это автоматически реализуют.
igor_bogomolov
19.9.2012, 9:11
Цитата(Litkevich Yuriy @ 19.9.2012, 6:54) *
Цитата(kuzulis @ 18.9.2012, 15:39) *
Возможен и полный дуплекс (так называемый RS485 4w).
что-то я не припомню такого в стандарте. Есть версия стандарта:
Цитата(igor_bogomolov @ 18.9.2012, 16:35) *
Есть так же RS422, который так же является полнодуплексным.
который просто содержит 2 канала RS485.
RS422 обеспечивает соединение точка-точка (в полном дуплексе). RS485 точка-многоточие (полудуплексная передача), RS485-4w точка-многоточие (в полном дуплексе).
RS422 != 2 канала RS485.

Цитата(Litkevich Yuriy @ 19.9.2012, 6:54) *
Хотя, по моему, все современные микросхемы USB-RS485 это автоматически реализуют.
USB-RS485 может быть. Но ими дело не ограничивается. У меня используются преобразователи уровней uart'a в RS232/485. При таком построении direction всегда придётся менять "руками".

Цитата('Litkevich Yuriy' date='19.9.2012 @ 6:54' post=60103)
ну вот это пожалуй единственный нюанс, который бы расширял библиотеку до поддержки электрического интерфейса.
Выше я уже привёл как минимум четыре. Иначе поддержкой я это не назову :)

kuzulis
19.9.2012, 10:24
Цитата(igor_bogomolov @ 19.9.2012, 10:11) *
USB-RS485 может быть. Но ими дело не ограничивается. У меня используются преобразователи уровней uart'a в RS232/485. При таком построении direction всегда придётся менять "руками".

Не правда. Есть промышленные преобразователи 232/485/422 от Advantech ADAM и пр. - там все автоматом определяется.


Цитата(igor_bogomolov @ 19.9.2012, 10:11) *
Выше я уже привёл как минимум четыре. Иначе поддержкой я это не назову :)

Вот если ты возьмешься добавить это дело в библиотеку, то почему нет!?
Исходники есть, а желание есть!?.

Только нужно со всеми разработчиками проконсультироваться на Gerrit, т.к.
там есть и капризные :)

Если есть желание - то можно в скайпе организовать конференцию и обсудить все. (По английски)
igor_bogomolov
19.9.2012, 12:51
Цитата(kuzulis @ 19.9.2012, 11:24) *
Вот если ты возьмешься добавить это дело в библиотеку, то почему нет!?
Исходники есть, а желание есть!?.
Я готов здесь что то пообсуждать. Не более. У меня своей работы хватает :)
kuzulis
19.9.2012, 14:22
Как ни странно - но и у меня тоже :)
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Форум IP.Board © 2001-2024 IPS, Inc.