Создаю библиотеку для работы с последовательными портами. [УШЕЛ ИЗ ПРОЕКТА].

[kuzulis]

Пример кода в студию. Как открывали порт, как конфигурировали, как проверяли кол-во байт и т.п.
Но лучше всего, приведите готовый минимальный компилябельный проект.
--
Ещё: про какую версию библиотеки Вы говорите: 0.3.0 или текущую ветку master?

[MrLink]

Прошу прощения, что не указал.
Значит версия 0.3.0, взял с git 13.11.10 (в Readme_ru.txt написано 0.2.0)

Пример кода в студию. Как открывали порт, как конфигурировали, как проверяли кол-во байт и т.п.
Но лучше всего, приведите готовый минимальный компилябельный проект.
--
Ещё: про какую версию библиотеки Вы говорите: 0.3.0 или текущую ветку master?

Всё привести вряд ли смогу.

Код:

void MainWindow::slot_readUart()
{
    // Поставил на всякий случай
    if (!m_pSerial->isOpen()) {
        return;
    }

    qint64 numBytes;
    numBytes = m_pSerial->bytesAvailable();
    if ( numBytes < 0) {
        m_pSerial->close();
        //qDebug("Read port error %ld", m_pSerial->lastError());
        qDebug("Read port error ");
        return;
    }
    if ( numBytes == 0) {
        //qDebug("Read 0");
        // Windows patch
        m_pSerial->read(numBytes);
        return;
    }
....
}

Открытие:

Код:

#if defined(Q_OS_WIN32)
        m_pSerial->setDeviceName(m_pCBSerialPort->currentText());
#else
        m_pSerial->setDeviceName(QString("/dev/") + m_pCBSerialPort->currentText());
#endif
        if (!m_pSerial->open(AbstractSerial::ReadWrite)) {
            qDebug("Error open port");
            return;
        }
/*
            qDebug() << "= New parameters =";
            qDebug() << "Device name            : " << m_pSerial->deviceName();
            qDebug() << "Baud rate              : " << m_pSerial->baudRate();
            qDebug() << "Data bits              : " << m_pSerial->dataBits();
            qDebug() << "Parity                 : " << m_pSerial->parity();
            qDebug() << "Stop bits              : " << m_pSerial->stopBits();
            qDebug() << "Flow                   : " << m_pSerial->flowControl();
            qDebug() << "Char timeout, msec     : " << m_pSerial->charIntervalTimeout();
//*/
        switch (m_pCBSerialSpeed->currentIndex()) {
        case 0: m_pSerial->setBaudRate(AbstractSerial::BaudRate1200);   break;
        case 1: m_pSerial->setBaudRate(AbstractSerial::BaudRate2400);   break;
        case 2: m_pSerial->setBaudRate(AbstractSerial::BaudRate4800);   break;
        case 3: m_pSerial->setBaudRate(AbstractSerial::BaudRate9600);   break;
        case 4: m_pSerial->setBaudRate(AbstractSerial::BaudRate19200);  break;
        case 5: m_pSerial->setBaudRate(AbstractSerial::BaudRate38400);  break;
        case 6: m_pSerial->setBaudRate(AbstractSerial::BaudRate57600);  break;
        case 7: m_pSerial->setBaudRate(AbstractSerial::BaudRate115200); break;
        }
        m_pSerial->setDataBits(AbstractSerial::DataBits8);
        m_pSerial->setParity(AbstractSerial::ParityNone);
        m_pSerial->setStopBits(AbstractSerial::StopBits1);
        m_pSerial->setFlowControl(AbstractSerial::FlowControlOff);
        m_pSerial->flush();
    }

[kuzulis]

Значит версия 0.3.0, взял с git 13.11.10 (в Readme_ru.txt написано 0.2.0)

Да, это 0.3.0. , не смотрите на то что написано в Readme.

Сделал по примеру чтение по сигналу readyRead() в "привязаном" слоте определяется количество принятых байтов, проверка на размер, и их чтение. Под WinXP(32bit) приходят сигналы, а количество равно нулю.

хм.. у меня приходит так как надо (я изменил для этого пример sreader, где вместо readAll() вставил bytesAvailable() и вывожу в консоль количество принятых байт).
Тестировал на шнурке PL2303 и встроенном в мамку портом. Хотя, в винде может быть всё что угодно.

И если не сделать чтение, сигналы больше не приходят.

Да, в винде так и будет. Это её фича!  
Сигнал приходит только в момент приема символа, после этого ничо не будет. Увы.
---
Могу только посоветовать использовать версию библиотеки из Master: http://gitorious.org/qserialdevice/qserialdevice/archive-tarball/master
может быть, оно поможет.

[kuzulis]

Сам по себе класс защищён от копирования (Q_DISABLE_COPY(AbstractSerial)), что очень сильно затрудняет его использование в множественных потоках. В принципе это правильно, так как последовательный порт, с которым мы работаем, является уникальным. Это гуд. Но каждый раз (при моих задачах) приходится его перемещать в нужный поток - это уже не гуд, я бы сказал просто мрак, тем более при отладке. Подумав на досуге, пришел к выводу, что нужно использовать статическую переменную isOpen, что позволит копировать экземпляр класса куда нам надо, со всеми его настройками. Естественно, что нам придётся при этом контролировать использование его IO - методов, то есть ставить что то вроде ioUsed или  какой-то мьютекс при приёме или передаче данных. Так же при этом возникнет ещё более (я бы сказал не слишком значительная) интересная задача. Связана она с тем, что в большинстве случаев нам приходится общаться с приборами в режиме запрос-ожидание-ответ. Тогда для этого режима надо будет ввести, что б не сильно напрягаться, пользовательский флаг монопольного доступа на некий промежуток времени, допустим до завершения некой операции, точнее до прихода ответа, ну если конечно не возникнет исключение таймаута ожидания.

Ох... Ну, раз Вы поняли что Вам надо, то пробуйте, я заниматься этим не буду.
Но ИМХО, вы не правильно спроектировали приложение.
В чем смысл перемещать объект в по разным потокам? Создали бы в одном потоке и всё, в чем проблема то?
Этож не "ночная бабочка" чтобы по рукам переходить!

PS: с проблемой получения перечней портов так ни фига и не поняли.

В смысле?
 

[MrLink]

Да, в винде так и будет. Это её фича!  
Сигнал приходит только в момент приема символа, после этого ничо не будет. Увы.

Делал у себя рефакторинг кода, поэтому и наткнулся на данную фичу. Лезть в исходники и разбираться, если честно, лень было, потому и написал. Да вообщем-то фиг с ним, главное теперь везде работает.
p.s. еще раз благодарю за библиотеку.

[kuzulis]

Важно!

Мне нужна консультация/мнения уважаемого сообщества по следующему вопросу:

Как известно,  в данный момент уведомления в классе SerialDeviceEnumerator для Windows реализованы через приватный Qt-класс QWinEventNotifier.
Этот класс "ловит" события при изменении соответствующей ветки в реестре.
Данный подход в принципе был бы "ничо так", если бы класс QWinEventNotifier не был бы приватным.

Я недавно реализовал уведомления (в Windows) иным способом: через создание окна (не QWidget) и отлова его мессаги WM_DEVICE_CHANGED через calbac-функцию окна (по аналогии с QEventDispatcherWin32).

* Так вот, стоит ли обновить репозиторий новым кодом?

В принципе, при этом, мы делаем наш код независимым от версии Qt, но при этом ухудшается возможность "интеграции" кода библиотеки в Qt4.

** Под интеграцией я подразумеваю гипотетическую возможность в будущем наложить некий патч на  исходники Qt чтобы добавить в неё поддержку последовательных портов как части Qt, т.е. при этом патчатся конфиги (*.pro и т.п.)  Qt и в опции configure добавляются опции для сборки QtSerial.
В будущем подумываю (есть мысли) , также создать некие патчи для интеграции QSerialDevice с исходниками Qt, чтобы была возможность собрать QSerialDevice  двумя путями:
1. Когда имеется уже откомпиленная Qt4 и мы хотим собрать QSerialDevice отдельно.
2. Когда имеются исходники Qt4 и мы хотим интегировать QSerialDevice туда и собрать всё это вместе.

Кто что думает по поводу * и **  ?

[sne]

* - стоит, т.к. использование окна Windows способ, мне кажется, прямее использования приватных внутренностей qt;
** - насколько это нужно и кому? Текущий вариант вполне лично меня устраивает.

Вышесказанное мнение - мое имхо, и т.д. и т.п. Спасибо за отличную библиотеку

[pastor]

Под интеграцией я подразумеваю гипотетическую возможность в будущем наложить некий патч на  исходники Qt чтобы добавить в неё поддержку последовательных портов как части Qt

На MeeGo Conference 2010 общался с менеджерами Нокия по Qt части. Сами троли не будут и не желают добавлять поддержку работы с последовательным портом в Qt, т.к., грубо говоря, им это ненужно (хотя на Qt Dev Days 2010 дали надежду). При этом сказали, если есть наработки - смелее вливайте, только следуйте всем правилам оформления и прочее.

Так что могу сказать - давай!

[pastor]

WM_DEVICE_CHANGED

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

[kuzulis]

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

А больше никакой метод не "прокатит". Увы.

Использую стандартный виндовый подход., сначала:

Код:

...
    ::DEV_BROADCAST_DEVICEINTERFACE notificationFilter;
    int size = sizeof(::DEV_BROADCAST_DEVICEINTERFACE);
    ::ZeroMemory(&notificationFilter, size);

    notificationFilter.dbcc_size = size;
    notificationFilter.dbcc_devicetype = DBT_DEVTYP_DEVICEINTERFACE;

    size = sizeof(guidDevInterfaceList);
    for (int i = 0; i < size; i++) {
        notificationFilter.dbcc_classguid = guidDevInterfaceList[i];
        ::HDEVNOTIFY hDeviceNotify = ::RegisterDeviceNotification(this->internalHwnd, &notificationFilter, DEVICE_NOTIFY_WINDOW_HANDLE);
        if (!hDeviceNotify) {
            // Handle the error...
            qWarning("Notificator: Failed call RegisterDeviceNotification: %d\n", (int)GetLastError());
        }
...

где :
this->internalHwnd - это дескриптор виндового окна созданного с помощью CreateWindowEx.
guidDevInterfaceList - список class-guid -ов для разного рода интерфейсов портов (в часности стандартный PORTS CLASS GUID).

Далее в callbac обработчике окна this->internalHwnd ловлю WM_DEVICECHANGE и "тупо" получаю список присутствующих в данный момент устройств в системе с помощью SetupDiGetClassDevs и SetupDiEnumDeviceInfo :

Код:

//callbac обработчик сообщений от окна
...
::LRESULT CALLBACK internal_proc(::HWND hwnd, ::UINT message, ::WPARAM wp, ::LPARAM lp)
{
    switch (message) {
    case WM_DEVICECHANGE: {
             //тут "тупо" перебор имеющихся в системе портов с помощью SetupDiGetClassDevs и SetupDiEnumDeviceInfo
        }
        break;
    default:
        return ::DefWindowProc(hwnd, message, wp, lp);
    }
    return 0;
}
...

Это вкратце.

Также винда предоставляет еще один способ, где в функции RegisterDeviceNotification вместо дескриптора окна можно подсунуть дескриптор сервиса, но для этого нужно сначала этот сервис создать, запустить и хз что еще с ним делать.
ИМХО, проще всего делать через дескриптор окна.

Иных решений я не вижу/не знаю/не представляю.

Сами троли не будут и не желают добавлять поддержку работы с последовательным портом в Qt, т.к., грубо говоря, им это ненужно (хотя на Qt Dev Days 2010 дали надежду). При этом сказали, если есть наработки - смелее вливайте, только следуйте всем правилам оформления и прочее.

Хм... Я тут http://bugreports.qt.nokia.com/browse/QTBUG-9980?focusedCommentId=125228&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel
предложил попробовать интегрировать QSerialDevice в Qt, но так ничо не получил в ответ от Nokia. ( Может не туда я предлагал?)
Хотя, еще рано об этом говорить (много ляпов в библиотеке + работает только в Linux/Win/Mac ).. Но попытка не тытка (с)

[pastor]

По поводу WM_DEVICECHANGE: как ты проверяешь приход этого эвента? Случайно не через эмулятор ком порта (USB-to-COM)? Насколько я знаю, то этот эвент приходит даже тогда, когда вставляешь\извлекаешь флешку, т.е. на каждый чиш ты будешь выполнять обновление портов. Как по мне, анализ ветки реестра самое то

[kuzulis]

По поводу WM_DEVICECHANGE: как ты проверяешь приход этого эвента? Случайно не через эмулятор ком порта (USB-to-COM)? Насколько я знаю, то этот эвент приходит даже тогда, когда вставляешь\извлекаешь флешку, т.е. на каждый чиш ты будешь выполнять обновление портов.

Блин, точно. Только что проверил (втыкал/вытыкал флешку) и WM_DEVICECHANGE тоже срабатывал! 
Какой тогда глубинный смысл в Win API функции RegisterDeviceNotification , если в окно "сыпятся" мессаги от любого устройства?
Я то думал, что будут отлавливаться только те мессаги, на которые мы подписались.

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

Дык и с реестром тоже самое. В текущей реализации также отлавливается любое изменение в реестре по пути
"SYSTEM\\CurrentControlSet\\services"

Иначе никак. ИМХО. 

[lit-uriy]

>> Так вот, стоит ли обновить репозиторий новым кодом?
просто сделай ветку, и отправь в хранилище. Кому надо тот возьмёт из неё вместо мастера

[pastor]

Дык и с реестром тоже самое. В текущей реализации также отлавливается любое изменение в реестре по пути
"SYSTEM\\CurrentControlSet\\services"

Иначе никак. ИМХО.  

А почему обрабатывается эменнто этот путь реестра?

Года 4 назад мы также разрабатывали класс для работы с последовательным портом. Мы мониторили ветку "HKLM\HARDWARE\\DEVICEMAP\\SERIALCOMM". Здесь можно полусить список всех COM портов системы, а также отследить добавление\удаление виртуальных COM портов. Если нужно, есть пример "монитора", правда на Qt3

[kuzulis]

А почему обрабатывается эменнто этот путь реестра?

Потому что если открыть порт и выдернуть его - то из этой ветки устройство не исчезнет! На crossplatform.ru уже обсуждали.

просто сделай ветку, и отправь в хранилище. Кому надо тот возьмёт из неё вместо мастера

А я не понял как ветки делать, т.е боюсь что после манипуляций моих я затру ветку master.