А-А-А 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 блокирует любые коммуникационные функции при работе с текущим дескриптором порта.

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

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

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

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

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

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

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

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

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

Эти имена извлекаются при помощи 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;
 

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

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

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

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

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

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

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

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

Люди!

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

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

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

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