QSerialDevice - Библиотека для работы с COM-портами Опции

[BRE]

Поэтому всё нафик удаляем и считаем что сколько байт записали - столько и записалось! Иного способа (кроме потоков) я не вижу.

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

Я так понимаю, что это ожидание происходит у тебя же в библиотеке, только уровнем выше?

[kuzulis]

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

Ну иначе (для винды) я не знаю иного выхода. В винде реальное кол-во записанных байт можно узнать только после завершения операции IO (т.е. не WriteFile их возвращает, а GetOverlappedResult).
Поэтому есть два выхода (для винды):
1. Или ждать завершения и получить реальное кол-во записанных байт (но это фризы)
2. Или не ждать завершения и считать что все что передали передастся.

BRE, если у тебя есть иные мысли то поделись.

Я так понимаю, что это ожидание происходит у тебя же в библиотеке, только уровнем выше?

Нет, что касаемо записи - то нет. Если рассматривать винду - то ожидание происходит в nativeWrite (через WaitForSingleObject + GetOverlappedResult).
А если linux - то никакого ожидания нет в принципе вообще.

[BRE]

BRE, если у тебя есть иные мысли то поделись.

Ну в свете твоих объяснений - мыслей нет.
Я не силен в том, как работает венда с последовательным портом, поэтому увидев эту функцию, по аналогии с linux, предположил, что стоит проверять, а что же реально записалось.
Если реально это значение возвращается и можно проверить где-то еще, то ты выбрал вполне нормальное решение.

[Гость_Гость_kuzulis_*_*]

по аналогии с linux, предположил, что стоит проверять, а что же реально записалось.

Ну так в линуксе (если неблокирующий дескриптор/сокет) ,ИМХО, ф-я write тоже может возвратить меньшее кол-во байт чем мы пишем. Но это не значит, что записалось столько - сколько она возвратила.

Поэтому, ИМХО, судить о том сколько байт записалось по возвращаемому функциями write (что в винде, что в линуксе) нельзя. Хотя, могу ошибаться .

[kuzulis]

Блин, зарегаться забыл.

[rcdimon]

Хм... Я вроде говорил, что тормозит при приеме, а не при отправке )

[kuzulis]

Хм... Я вроде говорил, что тормозит при приеме, а не при отправке )

Ну тогда попробуй такой код:

qint64 NativeSerialEnginePrivate::nativeRead(char *data, qint64 len)
{
    if (!clear_overlapped(&this->oRead))
              return qint64(-1);

    ::DWORD readBytes = 0;
    if (::ReadFile(this->descriptor, (PVOID)data, (DWORD)len, &readBytes, &this->oRead)) {
    }
    else {
        ::DWORD rc = ::GetLastError();
        readBytes = (ERROR_IO_PENDING == rc) ? (0) : (-1);
    }

    return qint64(readBytes);
}

Сообщение отредактировал kuzulis - 19.2.2011, 14:41

[sh2ka]

kuzulis
Windows XP/7, QSerialDevice (master), mingw32 4.5.2 dwarf2.

Я уже писал по поводу поддержки библиотекой виртуальных портов. В частности, о поддержке виртуальных портов VSPE (virtual serial port emulator). Аналогичная проблема наблюдается и для виртуальных портов для устройства MOXA NPort (удаленные порты через Ethernet). Люди используют виртуальные порты не чуть не реже, чем реальные (возможно, даже чаще: usb-com, ethernet-com, ...), а поддержки этих портов в библиотеке нет. Хотелось бы видеть эти порты в списке портов. Возможно разделение этих списков в API библиотеки:

• phisicalDevicesAvailable() - получение реальных портов
• allDevicesAvailable - получение всех портов

Хотя это выглядит не хорошо. Может быть можно как-то отображать эти устройства в списке независимо от того, можно отслеживать их исчезновение или нет - если нет возможности отслеживать появление и исчезновение порта в системе, то пусть оно всегда будет в списке (это ведь не криминал).
Т.о. поскольку записи портов в реестре дублируются (но не всех портов), то можно отслеживать появление/исчезновение только реальных портов в ветке [HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\services\\...], а для прочих устройств (у которых нет двойника в указанной ветке) - нет. Под прочими портами подразумеваются порты из [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM], которых нет в [HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\services\\...].

