На самом деле, для несъемных устройств толком ничего не поменялось. Я писал кое что для NT4.0 - конкретно, делал драйвер, который прикидывался Altera ByteBlaster, но работал через совсем другой JTAG. API было в общем, все то же, просто добавился геморрой по обслуживанию PnP-запросов. А вот для съемных устройств, например USB, да, пришла манна небесная Куда потом WDF подлил немного дегтя... Да даже не подлил... Ведь и без него живется хорошо (я хорошо знаю WDM, и смотрел на WDF - ну ничего там нету полезного вообще!). Но кто-то зачем-то его сделал, скорее всего, как Вы заметили, вопросы маркетинга, убить старые ОС, заставить пересесть на новые, и заапгрейдить и купить железо, чтобы это так же быстро заработало, как и раньше.

Они обещают более простой интерфейс в WDF. Может, и не врут? Надо попробовать.

Мне кажется, тут ситуация как Python-ом и Си. Если я знаю Си, мне не надо изучать Пайтон , если всё то же я могу сделать более быстрым и за меньшее время на Си. Однако, тому, кто в первый раз слышит фразу "язык программирования", очевидно, работать с Пайтоном будет намного приятнее. И не думаю, что здесь стоит искать никакого другого заговора, кроме как нацеленного на снижение порога входа. А скорость работы и размеры, это плата за плюшки.

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

В общем, эти мысли -- результат моего чтения выходного дня пропагандистской литературы от M$ :)

IMHO, попробовать, конечно, можно, но после того, как будете докой в WDM вообще, и в API ядра, в частности, чтобы понимать, что, где, как, и почему.

Потому, что драйвер, и вообще, ядро, это не то место, где можно разбрасываться ресурсами налево-направо.

PS
А что такое user mode driver, я к сожалению вообще не в курсе... И зачем они нужны.

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

Даже если это и так, то доступ к I/O должен быть через средства виртуализации, не говоря уже о тормознутости реакции на прерывание с переключением контекста в пользовательский режим. Поэтому, я не думаю, что в юзер моде можно реализовать сколько нибудь эффективный драйвер. Как я предполагаю (но, не знаю), это, видимо, только для какого-то очень ограниченного списка подвидов драйверов годится.

А запускать драйвер на той же системе, где он и компилируется, так это всегда без проблем. Кстати, для такой отладки есть жутко удобная утилитка - http://technet.microsoft.com/en-us/sysinte...s/bb896647.aspx

Вообще UMDF ругают. Мол, первая версия убога, а последняя только для 8.1 годится и то не для всех целей. А так KMDF для всего.




Хм, интересная утилитка

И весьма полезная!
С вашего позволения, господа, добавлю свои пять копеек. Во-первых, полностью солидарен с многоуважаемым SM: пользуйтесь WDK или хотя бы попытайтесь. У меня весьма скромный опыт работы с DDK (ныне WDK) - создавал простой драйвер для работы с USB-устройством в режиме Bulk, но впечатлений осталось на всю жизнь. Как Вам предложили ранее, возьмите примеры Microsoft, которые наличиствуют в установленном пакете WDK. Я брал bulkusb, убрал сначала все лишнее, а потом добавил нужное.

Функции драйвера, в том числе и процедуры передачи данных, реализуются посредством так называемых IOCTL-кодов. Обращение к драйверу осуществляется при помощи всего одной функции - DeviceIoControl(), входящей в API Windows, куда засылается IOCTL-код, однозначно определяющий какую процедуру драйверу нужно вызвать и как интерпретировать другие параметры, передаваемые в DeviceIoControl().
Почему-то мне думается, что с программированием PCIe ситуация аналогичная. В любом случае, "вьезжать" в WDK стоит времени и сил, которые на это потребуются (WDF никогда не пользовал).

В качестве документации я пользовался только MSDN, ибо там наличиствует вся необходимая информация. Только в моем случае это была локальная копия именуемая "MSDN 2000" (или 2002, не помню), которая тогда шла на трёх CD, ей было удобнее пользоваться, чем он-лайн версией. Возможно, сейчас существует обновленный вариант.

Эта часть MSDN локально идет внутри WDK - в меню "Пуск": Windows Driver Kits -> WDK 7600.16385.1 -> Help -> WDK Documentation

Тем лучше, на мой взгляд. Он-лайн у меня всегда медленно работает. Эх, надо бы какую-нибудь задачу придумать, чтоб с WDK попрактиковаться.

