Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | |
Чего-то там сказал типа... Это называется "пердеть клавиатурой" ;-) 26.10.04 08:09 Число просмотров: 1814
Автор: HandleX <Александр М.> Статус: The Elderman
|
Долго думал — штрафовать, не штрафовать?
Но решил, что как-бы человек что-то все-таки имеет в голове, а не только может сотрясать воздух нажатиями на клаву.
Может, всё-таки скажет чего конструктивного? ;-)
|
|
<programming>
|
[C++] Драйвер для COM порта 13.10.04 13:34
Автор: Федя Статус: Незарегистрированный пользователь
|
Вопрос в первую очередь к Leo...
ВОПРОС: COM порт, можно ли решить лимитирование времени?
Постановка задачи
---------------------------------
Нужно написать программу под ОС Windows 2000, которая реализует взаимодействие с устройством через последовательный порт (RS-232) на скорости 4800 бод. Компьютер должен принимать поток байт, если в потоке приходят 2 определенных байта, то нужно за 65 миллисекунд от момента их приема послать заранее подготовленных 20 байт. Управление потоком и т.п. не используется, устройство никак не контролирует приём байт компьютером, компьютер никак не контролирует устройство.
Проблема заключается в том, чтобы уложиться в эти 65 миллисекунд (это предельное значение), а желательно меньше 20-40 миллисекунд.
По моей оценке* на основе тестового приложения это невозможно сделать в рамках пользовательского Win32 приложения.
Вопросы
---------------------------------
Возможно ли решить эту задачу путём написания драйвера последовательного порта (или внесением модификации в существующий драйвер serial.sys, если я правильно понял пример из DDK под Windows 2000 и есть этот драйвер)?
По моей оценке на основе исходников serial.sys проанализировать получение 2 байт можно непосредственно в обработчике прерывания (функция SerialISR()), остается инициировать из обработчика прерываний запись 20 байт в порт. Возможно ли сделать это в указанных временных рамках и если да, то по какой схеме это сделать?
Можно реализовать задачу не через собственный драйвер, а обращаясь к существующему драйверу** из режима ядра используя Irp запросы?
Может быть такое, что задачу можно реализовать из пользовательского приложения?
Какую информацию и где можно посмотреть по данным вопросам?
Примечания
---------------------------------
* Оценка времени получена следующим образом. Время измерялось функцией GetTickCount(). Написано 2 тестовые программы (используются вызовы WinAPI), которые взаимодействуют с друг другом через последовательный порт (2 компьютера соединены через нуль-модемный кабель). Первая (программа А) посылает 2 байта и принимает 20 байт, вторая (программа B) ждет приёма 2 байт и посылает 20 байт. Если в программе А сделать задержку (Sleep()) меньше 120 мс, то будет приходить меньше 20 байт в рамках одной операции чтения FileRead(). В программе B временной интервал от наступления выполнения потока после задержки функцией WaitCommEvent() до завершения операции WriteFile() время скачет, т.е. может быть 0 мс, а может быть 30-40 мс. Из всего этого я сделал вывод, что гарантированно реализовать указанную задачу в рамках пользовательского приложения (с учетом того, что нужен запас времени) невозможно.
** Как я понял, одна из проблем это буферизация порта. Если я правильно понял из пользовательского приложения можно только рекомендовать функцией SetupComm() размеры буферов (кажется драйвера, а не порта), но отключить её нельзя. Если я правильно понял драйвер анализирует микросхему и включает буферизацию вроде как особо никого не спрашивая.
|
|
Парочка советов 26.10.04 08:57
Автор: OlegY <Oleg Yurchenko> Статус: Registered
|
1. В настройках СОМ портов отключить использование FIFO или установить размеры TX\RX в 1.
2. Для формирования задержек использовать multimedia timer: #include mmsystem.h
---
Мне кажется, что у тебя не настолько жесткие ограничения времени, что бы нужно было писать драйвер.
Кстати, по трудоемкости, гораздо проще было бы сделать примочку на однокристалке или пике для обеспечения 100% гарантии.
|
| |
Спасибо за советы. 26.10.04 09:11
Автор: Федя Статус: Незарегистрированный пользователь
|
> Кстати, по трудоемкости, гораздо проще было бы сделать
> примочку на однокристалке или пике для обеспечения 100%
> гарантии.
Спасибо за советы.
Я просто подправил стандартный драйвер,
это не сложно. Пока вроде всё работает.
Сложно понять какие могут возникнуть ньюансы.
|
|
Возможно, и без особых трудностей 13.10.04 15:06
Автор: leo <Леонид Юрьев> Статус: Elderman
Отредактировано 13.10.04 15:09 Количество правок: 1
|
Если поправить serial.sys или сделать свой драйвер, то конечно...
Но можно обойтись и без этого, только правильно используя API к серийному драйверу:
1) Во-первых важно понимать что такое системные "тики". Системный таймер в NT тикает примерно каждые 5-20 мс. Конкретное значение зависит от системы, в среднем 10 мс, на SMP немного больше 15 мс. Любые паузы (sleep-ы) и интервалы ожидания, заказанные системе, буду выполняться с точностью системных тиков. Частоту тиков можно поменять, вплоть до 1 мс (см. "Multimedia Timers" в "Platform SDK");
2) Чтобы сделать то, что вы хотите необходимо задействовать асинхронные операции ввода-вывода (см. ReadFileEx() и WriteFileEx());
3) Установите таймаут по чтению на например 1 мс (TotalReadConstantTimeout = 1). Организуйте и поддерживайте очередь из нескольких запросов на чтение по одному байту. Каждый запрос будет завершаться как только байт будет принят, но не будет ждать более "системного тика". Можно использовать другие режимы таймаутов или вовсе обойтись без них;
4) Установите по-выше приоритет для вашего процесса и треда, и все будет работать;
Переход на IRP в режиме ядра ничем не лучше. Вам придется запускать thread и вы лишь немного сэкономите на проходе системных вызовов через "ворота" между user-mode и kernel-mode;
Реализовать вашу задачу в исходниках serial.sys достаточно просто, и совсем другое дело интегрировать это с остальным кодом serial.sys. Вам придется либо попотеть над пониманием всех "заковырок" serial.sys и аккуратно "привить" вашу функциональность, либо очень аккуратно выкусить то, что делает serial.sys сейчас.
Удачи!
|
| |
Осмелюсь поправить member'а. 26.10.04 03:19
Автор: Entity Статус: Незарегистрированный пользователь
|
> Если поправить serial.sys или сделать свой драйвер, то
> конечно...
> Но можно обойтись и без этого, только правильно используя
> API к серийному драйверу:
>
> 1) Во-первых важно понимать что такое системные "тики".
> Системный таймер в NT тикает примерно каждые 5-20 мс.
> Конкретное значение зависит от системы, в среднем 10 мс, на
> SMP немного больше 15 мс. Любые паузы (sleep-ы) и интервалы
> ожидания, заказанные системе, буду выполняться с точностью
> системных тиков. Частоту тиков можно поменять, вплоть до 1
> мс (см. "Multimedia Timers" в "Platform SDK");
>
> 2) Чтобы сделать то, что вы хотите необходимо задействовать
> асинхронные операции ввода-вывода (см. ReadFileEx() и
> WriteFileEx());
>
> 3) Установите таймаут по чтению на например 1 мс
> (TotalReadConstantTimeout = 1). Организуйте и поддерживайте
> очередь из нескольких запросов на чтение по одному байту.
> Каждый запрос будет завершаться как только байт будет
> принят, но не будет ждать более "системного тика". Можно
> использовать другие режимы таймаутов или вовсе обойтись без
> них;
>
> 4) Установите по-выше приоритет для вашего процесса и
> треда, и все будет работать;
>
> Переход на IRP в режиме ядра ничем не лучше. Вам придется
> запускать thread и вы лишь немного сэкономите на проходе
> системных вызовов через "ворота" между user-mode и
> kernel-mode;
>
> Реализовать вашу задачу в исходниках serial.sys достаточно
> просто, и совсем другое дело интегрировать это с остальным
> кодом serial.sys. Вам придется либо попотеть над пониманием
> всех "заковырок" serial.sys и аккуратно "привить" вашу
> функциональность, либо очень аккуратно выкусить то, что
> делает serial.sys сейчас.
>
> Удачи!
Осмелюсь поправить member'а.
1. Приоритет процессов в данном контексте бесполезен т.к. здесь эта "сущность" недетерминистична т.к., в свою очередь, это не real-time OS.
2. Если уж Вы взялись говорить о "важности" понимании "тиков", то для честности и верности Вы должны были также сказать и о таких понятиях как "квант", "планирование", и т.д.
3. Если Вы, автор сабжа, хотите достичь стабильности в указанном временном интервале независимо от поведения ОС, категорически рекомендую Вам НЕ использовать асинхронные операции ввода-вывода.
4. Не следует быть настолько поверхностным г-н member, тем более, что Вы осмеливаетесь давать советы и тем более, что вы все-таки Member.
За сим откланиваюсь, искренне Ваш.
Пережиток прошлого.
|
| | |
Re: Осмелюсь поправить member'а. 26.10.04 12:12
Автор: leo <Леонид Юрьев> Статус: Elderman
|
> Осмелюсь поправить member'а.
>
> 1. Приоритет процессов в данном контексте бесполезен т.к.
> здесь эта "сущность" недетерминистична т.к., в свою
> очередь, это не real-time OS.
Добится "realtime" (гарантированной реакции на прерывание в течение заданного интервала времени) в Windows (и Linux) не сложно. И в Windows и Linux эффективная система приоритетов. Отличия от QNX в том, что сами прерывания и отложенное выполнение (DPC) не приоритезируются. Поэтому "realtime" нарушают только эти самые прерывания и DPC, соответственно реальное "качество" realtime зависит прежде всего от драйверов работающих в системе. Если не будет ничего особо "кривого" или специализированного, блокирующего прерывания или занимающего DCP на миллисекунды, то realtime с "качеством" до сотен микросекунд будет гарантирован.
> 2. Если уж Вы взялись говорить о "важности" понимании
> "тиков", то для честности и верности Вы должны были также
> сказать и о таких понятиях как "квант", "планирование", и
> т.д.
>
> 3. Если Вы, автор сабжа, хотите достичь стабильности в
> указанном временном интервале независимо от поведения ОС,
> категорически рекомендую Вам НЕ использовать асинхронные
> операции ввода-вывода.
>
> 4. Не следует быть настолько поверхностным г-н member, тем
> более, что Вы осмеливаетесь давать советы и тем более, что
> вы все-таки Member.
>
> За сим откланиваюсь, искренне Ваш.
> Пережиток прошлого.
Не хочу показаться грубым или неуважительным, но (в отличии от некоторых) я обычно знаю о чем говорю.
|
| | |
Member-а поправлять не зазорно 26.10.04 11:34
Автор: amirul <Serge> Статус: The Elderman
|
Если поправлять в тему
> Осмелюсь поправить member'а.
>
> 1. Приоритет процессов в данном контексте бесполезен т.к.
> здесь эта "сущность" недетерминистична т.к., в свою
> очередь, это не real-time OS.
Вы хотите сказать, что приоритет процесса ВООБЩЕ не имеет значения, если ОСь не RT? Странно, а шедулер думает иначе.
В виндах, если поток ожидает на каком либо объекте, то он будится сразу же как только этот объект переходит в "установленное" состояние. Поток получит свой квант сразу после того, как ISR-процедура завершит ReadIrp (строго говоря она только ставит DPC для текущего процессора и IRP завершается по окончании обработки прерывания). Высокий приоритет в данном случае нужен просто как страховка: чтоб успеть сделать все что нужно, не опасаясь что процессорное время передадут какому нибудь IE.
> 2. Если уж Вы взялись говорить о "важности" понимании
> "тиков", то для честности и верности Вы должны были также
> сказать и о таких понятиях как "квант", "планирование", и
> т.д.
А какое отношение имеют понятия квант, планирование и системному тику винды? Здесь не семинар по архитектуре ОС-ей. Просто было сказано, что невозможно указать задержку точнее системного тика.
> 3. Если Вы, автор сабжа, хотите достичь стабильности в
> указанном временном интервале независимо от поведения ОС,
> категорически рекомендую Вам НЕ использовать асинхронные
> операции ввода-вывода.
Для Вас наверное будет откровением узнать, что практически ВСЕ операции в винде вообще и в IO-менеджере в частности являются асинхронными. Разница между OVERLAPPED (асинхронным) и не OVERLAPPED (синхронным) режимами того же ReadFile только в месте, в котором стоит KeWaitForSingleObject. В первом случае ожидание события откладывается до явного вызова функции GetOverlappedResult(), во втором случае - ничего не откладывается и ReadFile() не возвращает управление пока IRP не завершится.
> 4. Не следует быть настолько поверхностным г-н member, тем
> более, что Вы осмеливаетесь давать советы и тем более, что
> вы все-таки Member.
Вам просто поговорить не с кем или Вы по делу пришли?
|
| | |
Чего-то там сказал типа... Это называется "пердеть клавиатурой" ;-) 26.10.04 08:09
Автор: HandleX <Александр М.> Статус: The Elderman
|
Долго думал — штрафовать, не штрафовать?
Но решил, что как-бы человек что-то все-таки имеет в голове, а не только может сотрясать воздух нажатиями на клаву.
Может, всё-таки скажет чего конструктивного? ;-)
|
|
|
подробно о проекте
Анализ криптографических сетевых...
