Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| |
Спасибо за инфу про DDK, буду изучать... 10.08.06 12:56 Число просмотров: 2385
Автор: Garick <Yuriy> Статус: Elderman
|
> Вообще драйвера работают в ТОМ ЖЕ кольце, что и ядро.
> Однако я не представляю, как собственный драйвер может
> помочь в твоем случае. У последовательного порта есть
> собственный драйвер (serial.sys), у USB их целая пачка, что
> такое CAN я не знаю. Эти драйвера собственно и
> предназначены для того, чтобы преобразовать твои Read/Write
> запросы в последовательность обращений по портам
> ввода/вывода. Делают они это достаточно хорошо, чтобы мысль
> о самостоятельном обращении к портам UART-а/UHCI была
> достаточно бредовой.
Мне необходимо обращатся к устройствам "висящим" на шинах
в 232 ром одно устройство на шину, но может быть неск шин, что стандартно для промустройств.
485 неск устройств на шину. КАН - аналог 485, но встроенным арбитражем шины.
USB - также неск устройств и арбитраж есть.
По аналогии с принтером - есть драйвер (настраиваемый в ручную или автонастраиваемый) работающий через драйвер порта (посл или парал). И API винды "минимально" печатать прозрачно.
В итоге есть желание формализировать работу с устройствами, что бы сервис (а реализован будет как сервис) сервера оборудования мог обращаться к устройству вне зависимости от реализации железки (точнее обеспечивать минимальный функционал, типичный для данного класса устройств).
Например, считыватель идентификаторов. Минимальный функционал (опять только пример) - получить ИД. А драйвер реализует работу уже с считывателем или безконтактных или контактных или магнитных карт/носителей.
А бизнеслогика выского уровня уже будет обращатся к сервису сервера оборудования (клиент серверная технология).
ЗЫ:мой ход мыслей и решение - не являются единственно правильным. Рад услышать другие мнения...:-)
|
|
<hardware>
|
Нужна инфа по написанию драйверов 09.08.06 18:11
Автор: Garick <Yuriy> Статус: Elderman
|
Лично не пишу на низком уровне, необходимо для постановки ТЗ для разработчиков. Я и разработчики больше по разработке высокго уровня:-) Но как гласит правило управленца "ставя задачу - представляй цели, пути достижения и время" (к военным и гослужбе это не относится, много дешевых трудовых ресурсов). Поэтому, зня, что на форуме постятся спецы по разработке драйверов - просьба дать линки или мануалы, форумы.
Планируется писать для самодельных пром устройств на микроконтроллерах по rs 232/485, USB и, может, CAN.
Сейчас поддержка железа реализована с помошью сервиса ВЫНЬ НТ 5.х. те читать/писать в девайс умеем, но только синхронно (и бывают потери).
А драйвера, я так понял работают на более ближнем к ядру кольце и их реализация критична к устойчивости системы.
PS^ сейчас из драйверов знаю - их надо устанавливать и иногда настраивать:-)
|
|
Собственно в самом DDK достаточно полные хэлпы 09.08.06 23:13
Автор: amirul <Serge> Статус: The Elderman
|
> ресурсов). Поэтому, зня, что на форуме постятся спецы по
> разработке драйверов - просьба дать линки или мануалы,
> форумы.
А без DDK драйвер не напишешь. Кроме того, все последние MSDN Library, которые мне попадались (в основном на 3-х компактах) содержат в себе весь DDK Help.
> Планируется писать для самодельных пром устройств на
> микроконтроллерах по rs 232/485, USB и, может, CAN.
> Сейчас поддержка железа реализована с помошью сервиса ВЫНЬ
> НТ 5.х. те читать/писать в девайс умеем, но только
> синхронно (и бывают потери).
> А драйвера, я так понял работают на более ближнем к ядру
> кольце и их реализация критична к устойчивости системы.
Вообще драйвера работают в ТОМ ЖЕ кольце, что и ядро. Однако я не представляю, как собственный драйвер может помочь в твоем случае. У последовательного порта есть собственный драйвер (serial.sys), у USB их целая пачка, что такое CAN я не знаю. Эти драйвера собственно и предназначены для того, чтобы преобразовать твои Read/Write запросы в последовательность обращений по портам ввода/вывода. Делают они это достаточно хорошо, чтобы мысль о самостоятельном обращении к портам UART-а/UHCI была достаточно бредовой.
> PS^ сейчас из драйверов знаю - их надо устанавливать и
> иногда настраивать:-)
|
| |
Спасибо за инфу про DDK, буду изучать... 10.08.06 12:56
Автор: Garick <Yuriy> Статус: Elderman
|
> Вообще драйвера работают в ТОМ ЖЕ кольце, что и ядро.
> Однако я не представляю, как собственный драйвер может
> помочь в твоем случае. У последовательного порта есть
> собственный драйвер (serial.sys), у USB их целая пачка, что
> такое CAN я не знаю. Эти драйвера собственно и
> предназначены для того, чтобы преобразовать твои Read/Write
> запросы в последовательность обращений по портам
> ввода/вывода. Делают они это достаточно хорошо, чтобы мысль
> о самостоятельном обращении к портам UART-а/UHCI была
> достаточно бредовой.
Мне необходимо обращатся к устройствам "висящим" на шинах
в 232 ром одно устройство на шину, но может быть неск шин, что стандартно для промустройств.
485 неск устройств на шину. КАН - аналог 485, но встроенным арбитражем шины.
USB - также неск устройств и арбитраж есть.
По аналогии с принтером - есть драйвер (настраиваемый в ручную или автонастраиваемый) работающий через драйвер порта (посл или парал). И API винды "минимально" печатать прозрачно.
В итоге есть желание формализировать работу с устройствами, что бы сервис (а реализован будет как сервис) сервера оборудования мог обращаться к устройству вне зависимости от реализации железки (точнее обеспечивать минимальный функционал, типичный для данного класса устройств).
Например, считыватель идентификаторов. Минимальный функционал (опять только пример) - получить ИД. А драйвер реализует работу уже с считывателем или безконтактных или контактных или магнитных карт/носителей.
А бизнеслогика выского уровня уже будет обращатся к сервису сервера оборудования (клиент серверная технология).
ЗЫ:мой ход мыслей и решение - не являются единственно правильным. Рад услышать другие мнения...:-)
|
|
|
подробно о проекте
Анализ криптографических сетевых...
