Доброе время суток уважаемые девелоперы.
Я новичок в написании дров. Мне необходимо написать драйвер для платы видеозахвата на чипе Conexant CX23881.
На сайте этого производителя просто так никакой доки не дают.
С чего мне посоветуете начать. В теорию то я начал вникать но тема обширная, а сроки сжатые.

Здравствуйте, driverman, Вы писали:

D>Доброе время суток уважаемые девелоперы.
D>Я новичок в написании дров. Мне необходимо написать драйвер для платы видеозахвата на чипе Conexant CX23881.
D>На сайте этого производителя просто так никакой доки не дают.
D>С чего мне посоветуете начать. В теорию то я начал вникать но тема обширная, а сроки сжатые.
--
Без описания конкретной микросхемы написать драйвер для нее не получится. Свяжитесь непосредственно с производителем, у него вполне может быть не только описание или aplications notes для этой микросхемы, но и какой-нибудь reference design kit, в составе которого уже может быть готовый драйвер.

C уважением,
Геннадий Майко.

Здравствуйте, Геннадий Майко.
Дело в том что, на сайте производителя (USA) есть несколько адресов, но не по одному из них почтовая система не хочет доставлять мои письма (мол почтовый сервер адресата сконфигурирован, чтобы reject мои письма). К тому же я вообще пока не знаю как работать с PCI. Вот и попросил совета.

Здравствуйте, driverman,

D>Дело в том что, на сайте производителя (USA) есть несколько адресов, но не по одному из них почтовая система не хочет доставлять мои письма (мол почтовый сервер адресата сконфигурирован, чтобы reject мои письма). К тому же я вообще пока не знаю как работать с PCI. Вот и попросил совета.
--
Там обычно бывают еще и телефоны, можно попытаться позвонить.

WDM PNP драйвера для PCI устройств ничем особым обычно не отличаются, поэтому в принципе можно начинать писать драйвер даже не имея пока под руками не то что описание микросхемы, но и самой платы для нее (именно так, например, мы работаем в нашей конторе). При этом используется существующее более или менее похожее PCI устройство и/или плата.
Если Вы хотите пойти таким путем, то обратите внимание на KMDF, это технология существенно упростит Вам жизнь при разработке WDM PNP драйвера from the scratch.

C уважением,
Геннадий Майко.

Здравствуйте, Геннадий Майко, Вы писали:

ГМ>Здравствуйте, driverman,

D>>Дело в том что, на сайте производителя (USA) есть несколько адресов, но не по одному из них почтовая система не хочет доставлять мои письма (мол почтовый сервер адресата сконфигурирован, чтобы reject мои письма). К тому же я вообще пока не знаю как работать с PCI. Вот и попросил совета.
ГМ>--
ГМ>Там обычно бывают еще и телефоны, можно попытаться позвонить.

ГМ>WDM PNP драйвера для PCI устройств ничем особым обычно не отличаются, поэтому в принципе можно начинать писать драйвер даже не имея пока под руками не то что описание микросхемы, но и самой платы для нее (именно так, например, мы работаем в нашей конторе). При этом используется существующее более или менее похожее PCI устройство и/или плата.
ГМ>Если Вы хотите пойти таким путем, то обратите внимание на KMDF, это технология существенно упростит Вам жизнь при разработке WDM PNP драйвера from the scratch.

ГМ>C уважением,
ГМ>Геннадий Майко.

Cпасибо за совет. Пока правда не могу качнуть столько метров. А вот что вы скажете про использование Compuware DriverStudio?
С уважением, Driverman.

Здравствуйте, driverman, Вы писали:

D>А вот что вы скажете про использование Compuware DriverStudio? С уважением, Driverman.

Я бы не стал использовать DS. IMHO — толка 0, т.е разработка не будет ни проще, ни быстрее.

Здравствуйте, TarasCo,


D>>А вот что вы скажете про использование Compuware DriverStudio? С уважением, Driverman.

TC>Я бы не стал использовать DS. IMHO — толка 0, т.е разработка не будет ни проще, ни быстрее.
--
Соглашусь с коллегой.
Я ее не использую; однако считаю, что изучать исходные коды реализации DS иногда бывает полезно.

C уважением,
Геннадий Майко.

D>>А вот что вы скажете про использование Compuware DriverStudio? С уважением, Driverman.
TC>Я бы не стал использовать DS. IMHO — толка 0, т.е разработка не будет ни проще, ни быстрее.
TarasCo, достаточно было отправить пустое сообщение — подписи\ориджина бы хватило

