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

[kuzulis]

А-А-А Help!

Решил попробовать добавить поддержку WinCE путем её "эмуляции" (т.е. открываю порт без FILE_FLAG_OVERLAPPED)
и наткнулся на грабли.

Т.е. как планировалось работать:

Для уведомлений о событиях порта используется отдельный поток в котором крутится:

Код

C++ (Qt)
void SerialPortNotifier::run()
{
    while (m_running) {
 
        m_setCommMaskMutex.lock();
        ::SetCommMask(m_ref->m_descriptor, m_setMask);
        m_setCommMaskMutex.unlock();
 
        if (::WaitCommEvent(m_ref->m_descriptor, &m_currentMask, 0) != 0) {
            if (EV_ERR & m_currentMask & m_setMask) {
                m_ref->canErrorNotification();
            }
            if (EV_RXCHAR & m_currentMask & m_setMask) {
                m_ref->canReadNotification();
            }
            //FIXME: This is why it does not work?
            if (EV_TXEMPTY & m_currentMask & m_setMask) {
                m_ref->canWriteNotification();
            }
        }
    }
}
 

т.е. при открытии порта (с нулевым dwFlagsAndAttributes)

Код

C++ (Qt)
...
    m_descriptor = ::CreateFile((const wchar_t*)nativeFilePath.constData(),
                                desiredAccess, shareMode, 0, OPEN_EXISTING, flagsAndAttributes, 0);
...
 

запускается поток в котором происходит отлов событий порта.

И т.к. WinCE не поддерживает асинхронных (OVERLAPPED) операций I/O, то поток
заблокируется на WaitCommEvent и будет вечно ждать пока не произойдет какое-то событие.

Тут всё работает "корректно", поток блокируется на  WaitCommEvent.

НО грабли начинаются, если я из главного потока (да думаю и из любого другого)
пытаюсь изменить настройки DCB порта, вызывая SetCommState.

А именно, эта функция SetCommState почему-то не возвращает управление немедленно,
а блокируется вечно!

Разблокировка происходит автоматически и она возвращает результат, только если
отработает WaitCommEvent в другом потоке, т.е. если появится любое событие в порте.

Нигде описания подобного поведения в MSDN я не встречал.

Кто что может посоветовать в этой ситуации?
Получается, невозможно одновременно и менять настройки порта и ловить события!

Останавливать поток перед переконфигурированием порта не айс.

Если же открывать порт с флагом FILE_FLAG_OVERLAPPED и с потоком в котором также WaitCommEvent блокируется, то
SetCommState не зависает.

PS: И кстати, WaitCommEvent блокирует любые коммуникационные функции при работе с текущим дескриптором порта.

[kuzulis]

Большая просьба ко всем, у кого имеется WinCE, кто заинтересован в поддержке WinCE в QSerialDevice и у кого есть несколько минут свободного времени,
провести пару тестов:

http://www.forum.crossplatform.ru/index.php?showtopic=7357

См. там ниже пост №9

[kuzulis]

Итак, я попробовал добавить поддержку WinCE:

https://gitorious.org/qserialdevice/qserialdevice/archive-tarball/2.0

Огромная просьба ко всем - протестировать и проверить!

ЗЫ: иначе я положу болт на всё, т.к. не вижу особого участия.

[b-s-a]

kuzulis, возьми отпуск - отдохни. Летом мозги у людей вообще туго работают. Потерпи до октября. Тогда все начнут приходить в себя и подключатся.

[kuzulis]

Итак, я попробовал добавить поддержку WinCE:
https://gitorious.org/qserialdevice/qserialdevice/archive-tarball/2.0
Огромная просьба ко всем - протестировать и проверить!

Я подправил и добавил кое что для Win CE. Теперь проект собирается.
Но нужно протестировать реальную работу.

[navrocky]

огромное спасибо за либу)
Я недавно ее заюзал для написания терминальчика (minicom меня замучал). Столкнулся с проблемой что на ядре 2.4 не компилится, потому что хочет udev, которого там нет, можно как-нибудь исключить udev? Я готов даже это сделать сам и прислать патч )

[kuzulis]

navrocky, ну, не компиль класс SerialDeviceEnumerator, т.к. udev только там используется.
В файле проекта закоментируй всё что с этим связано.

Хотя, в новой ветке 2.0 планируется (и уже имеется) возможность при компиляции включать/отключать поддержку Udev, но, правда пока не очень удачно: нужно для этого редактировать исходники и *.pro файл.

[navrocky]

Ок, попробую. Спасибо. В принципе для цмейка можно конфигурилкуз прикрутить.

[kuzulis]

Я подправил и добавил кое что для Win CE. Теперь проект собирается.
Но нужно протестировать реальную работу.

Библиотека для WinCE теперь работает!
Проверено на эмуляторе Pocket PC.

PS: Только необходимо разобраться с именованием последовательных устройств(портов) в WinCE,
т.к. там, как минимум, возможны два варианта:

1. $device/COM1
2. COM1:

и все они рабочие (т.е. порт открывается что так что так).

Эти имена извлекаются при помощи FindFirstDevice()
в структуру: DEVMGR_DEVICE_INFORMATION
в которой есть поля:

Код

C++ (Qt)
typedef struct _DevmgrDeviceInformation_tag {
  DWORD dwSize;
  HANDLE hDevice;
  HANDLE hParentDevice;
  WCHAR szLegacyName[6];
  WCHAR szDeviceKey[MAX_PATH];
  WCHAR szDeviceName[MAX_PATH];
  WCHAR szBusName[MAX_PATH];
} DEVMGR_DEVICE_INFORMATION, *PDEVMGR_DEVICE_INFORMATION;
 

где

dwSize
    Size of this structure.
hDevice
    Device handle obtained from ActivateDeviceEx.
