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

[linuxbergi]

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

[ViKo]

Мне понятно, что имеется в виду драйвер в микроконтроллере. (Ни под что )
Понимаю и поддерживаю желание топикстартера. Но помочь, увы, не могу.

[jcxz]

Мне понятно, что имеется в виду драйвер в микроконтроллере. (Ни под что )

То, что находится в МК в этом случае, принято называть "стеком". Так исторически сложилось

[prottoss]

То, что находится в МК в этом случае, принято называть "стеком". Так исторически сложилось

Под стеком, исторически, подразумевается оболочка и API к ней, которая знать не знает, на каком МК она выполняется. Все что ниже - драйвер.

[AlexandrY]

Под стеком, исторически, подразумевается оболочка и API к ней, которая знать не знает, на каком МК она выполняется. Все что ниже - драйвер.

Не, драйвер эта такая штука которая управляется менеджером драйверов и может быть динамически привязана и отвязана от процесса.
Т.е. физически набор функций со строго единообразным верхним интерфейсом для любой периферии.
У Keil-а отродясь такого не было.
Не все RTOS такое имеют.
Потому как в embedded это излишне, там нет нужды динамически менять и управлять драйверами.
А потому автор должен был написать по простому какой набор функций он хочет реализовать, а не туманить насчет драйвера. Эти функции там на пальцах пересчитать можно.

[prottoss]

Не...

lwIP что по Вашему? Или FatFS?

драйвер эта такая штука которая управляется менеджером драйверов и может быть динамически привязана и отвязана от процесса.

А на мой взгляд, драйвер это такая штука, которая знает как общаться с железом (или еще с чем то...) и предоставляет процессу (или приложению) уровнем выше более-менее стандартный API.

[AlexandrY]

lwIP что по Вашему? Или FatFS?

FatFS, насколько знаю, даже с NAND не умеет работать.
А lwIP не умеет с СDC-ECM.
Это просто наборы функций которые кое-как с помощью косвенной адресации могут перенаправлять свои потоки данных.
Но всей подготовкой к перенаправлению юзер должен заниматься вручную.
Или мы сейчас все что взаимодействует через косвенную адресацию будем называть драйверами?

Я даже скажу, что использования термина "драйвер" крайне вредно для TC.
Вместо того чтобы написать всего две специализированные функции read_x и write_x и остальное разрулить прямым доступом к периферии без всякой унификации, он будет сочинять API, которое сам забудет через месяц.