Форум РадиоКот

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

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

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

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

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

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

paskal писал(а):А нет ли каких более низкоуровневых API чем Createfile/ReadFile?

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

Мурик писал(а):Native API. https://msdn.microsoft.com/en-us/library/bb432380

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

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

Мурик писал(а):Тогда пишите драйвер.

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

paskal писал(а):олько я не знаю как с ним работать

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

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

kalobyte писал(а):

paskal писал(а):олько я не знаю как с ним работать

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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