Пытаюсь написать универсальные "дрова" для USB сканера ШК.
Универсальные в том смысле что под Lin/Win и с учётом разновидности протоколов самих ШК (USB-COM / KB)
Всё что перерыл - работает в основном на тредах, и даже не "подозревает" о аппаратных прерываниях
Было уже обрадовался увидев в LibUSB вызов

    libusb_fill_interrupt_transfer ( irq_transfer, devh, EP_INTR, irqbuf, sizeof(irqbuf), cb_irq, NULL, 0 );

но как оказалось её реализация организует свой "внутренний" тред для раздачи event-ов и опроса устр-в ...
... поэтому call-back - чная ф-ция у меня не вызывалась.

На обслуживание (и перехват) USB прерываний у гугля почему-то затык, или я его неправильно спрашивалЪ ...

Что нужно ? В пространстве пользователя ( т е в ПО ) "сесть" на НУЖНОЕ прерывание и формировать
сигналы с принятым и расшифрованным кодом ШК из call-back - чной ф-ции. (как в DOS-e для COM-Port )
Расшифровывать ШК нужно т к разные сканеры по разному его формируют ...

Кто в курсе, подскажите куда копать ?! Буду премного благодарен за ссылки и примеры.

у тебя в принципе неправильное понимание работы современных осей. ни одна ось не даст тебе из юзерспейса "сесть на прерывание". максимум ты можешь подписаться на события от драйвера и получать уведомления о том, что произошли какие-то события.
для унификации работы с USB в Linux есть lubusb, которая как раз собирает воедино все разные интерфейсы железа и предоставляет общий интерфейс для ПО. в венде есть какой-то WinUSB, но он весьма ограничен, насколько мне известно. и под венду вроде можно собрать libusb.

я использовал в винде libusb, именно в отдельном потоке. Нормальная штука, работает чётко, в отличие от зависающего майкрочиповского драйвера

Для потока и LibUSB у меня тоже реализовано, но некузяво это, при наличии аппаратного IRQ.
В том-то и вопрос, как выцарапать это IRQ у системы ?!
Где и как сказать драйверу что-бы он отдал конкретный EVENT моей Call-Back-чной ф-ции ?
Пишу под ARM на Linux (RPi-2) ...

JohnZ, не задумывался об этом, меня устраивает поток на 100%

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


я тебе ещё раз говорю: почитай хотя бы основы про систему, под которую ты собрался что-то писать.
последний раз, когда прерывания были доступны юзеру - это времена MS-DOS. с тех пор системы стали сложнее и драйвер в принципе не обязан ничего предоставлять юзеру. конечно, ты можешь написать свой драйвер, но это довольно сложная задача и главное, что это в принципе не нужно. потому что драйвер как раз предоставляет интерфейсы для libusb и всяких там HID интерфейсов и юзерский софт пользуется стандартизированными интерфейсами библиотек, а не затачивается под разные драйвера. на самом деле, с драйверами всё несколько сложнее, их там несколько уровней и они передают между собой сообщения. но то, о чём ты говоришь, доступно только драйверам самого низкого уровня и они точно ничего о прерываниях юзеру не сообщают. это загрузило бы ядро системы ненужными коллбеками вплоть до полного зависания.

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

я, честно говоря, не видела USB-шных девайсов на майкрочипе. чаще всего там FTDI ставят. дёшево и сердито.

Iron Bug, исторически так сложилось в одной старой железяке - вынуждены тянуть. На win 8 и 10 драйвер перестал работать, а libusb работает

А по поводу FTDI - тоже используем. Он непредсказуемо затыкается на win7 и младше, на 8 и 10 вроде стабильно работает

делал тест на win7 - гоню из прибора поток данных без остановки, принимаю в программу через стандартный COM порт. Самого непроизвольного затыкания можно ждать сутками, но спровоцировать легко - перетыкаешь разъём туда-сюда. В какой-то момент данные перестают приходить, хотя никаких ошибок из функций ком-порта не выскакивает. Лечится перезапуском программы, больше я способа не смог найти. Простое переоткрытие порта при этом не помогает, ошибок при этом тоже никаких не выскакивает

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