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

Я пишу с помощью DriverStudio 3.1. Как реализовать стек драйверов для случая, когда устройство на COM порту. Какие функции надо дописать, какие пункты в DriverWizard выбрать.

Неужели никто незнает?

Неужели совсем никто незнает?

А че такое DriverStudio 3.1 и зачем с его помощью писать дрова для COM порта? Под что вообще драйвера пишешь, если не секрет? Может чего и присоветую...

Вроде с COM портом можно и без дров работать.

UncoNNecteD
смотря чем, может человек собственную мышь конструирует.

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

Но сперва надо сделать с COM интерфейсом.

ArtSh
Может стоит пересмотреть протокол для избежания критичных ко времени моментов и тогда можно обойтись без драйвера?
кстати есть спец микрухи usb-rs232, которые позволяют видеть usb устройство как подключенное по виртуальному com порту

WiseAlex
Это неудачное решение. Во первых оно стоит денег, а во вторых, если в тех задании сказано LPT, USB, СОМ, то никаких переходников не поставишь.

ArtSh

Цитата:

Во первых оно стоит денег

микросхема не так уж и дорога - 5$ и может встраиваться в сам прибор -- на выходе стандартный usb
кроме того поддержка всех интерфейсов удорожит прибор значительно, а так будет два com и usb причем реализованы они будут почти одинаково - как на аппаратном так и на программном уровне

Цитата:

Это неудачное решение.

Прибор уже есть или разрабатывается?
Протокол определен или можно менять?
Еще раз

Цитата:

Может стоит пересмотреть протокол для избежания критичных ко времени моментов и тогда можно обойтись без драйвера?

WiseAlex

Цитата:

микросхема не так уж и дорога - 5$

это 5 процессоров ( на один прибор нужно 4)


Цитата:

выходе стандартный usb

тех задание говорит именно о физической среде перадачи.
Приведу пример. При последовательном интерфейсе тяжело делать точные большие по времени выдержки (связано с протоколом устройства, и методами анализа). Ктому же наводятся большие помехи при работе с дугой.


Цитата:

Может стоит пересмотреть протокол для избежания критичных ко времени моментов и тогда можно обойтись без драйвера?

к сожалению нет. в этом вся соль прибора.

ArtSh

Цитата:

это 5 процессоров ( на один прибор нужно 4)

можно более подробно?
как я понял процессоры общаются по своей шине, а для общения с ПК нужен один интерфейс в трех вариантах (т.е. на каждом приборе будет установлен и usb и com и lpt)
в любом случае нужен переходник внутренний интерфейс - интерфейс для ПК и по-видимому 3 штуки

Цитата:

При последовательном интерфейсе тяжело делать точные большие по времени выдержки (связано с протоколом устройства, и методами анализа). Ктому же наводятся большие помехи при работе с дугой.

а как же com да и usb последовательный интерфейс.
что-то я совершенно запутался если можно попытайтесь описать все как можно более подробно, включая интефейс общения процессоров в устройстве и все что, сочтете важным

ArtSh
Пока не очень понятно, зачем может понадобиться драйвер?
Чего ты собираешься в этом драйвере делать такого, чего нельзя сделать в приложении c помощью CreateFile("COMn"...), ReadFile, WriteFile, WaitCommEvent и прочих communication функций?

Вы ведь будете поставлять с прибором прогу для управления прибором и отображения / анализа данных, полученных с него?

Или же ты хочешь реализовать в драйвере обработку данных, получаемых с прибора, с тем, чтобы любая прога могла запросить такую обработку, обратившись к драйверу? Но ведь для этого достаточно сделать DLL с набором функций обработки.

Вобщем, поддерживаю WiseAlex, побольше подробностей не помешало бы.

Цитата:

можно более подробно?

Прибор модульный - всего 3 модуля и шлюз между внутренней шиной (CAN) и внешней.
Предполагается что интерфейс прибора может поменятся в процессе эксплуатации, как и программа реализующая интерфейс с пользователем, а драйвер менятся будет редко.

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

ArtSh
Наши железяки тоже на CAN - смастерили USB-CAN конвертер и прекрасно обошлись обычными функциями чтения/записи в виртуальный com порт, а для универсальности сделали систему клиент-сервер по tcp/ip, (сервер общается с устройством, а клиент занимается интерфейсом с пользователем) все работает отлично даже с высокими скоростями на CAN, правда такой режим достаточно требователен к ПК - на 300селероне загрузка большая

ArtSh
Имхо:
Продумать функции интерфейса в библиотеке (dll). Т.е. выделить набор функций высокого уровня для работы с устройством (что-то вроде SetData(), Set..., ReadData, Read....
Библиотеку грузить динамически и под каждый физический интерфейс писать отдельную библиотеку доступа.
Таким образом приложение отвяжется от физического интерфейса - поменялся интерфейс - поменяли Dll (доустановили драйвера если нужно) и все работает.
Для COM не придется заморачиваться с драйвером. И физические интерфейсы расширяй сколько хочешь.

vndovr
Заморачиваться с подменой библиотек и контролем версий не хочется, с драйвером в этом смысле гораздо проще.

WiseAlex

Цитата:

систему клиент-сервер по tcp/ip

Цитата:

такой режим достаточно требователен к ПК

смотри выше про работу в реальном времени.


И вообще, интерфейс уже сделан, платы спаяны, так что поздо обсуждать плюсы и минусы такого решения, а по теме я не слышал еще ни одного ответа.

ArtSh

Цитата:

И вообще, интерфейс уже сделан, платы спаяны

все так работают - и мы то же (сначала делаем потом думаем о наших возможностях в плане софта)
кроме того CAN обычно используют на мегабод - как вы собираетесь по com это передавать

Цитата:

а по теме я не слышал еще ни одного ответа.

да потому что driverstudio это экзотика.
Обычно для таких устройств пишут под 2000 и выше sys файлы с помощью ddk и VisualC, впрочем я сам этого не писал, так что ничего полезного посоветовать не могу.
Зайди на rsdn, может там что-то подскажут. Думаю что есть свой форум конкретно по DriverStudio (вероятно англоязычный) - попробуй поискать
Удачи

ArtSh

Цитата:

Заморачиваться с подменой библиотек и контролем версий не хочется, с драйвером в этом смысле гораздо проще.

Хех... если проще то с чего у тебя вопросы возникли? Тем более что ни с COM ни с USB (если HID) с драйверами не нужно заморачиваться вообще.

Но дело твое конечно

vndovr
проще в смыле котроля версий, а с созданием полноценного стека драйверов мне пока не приходилось встречаться.

WiseAlex
спасибо за совет. А насчет мегабода, мы раскачали LPT порт на 1.5 Мб/с , а с COM интерфейсом эти потоки данных будут циркулировать внутри прибора, а на выход будут поставляться только конечные данные.

Почитал я и не понял: зачем именно драйвер? Почему нельзя обойтись пользовательским уровнем? Еще я не понял под какую ОС все это планируется писать?

Rustam_Koviazin

Если речь о Win32 то для работы с LPT или USB-устройствами понадобятся драйвера. С COM-устройством можно работать при помощи Win32 API, если устроит производительность.

odl455
В принципе, через функции ReadFile, DeviceIoControl и прочая, можно работать и с LPT. Правда - хреново получится.

ИМХО, надо писать драйверы двух уровней: нижние будут ложиться поверх драйверов COM, LPT или в качестве устройства USB, и выдавать некий внутренний протокол - один на всех.
Второй драйвер будет вешаться поверх любого из трех или всех в любом наборе и, пользуясь согласованным протоколом, абстрагировать нижний уровень от приложений.

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

Как с клавиатурами: есть драйверы разных типов клавиатур, а сверху на них вешается драйвер класса "Клавиатура"...

odl455
Для USB не всегда нужен драйвер - для HID-устройств в Win уже есть драйвер с которым можно работать через API.

odl455
Я под драйвером физического интерфейса (COM, LPT и т.п.) понимаю то, что выполняется на уровне ядра, а не пользовательское приложение, способное выдавать/принимать некий протокол по этому физическому интерфейсу. Вот о чем у меня вопрос.

Rustam_Koviazin


Цитата:

под какую ОС

driverstudio предпологает Win.
А вопрос в том, как настроить стек драйверов для такого случая.
и вопрос второго порядка, как нстроить все это для нескольких объектов устройств в одном драйвере.

ArtSh

Цитата:

driverstudio предпологает Win.

Это слишком расплывчато. Драйвера под win95 - это совсем не драйвера для winxp.


Цитата:

А вопрос в том, как настроить стек драйверов для такого случая.

А в чем проблема? Видел как выглядит tcp/ip? Ну сделай по подобию (не до самого верха, конечно). Будет у тебя несколько уровней: канальный, сетевой. Обычно в для контроллеров выше сетевого угровня уже не требуется. Посмотри, например, реализацию opentcp. Там, конечно, не последовательный канал, но там стек tcp/ip в исходниках.


Цитата:

и вопрос второго порядка, как нстроить все это для нескольких объектов устройств в одном драйвере.

честно говоря из описания:


Цитата:

Прибор модульный - всего 3 модуля и шлюз между внутренней шиной (CAN) и внешней.
Предполагается что интерфейс прибора может поменятся в процессе эксплуатации, как и программа реализующая интерфейс с пользователем, а драйвер менятся будет редко.

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

я не понял в чем роль ПК и кто с ним будет связываться по последовательному каналу.

Rustam_Koviazin
WDM модель.
Примера написанного с помощью driverstudio я к сожалению не нашел.
Роль ПК в том чтобы найти прибор, настроить его, получить данные и обработать их.

ArtSh
И почему работу с последовательным каналом нельзя сделать на прикладном уровне? CreateFile, ReadFile, WriteFile и коммуникационные ф-ции.

Rustam_Koviazin
Смотри выше.