Реализация буфера данных в USB-драйвере.

[Ochkarik]

вот такой нюанс:
написал драйвер для USB 2.0 на Cypress-е FX2 (он же CY7C68013).
написал прошивку для самого CY7C68013 (там 51 процессор стоит).
добился обещанной производительности (порядка 40Мбайт/сек) - потоковый ввод!

логика работы всего этого безобразия.
в контроллере выделяю выходное (EP-3, IN) FIFO на 1кб*3. на всякий случай ставлю интервал опроса EP 1-2мс (реально ничем не отличаются от нуля). пакеты по 1кб.
при старте контроллера заполняю ВСЕ фифо 3мя пакетами по 1кб. далее по выталкиванию одного пакета (по прерыванию). заталкиваю еще 1кб (очень быстро, только заголовок меняю).
таким образом ФИФО контроллера всегда забито как минимум двумя готовыми к отправке пакетами.

теперь драйвер:
создал кольцевую очередь IRP-URB. (размер очереди может быть от 1 до 1024). чтобы всегда были необработанные IRP-URB запросы.
каждый запрос IRP-URB может содержать от 1кбайта до 256кбайт.
по обработке каждого IRP, зарегистрирована CompleteRoutine, которая по получению завершения IRP,  заново ставит ЭТОТ ЖЕ запрос IRP-URB в очередь: то есть фактически только IoCallDriver делает. и больше ничего. реально - ничего (interlockedIncrement наверное не в счет). к полученным данным больше никто не обращается.

ну вроде все ожило, начал бороться за производительность (в плане минимальной загрузки ЦП при максимальном потоке. и вот тут начались чудеса.
1. оказалось что 128 IRP в очереди - это не есть гуд. поток льется, но даже мышь по экрану не перемещается. оставил порядка 4-8 запросов.
2. дальше начал подбирать соотношение размера одного URB и количества IRP в очереди.
 вроде имеет смысл ставить размер запроса от 16 до 128кбайт, - это меняет частоту прерываний и частоту DPC.

а теперь то, что я понять не могу (графики загрузки ЦП - время ISR и время DPC при неизменной частоте ISR/DPC):
проц CoreDuo E8600 3.3ГГЦ. 4Г памяти. Windows XP-SP3.
контролер USB вроде intel.

вот эти хитрые всплески (только на DPC) примерно каждые секунд 30. и только при включенном вводе данных по USB.
вопрос: что это может быть? и как с этим бороться)

[jur]

вот такой нюанс:
написал драйвер для USB 2.0 на Cypress-е FX2 (он же CY7C68013).
...

Уважаемый коллега!

Весьма злободневная и интересная для меня тема! К моему огромному сожалению, я ничего не могу сказать по существу. Но мне хотелось бы обратиться к тебе с большой просьбой. Пожалуйста, поделись своим опытом!

Поясню. Я уже давненько работаю с этой микросхемой. До сих пор пользовался драйвером CyUSB.sys фирмы-изготовителя Cypress. Однако, также давно у меня возникали проблемы, связанные с необходимостью организации препарирования принимаемых сырых данных в самом драйвере. Дело в том, что мой прибор (ультразвуковой сканер) принимает данные разного рода по двум USB-каналам. Я каким-то левым образом организую их селекцию в триде приема (по-моему я об этом упоминал). Это не совсем хорошо.

Вот как выглядит комплект принимаемых данных из каналов приема:

1. Данные ультразвуковых лучей, представляющих собой УЗ-картинку.
2. Ультразвуковые данные конкретного места УЗ-картинки, формирующие "ленту самописца".
3. Ультразвуковые данные блока цветного допплера.
4. Данные блока обычного допплера.

Вся эта каша поступает по двум пайпам канала USB. Мне пришлось организовать два трида для их приема и сортировки "по принадлежности".

Совершенно понятно, что делать это на стороне user-а как-то некошерно. Происходят всякие неприятные вещи, как-то: выпадение отдельных лучей, рассинхронизация данных и т.п. Приходится прибегать к различным ухищрениям, чтобы избежать дефектов картинки.

Большую часть этих проблем можно было бы устранить в случае применения своего драйвера. Ведь драйвер работает максимально близко к "железу" и обладает хорошей скоростью реакции на внешние события (приход очередной порции данных по USB).

