Работаю над собственным драйвером для USB в STM32 , что-то мало материала. 99 % как скомпилировать готовый пример. Кто занимался аналогичной задачей? В принципе значительная часть уже сделана.

Вообще дурацкое это слово — "драйвер". Я только драйверы шаговых двигателей могу вспомнить. Где еще в природе это слово употребляется? На компе с железяками работают модули ядра (если их сразу в ядро не вмонолитили). На железяках крутятся прошивки. Где драйвера-то?

Эдди, вы когда-нибудь ставили Виндовс на голый комп?
https://ru.m.wikipedia.org/wiki/Драйвер

Может, здесь?

Тьфу-тьфу, с этим говном дела не имею!

Просто какой-то осел модуль ядра драйвером назвал.
Бывает. До сих пор встречаются ослы, которые директории/каталоги/справочники называют "папками". А мамок им не завезли случайно?

Сообщение отредактировал Эдди - Aug 5 2017, 06:42

Это ортодоксальный фанатик, какая винда? О чем вы... Спросите еще, как диск С отформатировать

Драйвер - всегда была программа, являющаяся мостом между аппаратным устр-вом уровня ядра и программой уровня пользователя. В МК таких уровней, как правило, нет, поэтому название "драйвер", как-то не совсем корректно.

Сообщение отредактировал mantech - Aug 5 2017, 06:52

ОС часто есть. И приложение, использующее ОС. Вполне допустимо назвать "прокладку" между приложением и аппаратным ресурсом - драйвером. Можно и как-то иначе, не возражаю.

Если под драйвером понимать то, что в МК обеспечивает работу USB интерфейса, то у меня написано свое под STM32 (назовем USB стек+некая HAL прослойка, хотя с платформонезависимостью я особо не заморачивался). А в чем собственно вопрос?

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

Ну так автор наверно хочет узнать что же входит или должно входить в состав "своего"
Расскажите что у вас там "своё".
Хост или дивайс вы сделали, или может OTG?
Покажите список вызовов вашего API между аппаратурой и фреймворком. Это ж не секретно?
А также между фреймворком и классами.
Или если нет у вас такого деления на уровни, то расскажите почему.
Покажите список классов которые вы реализовали.
Покажите как сделан адаптер к RTOS, как реентерабельность обеспечена и т.д. и т.п.

Нате, глумитесь.

У меня свое все , включая RTOS, графику, математику и т.д. Касательно USB реализован USB device, host/OTG мне не интересен, потому не реализовывался.


Реализованы CDC и аудио устройство, может быть сделаю еще Mass Storage. Деление на уровни есть - нижний уровень общается непосредственно с аппаратурой, ядро реализует обработку базовых запросов и обеспечивает обработку запросов классами, классы взаимодействуют с первыми двумя уровнями, полная изоляция не делалась. Ставилась задача сделать не универсального монстра (таких хватает), а маленький модуль под конкретные задачи. В итоге три VCP и аудио устройство (стерео in/out) у меня занимают:
- базовый модуль (HAL+ядро) 5.2кбайт флеша
- CDC класс (виртуальный ком порт) - 1119байт
- Аудио класс - 456байт флеша

API между классами и стеком несколько нетрадиционен по части стандартных запросов, они реализованы через "карты" обработчиков (по типу того, как сделана обработка событий в MFC/ATL/WTL). Поэтому у меня нет аццких switchей Также все дескрипторы сделаны через макросы, так что нет необходимости подсчитывать их длины, порядок байт и прочую ерунду. Например строковые дескрипторы:


И их обработка:


Разные языки поддерживаются в таком же стиле

Также и с другими запросами (типа выбора интерфейса, параметров CDC, параметров аудиодевайса и т.д., а также стандартные запросы дискрипторов устройства, конфига и т.п.).


Стек изначально рассчитан работу с моей RTOS, потому никаких никаких адаптеров не делалось. Реентабельность обеспечена обычными средствами RTOS - критическими секциями, семафорами и т.д. Без RTOS он не работает, почему так я уже объяснил выше.

P.S. Странный у Вас стиль общения - хотя бы слово волшебное добавили , а то "покажите"... а Вы заплатите, а я покажу . Если есть конкретный вопрос, ну что-то там не едет или что-то конкретное интересует, то спрашивайте - чем смогу - помогу, а просто так время тратить желания нет.

Сообщение отредактировал Шаманъ - Aug 6 2017, 09:57

У меня тоже - почти всё своё Кроме RTOS разве что. Хотя и к ней тоже порт - свой, ну ещё кой-какие её корректировки.
А так и USB-device (когда нужен) - свой, и TCP-стек - свой, и графические библиотеки - тоже свои, о математике и прочих фильтрах и не говорю...


Это как я понимаю - массивы указателей на обработчики? Они у Вас во флешь или интерактивно в runtime-е в ОЗУ создаются?


"Аццкие" switch-и если они действительно аццкие, компилятор как правило превращает в эти же самые массивы указателей. Если возможно.


У меня тоже так же сделано. Только имена макросов другие


Я иногда делаю на callback-ах такое взаимодействие. Например: в TCP-стеке так сделан вызов обработчиков протоколов, обработчиков событий для сокетов и т.п.
Поэтому оно никак не привязано к ОС (или к её отсутствию вовсе).

Видите, вы даже толком не можете описать "своё"
Потому что документацию на него не делали, а API ваше фрагментарное и архаичное. Небось и полного тестирования не делали, и даже профайлинга.
Такого недокументированного всеми забытого добра на гитхабе тоннами лежит.

Я бы TC предложил не делать "своё", а отрефакторить в пределах разумного какой-либо хорошо документированный USB фреймворк.
Вот допустим в MQX есть отличная документация и полные исходники USB стека для Device, Host(EHCI, KHCI), OTG. Имеет реализации всех востребованных классов HID, CDC, MSD, Audio, Video, Composite, RNDIS
Десятки примеров законченных приложений. Полная интеграция в RTOS, файловую систему, TCP стек и т.д.

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

Ага - вон тут в соседних темах товарищ на букву Д (не будем показывать пальцем "рефакторит" всё и "рефакторит" чьи-то шедевры.
Да и так полно тут "рефакторщиков" которые только говнокодом из тырнета живут.
Чем больше смотришь всякие "примеры" тем меньше хочется их рефакторить или вообще как-то использовать.

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