Менее, чем наполовину. Отличие от USB кардинальное - если для USB все делает драйвер, которые под Вашим в стеке, то с PCI/PCIe все делаешь сам - сначала, в обработчике IRP_MJ_PNP/IRP_MN_START_DEVICE, драйвер получает информацию о ресурсах устройства (физические адреса его регионов I/O портов, памяти, и прерывание), а затем работает непосредственно с портами устройства при помощи всяких там WRITE_PORT_UCHAR и иже с ними, а также может производить DMA-операции (режим PCI BusMaster), когда устройство само передает данные в память компьютера - для этого производится блокирование страниц памяти, получение физических адресов этих страниц на шине PCI (PCIe), передача этих адресов в устройство и запуск передачи. Всего этого в USB нету.
То есть, USB, это совсем просто. А PCI, особенно мастер, это уже следующий уровень.

Я только рад, что к теме присоединяются новые люди . Спасибо за ваши пять копеек.
Теперь 2:0 в пользу WDM.



Что характерно, WDK 8.1 устанавливается уже без офлайновой справки (или же я не нашел её). А у 7600 всё на месте, чудеса.

Я тоже столкнулся с проблемой создания своего драйвера под PCIe.
Делал опираясь на toaster (WinDDK\7600.16385.1\src\general\toaster\wdm\func\).
В нем даже херить ничего не пришлось. Правда в нем нет обращений к реальному железу. Но это можно стянуть с упомянутого SM драйвера UART.

Здравствуйте.
Так же столкнулся с задачей реализации PCI Express на плате Xilinx.
Как понимаю вы так же запускали пример контроллера памяти на основе Integrated Block for PCI Express. Разбирались ли вы что там к чему? Уже какой день не могу понять как и что в нем работает...
Как я понимаю на сам ip возлагается задача инициализации в системе, фильтрация запросов (пропускает только то, что относится к нашей плате, и не пропускает то, что относиться к другим устройствам подключеным по PCIe), а так же преобразование в пользовательский AXI-интерфейс. Так ли это?
Просто я запустил тестбенч от этого примера и вижу следующую картину:
1) сперва появляются данные на дифпарах pci_exp_rx и pci_exp_tx. На AXI - тишина. Предполагаю что в этот момент как раз и идет инициализация платы.
2) затем появляются данные на axis_rx_tdata, такого вида:

но при этом сигнал валидности axis_rx_tvalid в нуле.
3) вместе с данными появляется сигнал валидности:


Вот и не могу понять что за данные передаются без сигнала валидности, что за данные [15:0] во-втором DW и что за данные в третьем DW на axis_tx_tdata...
Если разбирать по полям правильно ли я понимаю на примере:
01a0_0a0f_0000_0001
de03_7320_0000_0010

01a0 - Requester ID
0a - Tag
0f - BE
0000_0001 - атрибуты и порядковый номер
de03_7320 - данные
0000_0010 - адрес
?

Попробовали ли вы действовать по этому сценарию? Получилось ли что то?

Добрый вечер, добро пожаловать в наше уютное обсуждение:)

Во-первых, да, именно этот проект я и зашил.

Сперва я запустил тестовый драйвер от виндрайвера, убедился, что устройство определяется в системе, что в память можно записывать и считывать. То есть, работающая болванка есть. На этом этапе я решил отложить часть ПЛИС и заняться драйвером.

Как можно заметить по другим моим топикам на этом форуме, я пошел против системы и SM-а :) и соблазнился на рекламируемые прелести WDF. На данный момент это закончилось тем, что отладчик подключается к рабочему компьютеру только когда моё устройство не подключено, что странно и бесполезно. На этой ноте я отчаялся и решил посмотреть и вовсе в сторону Виндрайвера и разобраться в том, что же такого удобного и классного у них есть.

Судя по описанию API действительно, всё радужно и хорошо. Тем более, что пример собирается и работает, а код его не выглядит пугающе. Как я понимаю работу дальше, необходимо научиться создавать на плате прерывания и тут мы погружаемся в пучину корки.

Тестбенч, о котором вы говорите, как-то не попадался мне на глаза, так что ничего прокомментировать не могу. Пока с трудом понимаю, как можно использовать готовый пример для создания собственного проекта. Однако обрабатывать и генерить все сигналы вручную представляется ещё большим мраком и я немного в растерянности. Еще хотелось бы отойти от AXI, а то разбираться ещё и в нём надо.

Вообще, мне достаточно научиться выкидывать прерывания, по которым драйвер читал бы определенную область памяти и всё. А переход от PIO к DMA, видимо, возможен не скоро, так как вообще не понимаю, как сейчас его реализовать.

Если вернетесь на рельсы WDM - то смогу объяснить все пошагово, как и что. Так как у меня реализованы и прерывания, и бусмастер.