QSerialDevice - Библиотека для работы с COM-портами |
Здравствуйте, гость ( Вход | Регистрация )
QSerialDevice - Библиотека для работы с COM-портами |
BRE |
18.2.2011, 22:45
Сообщение
#211
|
Профессионал Группа: Участник Сообщений: 1112 Регистрация: 6.3.2009 Из: Ростов-на-Дону Пользователь №: 591 Спасибо сказали: 264 раз(а) Репутация: 44 |
Поэтому всё нафик удаляем и считаем что сколько байт записали - столько и записалось! Иного способа (кроме потоков) я не вижу. Такое допущение можно сделать в конкретной программе, работающей с конкретной железкой и будучи абсолютно уверенным что все будет реально записано, но, IMHO, для библиотеки это не выход. Я так понимаю, что это ожидание происходит у тебя же в библиотеке, только уровнем выше? |
|
|
kuzulis |
19.2.2011, 10:23
Сообщение
#212
|
Активный участник Группа: Участник Сообщений: 393 Регистрация: 29.6.2009 Пользователь №: 862 Спасибо сказали: 36 раз(а) Репутация: 7 |
Цитата Такое допущение можно сделать в конкретной программе, работающей с конкретной железкой и будучи абсолютно уверенным что все будет реально записано, но, IMHO, для библиотеки это не выход. Ну иначе (для винды) я не знаю иного выхода. В винде реальное кол-во записанных байт можно узнать только после завершения операции IO (т.е. не WriteFile их возвращает, а GetOverlappedResult). Поэтому есть два выхода (для винды): 1. Или ждать завершения и получить реальное кол-во записанных байт (но это фризы) 2. Или не ждать завершения и считать что все что передали передастся. BRE, если у тебя есть иные мысли то поделись. Цитата Я так понимаю, что это ожидание происходит у тебя же в библиотеке, только уровнем выше? Нет, что касаемо записи - то нет. Если рассматривать винду - то ожидание происходит в nativeWrite (через WaitForSingleObject + GetOverlappedResult). А если linux - то никакого ожидания нет в принципе вообще. |
|
|
BRE |
19.2.2011, 12:11
Сообщение
#213
|
Профессионал Группа: Участник Сообщений: 1112 Регистрация: 6.3.2009 Из: Ростов-на-Дону Пользователь №: 591 Спасибо сказали: 264 раз(а) Репутация: 44 |
BRE, если у тебя есть иные мысли то поделись. Ну в свете твоих объяснений - мыслей нет. Я не силен в том, как работает венда с последовательным портом, поэтому увидев эту функцию, по аналогии с linux, предположил, что стоит проверять, а что же реально записалось. Если реально это значение возвращается и можно проверить где-то еще, то ты выбрал вполне нормальное решение. |
|
|
Гость_Гость_kuzulis_*_* |
19.2.2011, 12:54
Сообщение
#214
|
Гости |
Цитата по аналогии с linux, предположил, что стоит проверять, а что же реально записалось. Ну так в линуксе (если неблокирующий дескриптор/сокет) ,ИМХО, ф-я write тоже может возвратить меньшее кол-во байт чем мы пишем. Но это не значит, что записалось столько - сколько она возвратила. Поэтому, ИМХО, судить о том сколько байт записалось по возвращаемому функциями write (что в винде, что в линуксе) нельзя. Хотя, могу ошибаться . |
|
|
kuzulis |
19.2.2011, 12:55
Сообщение
#215
|
Активный участник Группа: Участник Сообщений: 393 Регистрация: 29.6.2009 Пользователь №: 862 Спасибо сказали: 36 раз(а) Репутация: 7 |
Блин, зарегаться забыл.
|
|
|
rcdimon |
19.2.2011, 13:31
Сообщение
#216
|
Студент Группа: Участник Сообщений: 69 Регистрация: 27.10.2009 Пользователь №: 1183 Спасибо сказали: 1 раз(а) Репутация: 0 |
Хм... Я вроде говорил, что тормозит при приеме, а не при отправке )
|
|
|
kuzulis |
19.2.2011, 14:38
Сообщение
#217
|
Активный участник Группа: Участник Сообщений: 393 Регистрация: 29.6.2009 Пользователь №: 862 Спасибо сказали: 36 раз(а) Репутация: 7 |
Хм... Я вроде говорил, что тормозит при приеме, а не при отправке ) Ну тогда попробуй такой код:
Сообщение отредактировал kuzulis - 19.2.2011, 14:41 |
|
|
sh2ka |
23.2.2011, 22:05
Сообщение
#218
|
Новичок Группа: Новичок Сообщений: 4 Регистрация: 23.2.2011 Пользователь №: 2437 Спасибо сказали: 0 раз(а) Репутация: 0 |
kuzulis
Windows XP/7, QSerialDevice (master), mingw32 4.5.2 dwarf2. Я уже писал по поводу поддержки библиотекой виртуальных портов. В частности, о поддержке виртуальных портов VSPE (virtual serial port emulator). Аналогичная проблема наблюдается и для виртуальных портов для устройства MOXA NPort (удаленные порты через Ethernet). Люди используют виртуальные порты не чуть не реже, чем реальные (возможно, даже чаще: usb-com, ethernet-com, ...), а поддержки этих портов в библиотеке нет. Хотелось бы видеть эти порты в списке портов. Возможно разделение этих списков в API библиотеки:
Хотя это выглядит не хорошо. Может быть можно как-то отображать эти устройства в списке независимо от того, можно отслеживать их исчезновение или нет - если нет возможности отслеживать появление и исчезновение порта в системе, то пусть оно всегда будет в списке (это ведь не криминал). Т.о. поскольку записи портов в реестре дублируются (но не всех портов), то можно отслеживать появление/исчезновение только реальных портов в ветке [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 |
23.2.2011, 23:06
Сообщение
#219
|
Активный участник Группа: Участник Сообщений: 393 Регистрация: 29.6.2009 Пользователь №: 862 Спасибо сказали: 36 раз(а) Репутация: 7 |
Цитата или 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 |
24.2.2011, 12:50
Сообщение
#220
|
Активный участник Группа: Участник Сообщений: 393 Регистрация: 29.6.2009 Пользователь №: 862 Спасибо сказали: 36 раз(а) Репутация: 7 |
Я в курсе что такое MOXA NPort. Если после установки ПО от MOXA эти порты появляются в диспетчере устройств - то не вижу никаких проблем в том, чтобы добавить их поддержку. Для этого мне нужна кое-какая дополнительная информация: class GUID этого устройства. Если же оно оставляет о себе инфу аналогично VSPE - то увы... Сегодня проверил на MOXA NPort 5130 - и всё работает "из каропки"!!! Так что вы сначала определитесь и проверьте - а потом что-то предъявляйте! |
|
|
Текстовая версия | Сейчас: 11.12.2024, 13:20 |