Поэтому меня весьма заинтересовал факт, что ты написал драйвер для этой микросхемы. (Часом не на основе EzUSB?) Поделись, пожалуйста, исходниками и помощью в компиляции! Конечно, если это позволено твоей производственной политикой.

Спасибо!

[Ochkarik]

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

целиком исходники драйвера отдать - увы не могу. я его со старым проектом скрещивал, там дюже много лишнего.
я гляну, может первая тестовая версия осталась - ее наверное смогу отдать.


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

PS обидно что 3-тий USB у сайпреса в течении месяца выйдет... сэмплы и демоборды уже были доступны с лета.

PPS я еще пока полностью не пробовал наступать на грабли QoS... в плане прерываемости по USB потока "из", потоком команд "в" и задержек передачи.

Добавлено через 3 дня, 23 часа и 37 секунд:

Ткнулся я в это дело... Пока отложил... Для начала поштудирую литературу. Я потом еще обращусь, хорошо?

PS обращайтесь, не вопрос)

PPS остальное перенес в c/c++)

[jur]

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

У меня там такая каша... :-) Как это всегда бывает, началось с малого, а потом и это нужно добавить, и то...

Суть вот в чем:

Железо позволяет мне иметь два пайпа на ввод УЗ-данных.

1. Первый пайп принимает данные ультразвуковых лучей. Размер луча 512 байт, первый байт - флаговый (номер луча). Номера 0...254 - лучи картинки, 255 - спец-луч ленты самописца.

2. Второй пайп принимает данные блоков цветного и импульсного (обычного) допплеров. Цветной допплер генерирует лучи размером 4 кбайт, а импульсный - 512 байт. При этом, цветные лучи принимаются в виде восьми USB-пакетов.

Теперь, что со всем этим нужно делать.

1. Ультразвуковые лучи складываются в буфер кадра (согласно своего номера). Лучи самописца - в свой кольцевой буфер.

2. Лучи цветного допплера складываются в свой буфер кадра (тоже по номеру луча). А лучи обычного допплера - в свой кольцевой буфер.

Вся эта бодяга переваривается в DLL-ке с двумя высокоприоритетными тридами.

Для повышения надежности работы прием лучей и их предварительную сортировку я хотел бы делать в драйвере. Сложности тут никакой нет, но важна быстрая реакция на приходящие из USB пакеты. Иначе возникают дефекты картинки (если какие-то лучи выпадают).

Процесс УЗ-сканирования циклический, практически так же, как в обычном телике: набрали лучи на полный кадр - отобразили его на экране. Скорость поступления УЗ-лучей довольно высока: от 40 до 350 мксек. Допплеровские лучи идут в несколько раз медленнее, но неприятно то, что они все перемежаются друг с другом... Потому и каша получается :-)

P.S. Спасибо за перенос!

[Ochkarik]

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

[jur]

Не, с 40МБ все ОК :-) Тут немного другое.

Если принимать из USB по 1 пакету, то проблем не будет. Но! Катастрофически падает быстродействие. Я опытным путем выяснил, что начиная с 8 пакетов за раз (т.е. к драйверу я обращаюсь за порцией в 8 пакетов), скорость приема становится приемлемой при сносной загрузке процессора. (В приборе стоит довольно слабенькая материнка.)

Однако, лучи самописца (т.н. М-лучи) и лучи обычного допплера нужно принимать очень быстро, сразу по их приходу. В результате получается, что в потоке обычных лучей в произвольные моменты времени вклиниваются М-лучи, которые я замечу только после того, как вся порция из 8-и пакетов (лучей) придет ко мне из драйвера. Это вызывает подергивание ленты самописца, что довольно неприятно.

Поэтому мне хочется убить одним выстрелом сразу двух зайцев вместо одного :-) Принимать по 1 пакету, но прямо в драйвере, т.е. быстро и без потери скорости работы. А приложению отдавать уже готовый кадр или одинаковые порции М-лучей.

P.S. У нас уже немало лет все более-менее работает. Но недавно возникла необходимость добавить еще и два допплеровских сигнала. Это тоже работает, но как-то на грани...

[Ochkarik]

ну кстати с приемом по одному пакету даже в драйвере не факт что быстродействие будет сильно лучше.
цифр не помню, но я ж тоже не зря размер URB запроса увеличивал до 16к и более. если меньше ставить - число ISR/DPC пропорционально расти начинает.
там в драйвере такая же ботва - ставишь требуемый размер и ждешь...

[jur]

Не, погоди. Дело-то в том, что где-то там, в USBD.sys, из железа поступают именно отдельные пакеты. Они по одному следуют куда-то наверх, там заносятся в заданный буфер (те же 16К, к примеру) и по накоплении оного отдаются приложению.

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

Мне думается, что потери времени и производительности таятся в канале драйвер<->приложение, а не внутри драйвера. Ведь драйвер там, внизу все равно работает с каждым отдельным USB-пакетом индивидуально (т.е. запихивает его в буфер).

[Ochkarik]

так вот в том и беда... что как только я ставил одиночные пакеты - что то мне не нравилось.... что конкретно - уже не вспомню. кажется число прерываний росло на порядок и число отложенных прерываний. соответственно ресурс ЦП жрался сильно. правда я при этом максимум потока из железа пересылал.
когда они по одному следуют - прерываний идет один к одному - сколько пакетов столько прерываний и отложенных прерываний.
а когда запросы групповые - видимо там в железке оно как-то компонуется при вычитке из аппаратного буфера. и прерываний меньше. других объяснений я не нашел...
в драйвере - доступа напрямую к железке и прерываниям - нет. там механизм точно таких же запросов через usbd.sys - строишь очередь запросов, и указываешь длинну каждого. можно и один пакет длины поставить - но тогда эти грабли в производительности.
может быть тебе поможет то что из разных пайпов можно разной длины запросы делать, но тоже не факт.

PS комп вообще не любит когда частота прерываний большая... при 40кГц у меня помню лет семь назад четвертый пень(или целерон?) загибался наглухо) сейчас наверное 20кГц прерываний - процентов 20% у 3ГГц проца жрет. если не ошибаюсь (на 1394 шине)

[jur]

Весьма странно... Может быть я ошибаюсь, но работа с железом USB должна производиться по-пакетно. Иными словами, каждый пакет должен вызывать прерывание. (Как бы это посмотреть?) По этому прерыванию вызывается процедура обслуживания данного прерывания. Как пишут в книгах, реакция на аппаратное прерывание должна быть максимально быстрой и короткой, т.е. забрал пакет и тут же сбросил железный флаг прерывания. Потом, наверное, вызывается процедура обработки отложенного прерывания, которая забирает принятый пакет, кладет его в заданный буфер, сигнализирует пользователю, когда буфер заполнится и т.п.

Вот я и подумал, что если подцепиться к этому самому USBD.sys, то можно направлять поступающие пакеты не в общий сборник, а в разные процедуры отложенных прерываний. А т.к. драйвера, при вдумчивой организации дела, общаются между собой без переключения контекста, то и скорость должна быть хорошей, и загрузка процессора (сверх того, что и так есть) не должна сильно возрасти. Не так?

[Ochkarik]

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

[jur]

Пребываю в полнейшем непонимании... Неужели там, внизу, железо программируется на получение нескольких пакетов?... Ведь это более чем сложно! Могут ведь приходить отбросы пакетов, требующие повторного считывания. Как это будет переваривать железо? Ведь ему придется отслеживать число нормально принятых пакетов, повторно считывать плохие, опять-же, хорошие пакеты куда-то складывать... И только по завершению приема всей пачки вырабатывать прерывание. А ведь перед этим USBD еще должен зарезервировать соответствующий буфер для переменного числа пакетов (соответственно, переменного размера)... А если буфер большой? Как железо с этим разберется? Вот запросит пользователь 1МБ данных - как железо организует прием 2000 пакетов перед тем, как выработать прерывание?...

Да... Нескоро я все это пойму :-)

[Ochkarik]

там не совсем так...
передача все равно происходит по одному пакету. как только ПК примет один пакет - он формирует подтверждение приема для  устройства(для builk пакетов). и кстати инициатором передачи всегда является комп. даже если данные идут от устройства.
в контроллере ПК(хост) есть небольшой буфер(я совсем подробно не изучал). думаю, что что буфер не очень большой, думаю - порядка десятков-сотен кб.
а вот он уже выгребается по прерыванию программно. тонкости программирования хоста - я опять не же не изучал.
меня интересовало лишь накладные расходы на обработку этого прерывания и вообще получения данных. но факт в том, что при формировании программного запроса к USBD, указывается объем данных которые пользователь желает получить. и скорее всего реализация программно-аппаратная.
да, можно указать в качестве объема получаемых данных - один пакет, и делать очередь запросов. но при этом при общем потоке порядка 40мбайт/с значительно растут накладные расходы на обработку прерывания(ISR) и обработку отложенного прерывания(DPC). вплоть до 40-50% ресурсов ПК(а может и более, уже не помню)
поэтому я стал увеличивать длину одного запроса до тех пор, пока производительность не упала до некой "минимальной" величины. при этом длина запроса примерно составляла указанную ранее величину.

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

если интересно почитайте перевод статьи "USB in a NutShell" на русский
там относительно коротенько и по русски о работе шины с аппаратной точки зрения. в общих чертах, для ознакомления. или Агурова, но там "воды" много)

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

[jur]

Большое спасибо, коллега, за помощь и ссылку! Попытаюсь дальше поковырять что там и как...

Однако... (Здоровенная ложка, даже скорее половник, дегтя в вожделенную бочку щедрой рукой влила Микрософт, будь она неладна...) Все более серьезно встает вопрос о подписи драйвера CyUSB.sys (да и моего - тоже, если когда-нить его разработаю). Статью про подписание драйверов читал, но еще не до конца понял, как это делается. Там упоминается тестовое окружение. А будет ли таким образом подписанный драйвер работать в любом окружении? IMHO, вся эта идиотская затея Микрософта не стоит и выеденного яйца! Все равно, злоумышленник обойдет эту херню как два пальца, а честные разработчики страдают... Я понимаю, лозунг: "Бабло побеждает зло!" висит у Гейца в Красном Углу. Но нельзя же быть настолько...

Ох, сладко мечтаю о том, что бы я сотворил с Гейцем и Балмером с помощью серпа!! :-)

P.S. Мощной струей вливаюсь в обсуждение Windows Embedded CE :-) Пока использую поиск и формулирую вопросы, стараясь выделить самый главный из них :-) Тебя, коллега, Win CE 6.0 часом не привлекает? (Возможно привлекает? Ведь это напрямую относится к разделу "Встраиваемые системы".)

[Ochkarik]

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

тестовое окружение, если я правильно вас понял - имеется в виду некий режим в который можно принудительно  перевести ОС? при этом она не проверяет подписи. но это просто для удобства отладки при частой смене бинарника. это никоим образом не рабочий режим.

СЕ6.0 - нет, не входит в круг задач... быть может когда нибудь войдет что нибудь RealTime на каком нибудь DSP... но CE - вряд ли. ну еще Windows XP  Embeded может быть.. да и то вряд ли)

[jur]

на майкрософт вы зря ругаетесь) сам не подписывал, но насколько слышал - это не так страшно, как кажется)

Дык... Как же их не ругать, если они такую черню сочинили?! А что не страшно... Интернет ломится от стонов. Большинство смиряются и башляют. Однако, мне - как советскому человеку - совесть не позволяет раскошеливаться просто из-за того, что какой-то хрен с горы придумал очередное разводилово :-)

и потом... у вас всегда есть альтернатива в качестве линукса)))))

Увы, нету... Я в этом Линуксе ну совершенно не копенгаген... Как это, чтобы не было диска C:\ ?... :-)

про подписание были вопросы на этом форуме. по-моему у людей все получалось...

Искал я... Кстати, именно из вашего поста я почерпнул полезнейшую ссылку про подписание драйверов :-) Однако про опыт применения данной методики ничего не нашел...

тестовое окружение, если я правильно вас понял - имеется в виду некий режим в который можно принудительно  перевести ОС? при этом она не проверяет подписи. но это просто для удобства отладки при частой смене бинарника. это никоим образом не рабочий режим.

Да Аллах его знает, что там с этим режимом?... Поэтому и хотелось бы перенять опыт других коллег, вместо того, чтобы мучительно и долго изобретать очередной велосипед...

P.S. А Windows XP Embeded, зараза, дорогущая... С несколькими баксами Win CE не сравнить. Это при том, что 90% всей присутствующей в XP фигни нам в приборе даром не надо...

[Ochkarik]

в 32битной семерке мой драйвер работает без подписи.
 мои шаловливые ручки пока не добрались до 64 битной платформы) так что пока ничего не могу сказать)
и народ что то не отписывал - что у них в итоге получилось...

[jur]

в 32битной семерке мой драйвер работает без подписи.

Когда я пробовал свою систему на Win 7 до SP1, то у меня тоже все нормально заработало. Просто поставил драйвер CyUSB.sys  и порядок. А недавно мне снова понадобилось попробовать - и облом... Драйвер уже не устанавливается. (Я работаю исключительно с 32-битными системами.) Во гады мелкомягкие! :-)

и народ что то не отписывал - что у них в итоге получилось...

Во, во... Это даже как-то странно... Ведь наверняка эти проблемы возникают у множества коллег! Так какого ... они молчат?...

[Ochkarik]

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

[jur]

ну... подозреваю что мелкомягкие тут не при чем)

Здрасьте! А какая же тогда вражина ввела в новую Винду эту зловредную и совершенно бессмысленную процедуру запрета загрузки драйверов?! :-) (Понимаю... Проклятые марсиане... Угадал? :-)

и вообще. я люблю микрософт)  у них изумительная документация - только сейчас это начал это ценить) или я просто научился ей пользоваться))))

Я тоже не линуксоид :-) Хотя и неоднократно пытался проникнуться этой идеологией. Но у меня не получилось. Не люблю бардака и не умею вылавливать жемчужины полезной информации в широкой реке всякого хлама... Жаль, конечно, но я такой...

А научи, пожалуйста, и меня пользоваться их документацией?

[Ochkarik]

Здрасьте! А какая же тогда вражина ввела в новую Винду эту зловредную и совершенно бессмысленную процедуру запрета загрузки драйверов?! (Понимаю... Проклятые марсиане... Угадал?

А научи, пожалуйста, и меня пользоваться их документацией?

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

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

[Ochkarik]

Кстати в процессе моих ковыряний с CY7C68013 на своем драйвере удалось достичь устойчивой потоковой скорости 48 Мбайт/с. ввод через 16-битный Ep2 4*1кБ от FPGA.
49 МБайт/с - уже не успевает, но может еще на других машинах проверю)

делал через непрерывную очередь запросов URB, после завершения каждого - заново ставлю запрос в очередь. запросы не менее 8кБ. количество запросов 8 и более. на конкретных цифрах пока не остановился. еще буду экспериментировать.

[jur]

Приветствую!

Давненько мы не брали в руки шашек! :-)

Долго и упорно я сопротивлялся. Да и Cypress мне в этои помогала, выпустив подписанные драйвера под современные операционки (я про Винду). Но все хорошее когда-нибудь кончается...

По причине не реал-таймовости Винды назревает необходимость написать-таки свой драйвер. Я подумал о драйвере типа User mode driver.

Хотел спросить:

1. User mode driver позволит добиться приближения к реальному времени? Т.е. сможет ли он сразу получить управление, когда прийдет пакет из шины USB?

2. Если написать такой драйвер над стандартным драйвером ядра (от той же Cypress), нужно ли его тоже подписывать?

[Ochkarik]

1.
к сожалению не знаю архитектуру usermode-usb да и понятия "реалтайм" и "сразу" - весьма размыты)))
2. подпись вроде нужна.

The driver code signing policy starting with Windows Vista and later versions of Windows requires that the following types of drivers have digital signatures:
For 64-bit versions of Windows, all kernel mode software, including, but not limited to, kernel-mode device drivers.
For 64-bit versions of Windows, user mode drivers, such as printer drivers.
Drivers that stream protected content.

[jur]

1.к сожалению не знаю архитектуру usermode-usb да и понятия "реалтайм" и "сразу" - весьма размыты)))

"Давай поговорим об этом" (С) :-) (Ниже.)

2. подпись вроде нужна.

Я задал вопрос на форуме Кварта Технологии. Они, вроде как, круты в области embedded. Пока сказали, что "Для 32-битной операционной системы драйверы подписывать не обязательно. Будет просто предупреждение при установке драйвера." Жду дальнейших ответов. (см. P.S.)

Так вот, о драйвере. Я сначала обрисую ситуацию, как я ее понимаю.

1. Имеется системный драйвер шины USB. Он работает напрямую с железом (наверное через драйвера более низкого уровня).
2. Каждый пришедший пакет USB вызывает аппаратное прерывание (возможно я не прав). Этот пакет передается драйверу более высокого уровня, если таковой имеется.
3. Этот драйвер может что-то сделать с поступившим пакетом. Например, запомнить в буфере и выдать ивент процедуре позднейшей обработки (типа своей DPC).
4. Эта DPC запустится и выполнит с пришедшим пакетом нужные действия. Именно это меня и интересует. В этой процедуре я могу положить пришедший пакет в нужный буфер, проверить номер пакета, выдать ивент приложению, что, мол, нужная группа пакетов пришла и т.п.

Я предполагаю, что возможно в моем драйвере выполнить пункты 3 и 4. Функции п.3 получат управление немедленно (конечно, с учетом других функций этого же и более высокого приоритета). Именно этот момент я и подразумеваю под "реальным временем". Т.е. я надеюсь, что моя функция п.3 "сразу" получит управление. Конечно, я не могу надолго занимать процессор, поэтому она немедленно скопирует пакет в свой локальный буфер и запустит процедуру из п.4. Та дождется исполнения и дальше поступит с пакетом так, как ей указано.

Уважаемый коллега, пожалуйста, поправьте меня, если я что-то не так понимаю. Ведь, попросту говоря, эти самые драйверные функции, ранжированные по приоритетам, и составляют реалтаймовую часть Винды. Я не прав?

P.S. Меня, как разработчика приборов, интересует именно embedded ОС. Если в обычной десктопной операционке политика с подписью более строга, то это не будет меня смущать применительно к моему прибору. Который базируется и будет базироваться именно на встроенном варианте операционки.

[Ochkarik]

2. не каждый. по крайней мере у меня на поток 48Мб - было 2700 прерываний/сек сто при максимальном размере пакета в 1кб по шине - не сходится. так что там тоже какое то фифо стоит в контроллере ПК
3. ваш драйвер аппаратные прерывания USB не получит - в любом случае это будут лишь отголоски DPC. но это будет довольно шустро и кажется даже на DISPATCH_LEVEL. точно не знаю но думаю что CompletionRoutine от IOCTL_INTERNAL_USB_SUBMIT_URB  скорее всего и вызывается из DPC.

теперь поправляю) у винды нет и никогда не было реалтаймовской части! у нее практически везде - очереди и приоритеты. и при этом она не обещает и не гарантирует что очередь дойдет и завершится за заданное число тактов.
и даже DPC все равно выполняются по очереди.


Добавлено через 1 минуту и 32 секунды:
embedded ОС - ничего не могу сказать. 32 бита да - без подписи.
сертификат для подписи стоит что то порядка 100-200$/год.

[jur]

Сегодня наконец-то получил ответ от спеца из Кварта Технологии. Вариант POSReady новой линейки операционок от Микрософт есть. Называется Windows Embedded 8.1 Industry. Это неплохо.

Про реалтаймовость все-равно не понимаю... Ведь если системные драйвера реагируют на аппаратные прерывания, причем достаточно быстро, так это и можно считать очень близким приближением к реалтаймовости. Нет? Конечно, не как в CE с ее 5 микросекундами, но все-же. Например, надстройка RTX позволяет оперировать временем реакции на прерывание порядка 5-10 микросекунд.

Но я думаю, что параметров RTX мне не нужно. Возможно DPC на уровне DISPATCH_LEVEL меня вполне устроит.

(У меня сейчас в голове каша неимоверная! :-))

Буду думать дальше...

P.S. Тут давеча (в прошлом году вроде) Cypress выложила исходники своего драйвера и CyAPI. Молодцы ребята! Они пишут, что нужна версия Windows Driver Kit Version 7.1.0 (BASEDIR=C:\WINDDK\7600.16385.0). Я ее скачал, но еще не попробовал. Пока раскачиваюсь...

[Ochkarik]

RTX системный таймер позволяет перепрограммировать,  на нескольких порядков вниз.
я просто призываю осторожно обращаться со словом "реалтайм") драйвера "реагируют" и "достаточно быстро" это не линейка и не весы) и может различаться в зависимости от чужих железок и дрйверов.
  надо смотреть и набирать статистику на конкретном железе.
кашу - лечить соломоном-руссиновичем на ночь, последовательно, все, два раза)
PS драйвер? пропустил... ща посмотрим)) спасибо!