[Шаманъ 0]

Лучше всего все описано в документе usb_20.pdf который скачивается с сайта usb.org. В главе 9 машина состояний во всех подробностях, а в главе 8 ответы на вопросы про то как осуществляется передача данных.

[linuxbergi 0]

В своё время интересовался USB , даже опубликовал результат своих изысканий

https://yadi.sk/i/kQfoeUJ8iicDi

Чем плохи доки по стандартам? Они объективно очень громоздки в силу их специфики, там предусматриваются все варианты событий, какие только возможны. Например если смотреть стандарт по HID, то умопомрачительно, а кто знает, что такое custom hid (наиболее используемый на практике), тот рассмеётся. На практике можно многое отбросить, скостить углы.

Основу моего проекта составляют идеи предоставленные здесь:

http://mcu.goodboard.ru/viewtopic.php?id=40

Может модератор не удалит сей ценный материал?

[AlexandrY 3]

В своё время интересовался USB , даже опубликовал результат своих изысканий

Вы идете совершенно неэффективным путем.

Если нужен эталон как правильно писать под USB в embedded то всегда смотрят у Micrium-а.

Он делает исходники специально так чтобы начинающие могли легче понять как все внутри устроено.

И только у Micrium-а документация действительно объясняет как работает их софт.

Диаграмма выше как бы намекает, что вам до своего "драйвера USB" как до луны.

 

А эта диаграмма показывает слои.

У Micrium-а драйверы действительно являются драйверами.

И как видно драйвер у них это даже не половина дела.

 

Справок где берут Micrium USB, документацию на него и какая у него лицензия не даю. :laughing:

 

[linuxbergi 0]

За информацию и отклики благодарен всем, рискну выложить схему реализации, может кто-нибудь ещё подкинет идей.

В цикле мониторятся флаги событий. GLOBAL_SM - мониторит RESET, SUSPEND и пр. Группа TRN_SM собирает из отдельных транзакций запросы управления, мониторит флаги транзакций передач управления. После транзакции setup, выполняется парсинг пакета конфигурации (выделено голубым), остальные секции не реагируют, состояние автомата фиксируется в глобальных переменных. По транзакции IN выполняется соответственная секция кода, состояние фиксируется в гл. переменных. Транзакция setup общая для всех передач управления, а дальнейшая реализация зависит от парсинга конфигурационного пакета из этой самой транзакции setup. В секции setup устанавливается указатель на функцию реализующую конкретный запрос и далее эта функция вызывается каждый раз при выполнении последующих транзакций пока запрос не закончится выполняться. Думаю схема ясна. Обработчик транзакций передачи данных прост, по сравнению с управляющими, поэтому пока не рассматривается