Как вариант, можно сделать опцию для включения/отключения поддержки виртуальных портов в qserialdeviceenumerator, хотя это странновато, т.к. порты спокойно открываются с помощью qserialdevice как реальные, так и виртуальные, однако, последних нет в списках - ДИСКРИМИНАЦИЯ!!!

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

Много написал, но смысл прост - люди недоумевают: почему нельзя показать в списке виртуальные порты (они что, какие-то не такие, недоделанные что-ли?), чтобы их можно было выбрать, тем более, что они имеют линейное пространство имен вместе с реальными: COM1, COM2, COM3, ...

И, собственно, вопрос: можно ли как-то сделать, чтобы в списке отображались все реальные и виртуальные порты системы?

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

Я проверил под виндой. Да, таже проблемка . Но я знаю как решить.. Просто нужно "слушать" другие ветки реестра и все должно быть нормуль.

У меня это вызывает недоумение: как физический (настоящий) COM-порт может взять и исчезнуть из системы - "на горячую"? - но это аварийная тогда ситуация и нет смысла ее обрабатывать; или usb-com - тогда это уже виртуальный порт - опять неувязочка. Одним словом непонятно, чем не устраивает ветка реестра [HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM], в которой просто и понятно представлены все порты - ОС уже позаботилась о том, кому нужен список портов - просто возьми?

Есть еще один способ получить список портов системы, который мы использовали раньше в своем коде под WinAPI: QueryDosDevice, в которую передается имя утройства, которое проверяется на наличие - можно простым перебором от COM1 до COM255 быстро проверить наличие всех доступных портов, хотя это может быть не совсем правильным решением.

[kuzulis]

или usb-com - тогда это уже виртуальный порт - опять неувязочка.

Ну так его же можно выдернуть, ведь правда?! И он же исчезнет!?
Не вижу неувязочек.

Я уже писал по поводу поддержки библиотекой виртуальных портов.

Поддержка имеется, и я не пойму к чему такая "экспрессия".

В частности, о поддержке виртуальных портов VSPE (virtual serial port emulator).

Этот софт реализован через (Ж), и эти порты не определяются в диспетчере устройств.
Поэтому для енумератора их нет!
Тем более, нельзя вытянуть никакой информации об этом виртуальном устройстве (ну, кроме его имени).
Этот софт оставляет в реестре о себе информацию только в одном месте :
[HKEY_LOCAL_MACHINE\HARDWARE\DEVICEMAP\SERIALCOMM] и всё.
Какой черт я буду из-за какой-то хрени что-то переписывать?
Используйте вместо VSPE софт от Eltima (или com0com на крайняк).

Аналогичная проблема наблюдается и для виртуальных портов для устройства MOXA NPort (удаленные порты через Ethernet).

Я в курсе что такое MOXA NPort.
Если после установки ПО от MOXA эти порты появляются в диспетчере устройств - то не вижу никаких проблем в том, чтобы добавить их поддержку.
Для этого мне нужна кое-какая дополнительная информация: class GUID этого устройства.
Если же оно оставляет о себе инфу аналогично VSPE - то увы...

почему нельзя показать в списке виртуальные порты (они что, какие-то не такие, недоделанные что-ли?),

Зависит от производителя ПО, но в большинстве случаев - да, недоделанные.

[kuzulis]

Я в курсе что такое MOXA NPort.
Если после установки ПО от MOXA эти порты появляются в диспетчере устройств - то не вижу никаких проблем в том, чтобы добавить их поддержку.
Для этого мне нужна кое-какая дополнительная информация: class GUID этого устройства.
Если же оно оставляет о себе инфу аналогично VSPE - то увы...

Сегодня проверил на MOXA NPort 5130 - и всё работает "из каропки"!!!
Так что вы сначала определитесь и проверьте - а потом что-то предъявляйте!