Скажите пожалуйста какие принципиальные отличия между драйверами под Linux и под Windows. У меня тут появились исходники драверов на мой девайс под Linux, и мне теперь нужно сотворить подобное под Винду.
И вообще проблема у меня такая:
есть плата видеозахвата на чипе CX23881 с четырьмя видеовходами, но стандартные дрова снимают сигнал только с трех.
Мне же поставлена задача получить доступ к четвертому входу и обеспечить взаимодействие со всеми 4-мя
Что мне можете посоветовать, уважаемые знатоки.

Здравствуйте, driverman, Вы писали:

D>Скажите пожалуйста какие принципиальные отличия между драйверами под Linux и под Windows. У меня тут появились исходники драверов на мой девайс под Linux, и мне теперь нужно сотворить подобное под Винду.

Драйвера под Windows и Linux абсолютно отличаются, т.е портабильность 0%. C другой стороны, написание драйвера как такового — не супер задача. Настоящие трудности могут возникнуть при написании функциоанльной части — т.е управления самим устройстом. И вот тут то исходники nix овых драйверов могут Вам очень помочь. Считайте, что интерфейс устройства Вам известен. Теперь можно приступить к разработке драйвера.

1 Шаг:
Выбрать среду для разработки. Варианта три:
— стандартный WDM ( windows driver model ) драйвер
— WDF ( windows driver framework ) драйвер
— WDM драйвер с использованием вспомогательных классов из Driver Studio NuMega.

Лично я бы выбрал путь #1, но только потому, что он для меня известен. Возможно, для новой разработки использование WDF будет оптимальным выбором. Но в этом случае, с шагами 2 и далее помочь врядли смогу

Здравствуйте, TarasCo, Вы писали:

D>>Скажите пожалуйста какие принципиальные отличия между драйверами под Linux и под Windows. У меня тут появились исходники драверов на мой девайс под Linux, и мне теперь нужно сотворить подобное под Винду.
технически, в результате работы как Linux так и Win драйвера устройство должно управляться одним и тем же, документированным в спецификациях на устройство, способом — т.е. протокол общения — последовательность записи в порты, работа с DMA, прерываниями и т.п. должна быть одной и той же грубо говоря. Здесь разницы нет, кто рулит устройством — остается правильно это сделать — сформировать вызовы. Времена DOS ушли и теперь чтобы управлять железом в составе ОС, невыйдет монопольно распоряжаться всеми ресурсами ОС как заблагорассудится.

Чтобы не нарушать работу других, нужно всего лишь встроиться в framework, каковым например является WDM-модель для Windows. WDM это интерфейс между ОС и нижним уровнем — HAL за которым уже реальные железки, фактически мы имеем таким образом framework с кучей правил и ограничений, порой очень запутанных. В линуксе вероятно свой framework для тех же целей, но тут я не владею предметом.

т.к. frameworks совершенно разные, то дальше имеем картину описанную ниже (с которой я полностью согласен)

TC>Драйвера под Windows и Linux абсолютно отличаются, т.е портабильность 0%. C другой стороны, написание драйвера как такового — не супер задача. Настоящие трудности могут возникнуть при написании функциоанльной части — т.е управления самим устройстом. И вот тут то исходники nix овых драйверов могут Вам очень помочь. Считайте, что интерфейс устройства Вам известен. Теперь можно приступить к разработке драйвера.

TC>1 Шаг:
TC>Выбрать среду для разработки. Варианта три:
TC> — стандартный WDM ( windows driver model ) драйвер
TC> — WDF ( windows driver framework ) драйвер
TC> — WDM драйвер с использованием вспомогательных классов из Driver Studio NuMega.
лишь выскажу свое мнение что не стоит новичку (а тем более профи) примешивать дополнительную сложность без серьезных и полностью осознанных на то причин. Сложности хватит и без этого.

Шаг 3 — великолепный пример такого рода излишнего в данном случае риска, т.к. он растет за счет
а) трудов программеров из NuMega с их привнесенными проблемами, багами и разного рода pitfalls, workarounds, known issues, etc
б) С++ компилятор, использование которого по-прежнему легко вызывает священные войны и споры, но что хуже гораздо более трудно отлавливаемые проблемы в редких но от того гораздо более неприятных случаях. Нужно четко представлять себе ограничения в ядре и то, во что выливается в итоге С++ в машинных кодах. Легко можно всю экономию на использовании чужих классов в этом месте потерять. Отладка может быть весьма тяжелой т.к. всегда надо ко всему прочему думать не только на себя и ОС, но и на этот доп. уровень абстракции-сложности. Это не managed код и в ядре всегда рекомендую избегать любых наворотов.
в) есть такая особенность при использовании чужих frameworks (в т.ч. это справедливо и для WDM например в глобальном смысле) — когда дизайн ложится хорошо под это дело, все кажется прекрасно и быстро. но чуть понадобилось нечто (а это случается не часто, а очень часто), что разработчики framework не предусмотрели — начинаются проблемы, которые могут даже поставить под угрозу весь проект. Ведь в этом случае уже нужен более высокий уровень разработчиков — недостаточно освоить парадигму использования чьей-то framework — фактически придется его\ее расширять и\или переписывать уже самому. NuMegu ж просить не будешь.

Да тот же MFC не всегда легко было расколупать и подлатать ибо слишком там бывало мудрено все задумано, что ж говорить про наши дела скорбные

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

TC>Лично я бы выбрал путь #1, но только потому, что он для меня известен. Возможно, для новой разработки использование WDF будет оптимальным выбором. Но в этом случае, с шагами 2 и далее помочь врядли смогу
новичка бы я отправил как раз на путь 2 ибо ему все равно что изучать, а значит лучше учить технологию которая будет завтра а не которая вчера. тем не менее для общего развития и т.п. все таки лучше быть знакомым с шагом 1, это факт.

если есть исходники unix драйвера и спецификации на устройство — технически проект переходит в разряд выполнимых и хорошо поддается управлению.

Здравствуйте, driverman, Вы писали:

D> есть плата видеозахвата на чипе CX23881 с четырьмя видеовходами, но стандартные дрова снимают сигнал только с трех.
D>Мне же поставлена задача получить доступ к четвертому входу и обеспечить взаимодействие со всеми 4-мя

А оригинальные дрова большие? Может проще будет снять ограничение?

Ну,что ж, спасибо за дельные советы, уважаемые знатоки.

Здравствуйте, driverman,

D>И вообще проблема у меня такая:
D> есть плата видеозахвата на чипе CX23881 с четырьмя видеовходами, но стандартные дрова снимают сигнал только с трех.
D>Мне же поставлена задача получить доступ к четвертому входу и обеспечить взаимодействие со всеми 4-мя
--
Обычно такие микросхемы имеют несколько разных входов видео (composite, S-video, иногда component) и один входной мультиплексор, с помощью которого выбирается один из этих входов для дальнейшей обработки. Изменения инициализации микросхемы при этом минимальны — записать другое значениие в один регистр. Правда, если тип входа другой, может и кое-какая другая инициализация измениться (например, использовать другие фильтры для composite и S-video сигнала). Все должно быть описано в документации.

Однако смущает то, что оригинальный драйвер не поддерживает все входы. Вы уверены, что этот вход вообще подключен к микросхеме?

C уважением,
Геннадий Майко.

Здравствуйте, Геннадий Майко, Вы писали:

ГМ>Однако смущает то, что оригинальный драйвер не поддерживает все входы. Вы уверены, что этот вход вообще подключен к микросхеме?
Как бы это по ламерски не звучало , но дело вот в чем:
дают мне железку ребятки, которые создают систему видеонаблюдения
дают и говорят, мол не получается у них (используя родной драйвер) получать одновременно сигналы с входов
ну и дают задание: ты мол сделай такой драйвер, чтобы все-таки использовать 4 входа вместе(как они сказали в режиме мультеплексирования) или по отдельности.
Я то осломя голову и стал вникать в совершенно неизвестную область( написание дров) к тому же нифига не смысля в видеозахвате .
И тут Ваш вопрос очень кстати
В связи с этим вопрос: А какими тулзами можно проверить поключен вход или нет.
С уважением Driverman.

Здравствуйте, driverman,

D> В связи с этим вопрос: А какими тулзами можно проверить поключен вход или нет.
--
Если известен вывод микросхемы, на который нужно подать вход видео сигнала, то с помощью осцилографа можно проверить идентичность сигнала на входе платы и на этом выводе.

C уважением,
Геннадий Майко.