Лично не пишу на низком уровне, необходимо для постановки ТЗ для разработчиков. Я и разработчики больше по разработке высокго уровня:-) Но как гласит правило управленца "ставя задачу - представляй цели, пути достижения и время" (к военным и гослужбе это не относится, много дешевых трудовых ресурсов). Поэтому, зня, что на форуме постятся спецы по разработке драйверов - просьба дать линки или мануалы, форумы.
Планируется писать для самодельных пром устройств на микроконтроллерах по 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 винды "минимально" печатать прозрачно.
В итоге есть желание формализировать работу с устройствами, что бы сервис (а реализован будет как сервис) сервера оборудования мог обращаться к устройству вне зависимости от реализации железки (точнее обеспечивать минимальный функционал, типичный для данного класса устройств).
Например, считыватель идентификаторов. Минимальный функционал (опять только пример) - получить ИД. А драйвер реализует работу уже с считывателем или безконтактных или контактных или магнитных карт/носителей.
А бизнеслогика выского уровня уже будет обращатся к сервису сервера оборудования (клиент серверная технология).
ЗЫ:мой ход мыслей и решение - не являются единственно правильным. Рад услышать другие мнения...:-)