Неоднократно приходилось работать с портом LPT напрямую через пространство портов в/в. Под виндой для этого написано множество драйверов, inpout32 например, и все прекрасно работают. Возникла нужда поработать также на низком уровне с COM портом. Казалось бы такая же задача, только адреса в/в другие, но нет! Не видит драйвер его адресов вообще! Обращения к 3F8 и другим возвращают только FF как будто устройство отсутствует физически. Может тот драйвер не годится для такого адреса? Посоветуйте какие драйвера годятся для работы с COM портом через регистры.
paskal, у меня i3-3210, COM1 ― диапазон ввода/вывода=3F8-3FF, IRQ=4 наверное, у всех также Еще можно через CreateFile,'COM1',GENERIC_READ,0,0,OPEN_EXISTING,0,0 посмотри в Ещё раз о прямом доступе к аппаратуре Автор: Сивцов П. RSDN Magazine #4-2004
CreateFile я пользыуюсь. И в синхронном, и в асинхронном режимах. Но сейчас не тот случай. Надо принимать посылки в 9 бит. API этого сделать не могут.
Если верить гуглу, 9 бит это RS-485 и наверное не совсем корректно из RS-232 такое лепить. Зная насколько чувствительны последовательные интерфейсы к таймингам, мне вот совсем не кажется отличной затеей использовать колхоз типа крохотного примитивного драйвера inpout32 тупо как посредника, которому с юзермода что-то засылать. Тем более стоят rs-485 адаптеры 500-1000 рублей, ради экономии этих денег не стоит так упарываться.
Вы видимо не поняли. Нет никакой речи о таймингах с помощью драйвера. Речь о программировании контроллера COM порта, тайминги также вырабатывает контроллер как и программировании через CreateFile. И у нас стоит rs-485 адаптер. Адапртер это всего лишь преобразователь уровней от rs-232 к rs-485, проблему с 9-битной посылкой он не решает. И вообще, предложения с покупкой нового железа не годятся. Проблема возникла с серийныйным изделием которое лет 20 как разработано, менять отработанное железо никто не даст. Софт тогда был под ДОС и проблем не было. Теперь надо сделать тоже самое под виндой.
Будем считать, что это я о своем. Если управлять устройством с юзермода, лаг может составить 1-2мс. Почитал подробней. Как я понял 9й бит не фича, а скорей народное творчество: dcb.fParity=1 и по идее можно проверять parity error GetCommMask'ом с EV_ERR. Как альтернатива виндовым апям есть ftdi-интерфейсы со своим драйвером и своей интерфейсной библиотекой ftd2xx.dll. Включается parity FT_SetDataCharacteristics'ом, parity error проверяется маской 0x0400 от статуса, возвращаемого FT_GetModemStatus.
И с FT мы тоже работали. Тут проблема в особенности USB интерфейса. USB работает с блоком, а не с отдельным байтом как это можно в RS-232. Поэтому проверить паритет можно для всего пакета, а отдельные байты недоступны. Нашу задачу это не решает. Кроме того USB вносит задержки. И повторяю. НЕЛЬЗЯ ДОБАВЛЯТЬ НОВОЕ ЖЕЛЕЗО. Нужно программное решение.
Ну если никакое железо добавлять нельзя, мои полномочия всё. Гугл говорит, что одна коммерческая библиотека умеет в 9 бит: https://www.adontec.com/9-bit-serial-communication.htm, есть даже отдельное упоминание, что бесплатная демо-версия в такое может. Можешь ее попробовать.
Подборка от Mikl___: Зачем нужен драйвер и как написать простейший драйвер тоже есть на Wasm но может в нескольких темах. Почему все как ссылка?