hParentDevice
    Parent device's handle obtained from ActivateDeviceEx.
szLegacyName
    Legacy device name, for example, "COM1:".
szDeviceKey
    Registry key path passed to ActivateDeviceEx.
szDeviceName
    Device name in the $device namespace.
szBusName
    Device name in the $bus namespace.

соответственно, я беру поля szDeviceName и szLegacyName как имя и локацию.

Поэтому надо как-то придумать какое имя к чему отнести: или к имени порта или к локации порта - ХЗ, т.к. и так и так оно работает.
И в связи с этим,также, нужно как-то модифицировать методы: setPort() и portName().

[b-s-a]

COM1 - название
$device/COM1 - локация

в setPort можно передавать как название, так и локацию
метод port() возвращает всегда полную локацию
portName() только название

[juvf]

Вобщем нашел закономерность. У меня в компе есть 2 ком порта. COM1 на материнской плате, "честный" компорт. СОМ7 - преобразователь USB<->RS-232 на чипе prolific. Если мастеру назначаю СОМ1, т.е. "честный", а редэру СОМ7, то все работает без сбоев. Но если мастеру указываю порт СОМ7, а редэру СОМ1 - то ошибки долго не заставляют ждать. Сыпятся.
По хорошему надо бы выкинуть этот prolific и поставить нормальный преобразователь, типа ftdi, но дело в том, что подобный баг наблюдал и с преобразователями на чипах ftdi, и на USB GSM модемах.

Ага... Ок, проверю это дело... (Уменя в тестах мастер был "мамкин" порт, а слейв - "пролифик" PL2303)  

Не подтверждаю "ошибки". У меня работает как часы.
OS: Win7 x32
Шнурок: PL2303
Драйвер:
- поставщик Prolific
- дата разработки 19.11.2009
- версия 3.3.10.140

Давно уже переписал свое приложение на WinAPI и забыл про эту проблему. Вчера коллеги бились о стену со своим приложением. Иногда обмен сбивается. Они в две головы решали эту проблему, багу в коде искали. Сегодня к обеду проблему решили )). Я поинтересовался - где была ошибка..... А они просто поменяли преобразователь. Ну я не удивился, когда выяснил чем они пользуются для связи с компортом - старая знакомая библиотека для компорта под Qt. 
Причем я грешил на Prolific, но они поставили другой преобразователь, тоже на Prolific-е и всё работает. А глючило и у меня и у них на преобразователе TU-S9. Может преобразователь кривой..... однако с GSM-модемом (Novacom) я такой-же глюк наблюдал, а с этим "глючным" TU-S9 на WinAPI всё работает как часы, без сбоев.

ps давно не слежу за развитием этой библиотеки, т.к. не использую, но может уже эту багу всё таки обнаружил автор и пофиксил.

[sne]

kuzulis, плз глянь вот эту строчку-то, вылетает же..

Код:

qserialdevice$ git diff
diff --git a/src/qserialdevice/nativeserialnotifier_unix.cpp b/src/qserialdevice/nativeserialnotifier_unix.cpp
index 753c7f4..4ab3f79 100644
--- a/src/qserialdevice/nativeserialnotifier_unix.cpp
+++ b/src/qserialdevice/nativeserialnotifier_unix.cpp
@@ -114,7 +114,7 @@ bool NativeSerialNotifier::eventFilter(QObject *obj, QEvent *e)
         this->engine->exceptionNotification();
         return true;
     }
-    return NativeSerialNotifier::eventFilter(obj, e);
+    return QThread::eventFilter(obj, e);
 }
 
 void NativeSerialNotifier::run()

[kuzulis]

COM1 - название
$device/COM1 - локация

в setPort можно передавать как название, так и локацию
метод port() возвращает всегда полную локацию
portName() только название

Cмотри внимательнее! Там не COM1, а COM1: .
т.е. открыть можно и как "COM1" и как "COM1:" и как "$device/COM1"

И как парсить и что во что преобразовывать - пока не очень понятно,
тем более, в WinCE есть и другие последовательные устройства отличные от COM (например Bluetooth и т.п.) и их имена также нужно учитывать.

Ну это ладно, попробую разобраться.

kuzulis, плз глянь вот эту строчку-то, вылетает же..

Ок, поправил.

[kuzulis]

Всем доброго времени.

Вопрос к знатокам ОС Symbian!

Я нарыл немного информации (на сайте нокии) по API для доступа к последовательным портам в ОС Symbian
и непонятен один момент.

Там, одним из методов класса RComm является метод NotifyDataAvailable()

NotifyDataAvailable()

Capability:    Illegal    

IMPORT_C void NotifyDataAvailable(TRequestStatus &aStatus) const;
Description

Notifies the client when data is available to be read from the input buffer.
Parameters
TRequestStatus &aStatus    

On return, system wide error code for asynchronous function.

Т.е. оно как-то должно уведомлять об поступлении в приемный буфер порта данных, доступных для чтения.

Внимание, вопрос:
1. Каким образом мне отловить это уведомление?
2. Как в симбе построена система уведомлений/нотификации?
3. Где б об этом можно почитать подробнее и/или может есть любые "левые" примеры с использованием
нотификации?

[kuzulis]

Люди!

Кто шарит в программировании для Symbian,
нужна помощь в реализации методов
- SerialPort::read()
- SerialPort::write()

а то я что-то запутался с преобразованием/приведением  симбиановских буферов типа TBuf8 и т.п. к *char и т.п.

Я уже реализовал и проверил на эмуляторе класс SerialPortInfo - он работает  (я сцуко крут!) ,
и для класса SerialPort реализовал основные его методы (кроме вышеперечисленного и пр.).

Кому интересно - можете потестить у себя на реальных девайсах с симбианом.