» устройство на COM порту, драйвер

ArtSh
просмотрев выше...


Цитата:

Это спектрофотометр, предполагаются разные его варианты с LPT, COM или USB интерфейсом. Желательно, что это был один драйвер, а не 3.

из перечисленных интерфейсов разве что для USB придется писать драйвер. В любом случае у него будет некий wrapper на прикладном уровне. Для двух других интерфейсов все останется только на прикладном уровне, т.к. драйвера COM и LPT в WDM есть. Суть драйвера COM не сильно отличается отличается от непосредственной работы с микросхемой 8250. Сделать драйвер лучше стандартного... не стоит. Чем один драйвер всего лучше трех, но каджый для своего - не понятно.


Цитата:

в этом случае часть управляющих сигналов фотоприемника будет генерировать компьютер, благодаря этому можно будет достигнуть проведения измерения в реальном времени

Даже на уровне ядра никакого реального времени в Win32 не получить, это не ОСРВ. Реальное время должно быть заложено на уровне операционной системы, а если вы хотите организовать локальное реальное время для своего драйвера - ничего не выйдет.

А в целом смотри мой ответ выше про opentcp.

Rustam_Koviazin
Блогодарая непосредственному обращению к регистрам вполне реально для Win получить промежуток времени с точностью до 1 мс. Этого вполне достаточно.

ArtSh

Цитата:

Блогодарая непосредственному обращению к регистрам

К регистрам чего? Процессора, 8250?


Цитата:

вполне реально для Win получить промежуток времени с точностью до 1 мкс

это не есть критерий real-time


Цитата:

Этого вполне достаточно.

ни ты, ни ОС не гарантируют, что каждую мкс твоему драйверу будет передано управление

ArtSh

Цитата:

Блогодарая непосредственному обращению к регистрам вполне реально для Win получить промежуток времени с точностью до 1 мкс. Этого вполне достаточно.

Наверно я не правильно сформулировал.
Благодаря непосредственному доступу к регистрам процессора можно использовать нестандартные протоколы обмена с периферией, а при управлении данным устройством, важно чтобы сигналы с порта приходили с точногстью прибл. 1мс. Такую точность Win волне обеспечивает.

ArtSh

Цитата:

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

Что за нестандартные протоколы обмена с периферией? Когда ты работаешь с COM через CreateFile, ReadFile, ты что, обмениваешься с микросхемой по какому-то особому протоколу? Почитай описание 8250. В общем ты с нее можешь получать/передавать байты по опросу, по прерыванию. Большего, чем в ней есть, из нее не вытащить. И стандартные драйвера все это умеют. Может ты думаешь, что программа Hyperterminal, умеющая передавать/принимать файлы по протоколу Zmodem, а также включающая много других вкусностей, работает с COM в обход стандартного драйвера?

Если ты хочешь общаться с 8250 через порты, то на прикладном уровне это у тебя получится разве что под Win9X. В других Win32 системах тебя встретил HAL и подставиться вместо микросхемы. Ты будешь работать только с ним.


Цитата:

важно чтобы сигналы с порта приходили с точногстью прибл. 1мс.

Этого можно добиться и на прикладном уровне, если ограничить процессы, выполняющиеся в системе, задрать производительность. В общем случае никто не гарантирует тебе этой милисекунды ни на уровне ядра, ни на прикладном уровне. Ну не ОСРВ это!

Rustam_Koviazin
Если почитать выше, то станет ясно, что не стандартно я общаюсь с LPT портом.

На прикладном уровне это точно не получиться, попробуй!
Масимум, что можно выжать это 1МКС.
А в режиме ядра на уровне DISPATCH_LEVEL уже можно это сделать, не говоря о более высоких.

ArtSh
интересно такая скорость стандартна или это вам так повезло с контроллером LPT/кабелем?

Rustam_Koviazin
Я пробовал на кабелях до 3 метров, обычных китайских и более длинных экранированных. А в протоколе LPT интерфейса написана скорость 2 мб/с. Так что это не предел.

ArtSh
Тормоза работы с LPT (как и с COM) вероятно были из-за желания на прикладном уровне работать с микросхемами LPT (соответственно COM). Поскольку HAL перехватывает все эти обращения, то обрабатывает их прграммно, из-за этого и тормоза. Если же с этими устройствами работать стандартными средствами как с файлами, то все должно быть быстрее.

Rustam_Koviazin
HAL НЕ перехватывает их( трудно перехватить ч-л в кольце защиты 0), и тормозов никаких нет. Просто нужно сделать то что написано, т. к. драйвер LPT уже давно работает.

ArtSh
Я говорил о прикладном уровне. На прикладном уровне вы через Win32 API работали с LPT?


Цитата:

HAL НЕ перехватывает их( трудно перехватить ч-л в кольце защиты 0), и тормозов никаких нет

Предлагаю сразу все написать под MS-DOS, но и это вы не сделаете ибо ТЗ.

Rustam_Koviazin

Цитата:

через Win32 API работали с LPT?

Конечно же нет.



Цитата:

Предлагаю сразу все написать под MS-DOS

Где же найти чистый ДОС, это во первых, а во вторых очень неудобно работать в ДОС.

И вообще может кто - нибудь ответить по делу?

ArtSh

Цитата:

Конечно же нет.

тогда я уже говорил в чем была проблема


Цитата:

очень неудобно работать в ДОС

а какая разница где с портами работать?


Цитата:

И вообще может кто - нибудь ответить по делу?

Если тебя интересуют не возможные способы решения задачи, а создание WDM-драйвера, то думаю никто не ответит.

В общемто мне стало понятно, что написать стек драйверов довольно трудно, и я решил воспользоваться ZwreadFile(), в связке с ZwOpenFile(), и ZwDeviceIoControlFile().