Шаманъ 0 9 августа, 2017 Опубликовано 9 августа, 2017 · Жалоба Лучше всего все описано в документе usb_20.pdf который скачивается с сайта usb.org. В главе 9 машина состояний во всех подробностях, а в главе 8 ответы на вопросы про то как осуществляется передача данных. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
linuxbergi 0 9 августа, 2017 Опубликовано 9 августа, 2017 · Жалоба В своё время интересовался USB , даже опубликовал результат своих изысканий https://yadi.sk/i/kQfoeUJ8iicDi Чем плохи доки по стандартам? Они объективно очень громоздки в силу их специфики, там предусматриваются все варианты событий, какие только возможны. Например если смотреть стандарт по HID, то умопомрачительно, а кто знает, что такое custom hid (наиболее используемый на практике), тот рассмеётся. На практике можно многое отбросить, скостить углы. Основу моего проекта составляют идеи предоставленные здесь: http://mcu.goodboard.ru/viewtopic.php?id=40 Может модератор не удалит сей ценный материал? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 9 августа, 2017 Опубликовано 9 августа, 2017 · Жалоба В своё время интересовался USB , даже опубликовал результат своих изысканий Вы идете совершенно неэффективным путем. Если нужен эталон как правильно писать под USB в embedded то всегда смотрят у Micrium-а. Он делает исходники специально так чтобы начинающие могли легче понять как все внутри устроено. И только у Micrium-а документация действительно объясняет как работает их софт. Диаграмма выше как бы намекает, что вам до своего "драйвера USB" как до луны. А эта диаграмма показывает слои. У Micrium-а драйверы действительно являются драйверами. И как видно драйвер у них это даже не половина дела. Справок где берут Micrium USB, документацию на него и какая у него лицензия не даю. :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
linuxbergi 0 10 августа, 2017 Опубликовано 10 августа, 2017 · Жалоба За информацию и отклики благодарен всем, рискну выложить схему реализации, может кто-нибудь ещё подкинет идей. В цикле мониторятся флаги событий. GLOBAL_SM - мониторит RESET, SUSPEND и пр. Группа TRN_SM собирает из отдельных транзакций запросы управления, мониторит флаги транзакций передач управления. После транзакции setup, выполняется парсинг пакета конфигурации (выделено голубым), остальные секции не реагируют, состояние автомата фиксируется в глобальных переменных. По транзакции IN выполняется соответственная секция кода, состояние фиксируется в гл. переменных. Транзакция setup общая для всех передач управления, а дальнейшая реализация зависит от парсинга конфигурационного пакета из этой самой транзакции setup. В секции setup устанавливается указатель на функцию реализующую конкретный запрос и далее эта функция вызывается каждый раз при выполнении последующих транзакций пока запрос не закончится выполняться. Думаю схема ясна. Обработчик транзакций передачи данных прост, по сравнению с управляющими, поэтому пока не рассматривается Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться