[linuxbergi 0]

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

[jcxz 245]

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

Что имеется в виду под "драйвером USB"? Виндовый драйвер для своего USB-девайса?

[AlexandrY 3]

Что имеется в виду под "драйвером USB"? Виндовый драйвер для своего USB-девайса?

Наверно скорее под линух.

Виндовый работает идеально.

[ViKo 1]

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

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

[Kabdim 0]

Тема пообщаться или о чем? :)

[Eddy_Em 2]

А в чем проблема? Через libudev + libusb все решается. Главное — чтобы systemd чертового не было на компьютере, а то поцтеринг та еще свинья, спокойно может очередную гадость подкинуть.

[LightElf 0]

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

Чем не устраивает кейловский пример?

[jcxz 245]

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

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

[prottoss 0]

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

Я занимался. Достаточно долгое время.

В итоге есть платформонезависимая библиотека. К ней подключаются файлы драйверов для различных МК. Один файл - один модуль и один заголовок.

Сейчас есть драйверы для AVR XMEGA, AT91, STM32 USB, STM32 OTG.

STM32 OTG дался труднее всех. Есть некоторые отличительные нюансы, к примеру, для F107, F407 и L4xx в плане инициализации Device Core. Это те, с которыми работал.

[ViKo 1]

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

Сам Ка(е)йл называл такие вещи драйверами, еще и макроопределение ввел STDPERIPH_DRIVER.

[prottoss 0]

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

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

 

[AlexandrY 3]

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

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

Т.е. физически набор функций со строго единообразным верхним интерфейсом для любой периферии.

У Keil-а отродясь такого не было.

Не все RTOS такое имеют.

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

А потому автор должен был написать по простому какой набор функций он хочет реализовать, а не туманить насчет драйвера. Эти функции там на пальцах пересчитать можно.

[prottoss 0]

Не...

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

 

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

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

[alexunder 4]

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

Обычно это все таки называется библиотекой под МК, хотя иногда и стеком

[AlexandrY 3]

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

FatFS, насколько знаю, даже с NAND не умеет работать.

А lwIP не умеет с СDC-ECM.

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

Но всей подготовкой к перенаправлению юзер должен заниматься вручную.

Или мы сейчас все что взаимодействует через косвенную адресацию будем называть драйверами?

 

Я даже скажу, что использования термина "драйвер" крайне вредно для TC.

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