информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыВсе любят медАтака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Ростелеком заподозрили в попытке... 
 Линуксовый ботнет, распространяющийся... 
 Конец поддержки Internet Explorer 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / hardware
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Спасибо за инфу про DDK, буду изучать... 10.08.06 12:56  Число просмотров: 2271
Автор: Garick <Yuriy> Статус: Elderman
<"чистая" ссылка>
> Вообще драйвера работают в ТОМ ЖЕ кольце, что и ядро.
> Однако я не представляю, как собственный драйвер может
> помочь в твоем случае. У последовательного порта есть
> собственный драйвер (serial.sys), у USB их целая пачка, что
> такое CAN я не знаю. Эти драйвера собственно и
> предназначены для того, чтобы преобразовать твои Read/Write
> запросы в последовательность обращений по портам
> ввода/вывода. Делают они это достаточно хорошо, чтобы мысль
> о самостоятельном обращении к портам UART-а/UHCI была
> достаточно бредовой.

Мне необходимо обращатся к устройствам "висящим" на шинах
в 232 ром одно устройство на шину, но может быть неск шин, что стандартно для промустройств.
485 неск устройств на шину. КАН - аналог 485, но встроенным арбитражем шины.
USB - также неск устройств и арбитраж есть.

По аналогии с принтером - есть драйвер (настраиваемый в ручную или автонастраиваемый) работающий через драйвер порта (посл или парал). И API винды "минимально" печатать прозрачно.

В итоге есть желание формализировать работу с устройствами, что бы сервис (а реализован будет как сервис) сервера оборудования мог обращаться к устройству вне зависимости от реализации железки (точнее обеспечивать минимальный функционал, типичный для данного класса устройств).
Например, считыватель идентификаторов. Минимальный функционал (опять только пример) - получить ИД. А драйвер реализует работу уже с считывателем или безконтактных или контактных или магнитных карт/носителей.

А бизнеслогика выского уровня уже будет обращатся к сервису сервера оборудования (клиент серверная технология).

ЗЫ:мой ход мыслей и решение - не являются единственно правильным. Рад услышать другие мнения...:-)
<hardware> Поиск 






Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach