Своя программная обёртка USB stm32, Создание своего драйвера USB для STM32 Опции

[linuxbergi]

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

[Шаманъ]

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

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

[AlexandrY]

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

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

[prottoss]

Покажите...

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

Прикрепленные файлы

 stm32_usbd.rar ( 1.29 килобайт ) Кол-во скачиваний: 79

 

[linuxbergi]

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

Премного благодарен! Многая лета.

В книге 'Making Embedded systems' описывается шаблон программирования МК под названием 'драйвер', ну это так.
Залез в USB-FS-Device_Lib_V4 и ужаснулся, мрачное нагромождение файлов и не понятно по какому принципу.
Меня интересовало как можно подойти к проблеме.

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




Но при ближайшем рассмотрении выяснилось, что обработку управляющих запросов от хоста невозможно представить одним конечным автоматом. Схема сложней. После выполнения транзакции SETUP нужно раскодировать конфигурационный пакет. По результатам расшифровки выбирается один из некоторого множества конечных автоматов, отражающий запрос. Ниже граф переходов для запроса GET_DESCRIPTOR c несколькими стадиями данных. Транзакции выполняются аппаратурой автоматически, по результатам выполнения выставляют флаги. Хост инициирует тр. setup, из сост. I переходит в S, готовит буфер USB для следующей транзакции от хоста и т.д.

Эскизы прикрепленных изображений