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

[linuxbergi]

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

[Шаманъ]

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

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

[AlexandrY]

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

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

[Шаманъ]

Ну так автор наверно хочет узнать что же входит или должно входить в состав "своего"
Расскажите что у вас там "своё".
Хост или дивайс вы сделали, или может OTG?

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

Покажите список вызовов вашего API между аппаратурой и фреймворком. Это ж не секретно?
А также между фреймворком и классами.
Или если нет у вас такого деления на уровни, то расскажите почему.
Покажите список классов которые вы реализовали.

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

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

Код

STRINGS_TABLE(Strings)
{
   LANGUAGES(0x409),
   STRING(u"Oleg xxxxxxxxx"),  /* 1 = MANUFACTURER */
   STRING(u"xxxxt"),    /* 2 = PRODUCT */
   STRING(u"0001"),        /* 3 = SERIAL */
   STRING(u"xxxx RX A CAT Port"),  /* 4 = INTERFACE_0*/
   STRING(u"xxxx RX B CAT Port"),  /* 5 = INTERFACE_2*/
   STRING(u"xxxx OTRSP Port"),      /* 6 = INTERFACE_4*/
   STRING(u"xxxx Audio"),           /* 7 = */
   STRING(u"xxxx RX Audio"),        /* 8 = RX Audio Terminal */
   STRING(u"xxxx TX Audio")         /* 9 = TX Audio Terminal */
};

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

Код

//Standard Request Map
BEGIN_REQUEST_MAP(StandardRequestMap)
   .................
   ON_GET_STRING_DESCRIPTOR(Strings)                
   .................
END_REQUEST_MAP()

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

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

Покажите как сделан адаптер к RTOS, как реентерабельность обеспечена и т.д. и т.п.

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

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

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

[jcxz]

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

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

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

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

Поэтому у меня нет аццких switchей

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

Также все дескрипторы сделаны через макросы, так что нет необходимости подсчитывать их длины, порядок байт и прочую ерунду. Например строковые дескрипторы:

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

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

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