Прием 9-го бита, КОМ-порт, винда

[paskal]

Добрый вечер!
С КОМ-портом работать приходилось. Пользовался стандартными функциями MSDN Createfile, ReadFile. Но возникла новая задача. Устройство отправляет 9-битные посылки. И надо прочесть все биты. С приемом 8 бит все ясно - функция ReadFile. А как принять девятый бит?

[petrenko]

Шутить изволите ?

"Проверка ошибки чётности" - Вам что-нибудь говорит ?

[paskal]

Говорит. Но интересуют подробности. И в частности когда во входной буфер попало несколько посылок как вычислить этот бит для каждой.

[petrenko]

Никак. Придётся отказаться от буфера и каждую 9-битовую последовательность обрабатывать явно ( с наивысшим приоритетом, чтоб не терять ничего. ) Сие в учебниках вообще то написано давным давно ..

[paskal]

А нет ли каких более низкоуровневых API чем Createfile/ReadFile?
Боюсь что приоритет не поможет при использовании переходников COM-USB.

[Мурик]

А нет ли каких более низкоуровневых API чем Createfile/ReadFile?

Native API. https://msdn.microsoft.com/en-us/library/bb432380

[paskal]

Native API. https://msdn.microsoft.com/en-us/library/bb432380

Ну допустим я заменю Createfile на NtCreatefile, ReadFile на NtReadFile. Это что то даст в плане сабжа? Учитывая что это такой же потоковый ввод/вывод.
А как насчет работы с КОМом через IOCTL?

[Мурик]

Тогда пишите драйвер.

[paskal]

Тогда пишите драйвер.

Зачем? Он же в системе уже есть - serial.sys, только я не знаю как с ним работать

[kalobyte]

олько я не знаю как с ним работать

это не тот драйвер, тебе нужен прямой доступ к регистрам мелкасхемы

dlportio например для железных портов

[paskal]

олько я не знаю как с ним работать

это не тот драйвер,

Почему? Это точно драйвер ком-порта, можно в диспетчере устройств убедится.
В частности, похоже что eltima serial port monitor работает с этим драйвером через irp пакеты

тебе нужен прямой доступ к регистрам мелкасхемы

dlportio например для железных портов

И что он дает? Прерывания или события он не обеспечит. Для приема придется опрашивать ком порт из user mode. Никаких преимуществ по сравнению со стандартными методами через файловый в/в.

[kalobyte]

а какие прерывания ты ждеш от него? это тебе не контроллер
и виндовс не ртос
для прерываний есть дополнительные провода

[paskal]

а какие прерывания ты ждеш от него? это тебе не контроллер
и виндовс не ртос
для прерываний есть дополнительные провода

Ну вообще то ком порты всегда имели прерывания. IRQ4 и IRQ3 для COM1 и COM2 соответственно (кстати тоже в диспетчере устройств видно). А как еще без них обойтись? Иначе данные теряться будут.

[kalobyte]

эти прерывания не то, что ты думаеш
данные не будут теряться, если ты будеш использовать стандартизированные режимы работы порта
например пакеты будут теряться, если использовать порт в режиме протокола дмх512
поэтому для него используют переходник на базе контроллера, юарт которого может работать в таком режиме (в авр это реализовано переключением скорости для передачи одного бита)

усб переходник на базе фт232 реализует это через родной драйвер, которые задействует внутренние ресурсы этого моста

а то, о чем ты говориш - начало прихода данных и все такое - реализовано через дополнительные провода и раньше именно так и работало

а в софте под виндовс есть таймеры и потоки, поток запускается по таймеру и в потоке опрашивается порт, очищая буфер и перекидывая данные в основной поток, где они и выводятся
вот это и есть то "прерывание"

а те железные прерывания они использовались в досе, а дос однозадачная система и там естественно требовалось прервать работу основной задачи и сгонять в обработчик прерывания и забрать данные

[Мурик]

Ну вообще то ком порты всегда имели прерывания. IRQ4 и IRQ3 для COM1 и COM2

Они доступны только в ядру. Даже драйверы напрямую не имеют доступа к ним. Какой вам смысл от них? Тем более что в случае USB переходника, о прерываниях и речи быть не может.

[nds]

на ft232 точно была подходящая библиотека