Перейти к содержанию
    

Своя программная обёртка USB stm32

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...