[Eddy_Em 2]

Вообще дурацкое это слово — "драйвер". Я только драйверы шаговых двигателей могу вспомнить. Где еще в природе это слово употребляется? На компе с железяками работают модули ядра (если их сразу в ядро не вмонолитили). На железяках крутятся прошивки. Где драйвера-то?

[ViKo 1]

Эдди, вы когда-нибудь ставили Виндовс на голый комп?

https://ru.m.wikipedia.org/wiki/Драйвер

[Сергей Борщ 143]

Где драйвера-то?

Может, здесь?

 

[Eddy_Em 2]

Эдди, вы когда-нибудь ставили Виндовс на голый комп?

Тьфу-тьфу, с этим говном дела не имею!

Может, здесь?

Просто какой-то осел модуль ядра драйвером назвал.

Бывает. До сих пор встречаются ослы, которые директории/каталоги/справочники называют "папками". А мамок им не завезли случайно?

Изменено 5 августа, 2017 пользователем Эдди

[mantech 57]

Эдди, вы когда-нибудь ставили Виндовс на голый комп?

 

Это ортодоксальный фанатик, какая винда? О чем вы... Спросите еще, как диск С отформатировать

 

Драйвер - всегда была программа, являющаяся мостом между аппаратным устр-вом уровня ядра и программой уровня пользователя. В МК таких уровней, как правило, нет, поэтому название "драйвер", как-то не совсем корректно.

Изменено 5 августа, 2017 пользователем mantech

[ViKo 1]

Драйвер - всегда была программа, являющаяся мостом между аппаратным устр-вом уровня ядра и программой уровня пользователя. В МК таких уровней, как правило, нет, поэтому название "драйвер", как-то не совсем корректно.

ОС часто есть. И приложение, использующее ОС. Вполне допустимо назвать "прокладку" между приложением и аппаратным ресурсом - драйвером. Можно и как-то иначе, не возражаю.

[Шаманъ 1]

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

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

[Сергей Борщ 143]

Я, конечно, понимаю, что есть два мнения - ваше и неправильное Но давайте вы будете придерживаться культуры общения на форуме и ограничите свои сообщения литературным языком.

 

[AlexandrY 3]

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

Ну так автор наверно хочет узнать что же входит или должно входить в состав "своего"

Расскажите что у вас там "своё".

Хост или дивайс вы сделали, или может OTG?

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

А также между фреймворком и классами.

Или если нет у вас такого деления на уровни, то расскажите почему.

Покажите список классов которые вы реализовали.

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

 

 

 

[prottoss 0]

Покажите...

Нате, глумитесь.

stm32_usbd.rar

[Шаманъ 1]

Ну так автор наверно хочет узнать что же входит или должно входить в состав "своего"

Расскажите что у вас там "своё".

Хост или дивайс вы сделали, или может 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. Странный у Вас стиль общения - хотя бы слово волшебное добавили ;), а то "покажите"... а Вы заплатите, а я покажу ;). Если есть конкретный вопрос, ну что-то там не едет или что-то конкретное интересует, то спрашивайте - чем смогу - помогу, а просто так время тратить желания нет.

Изменено 6 августа, 2017 пользователем Шаманъ

[jcxz 245]

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

У меня тоже - почти всё своё :rolleyes: Кроме RTOS разве что. Хотя и к ней тоже порт - свой, ну ещё кой-какие её корректировки.

А так и USB-device (когда нужен) - свой, и TCP-стек - свой, и графические библиотеки - тоже свои, о математике и прочих фильтрах и не говорю... :laughing:

 

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

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

 

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

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

 

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

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

 

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

Я иногда делаю на callback-ах такое взаимодействие. Например: в TCP-стеке так сделан вызов обработчиков протоколов, обработчиков событий для сокетов и т.п.

Поэтому оно никак не привязано к ОС (или к её отсутствию вовсе).

[AlexandrY 3]

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

 

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

Видите, вы даже толком не можете описать "своё"

Потому что документацию на него не делали, а API ваше фрагментарное и архаичное. Небось и полного тестирования не делали, и даже профайлинга.

Такого недокументированного всеми забытого добра на гитхабе тоннами лежит.

 

Я бы TC предложил не делать "своё", а отрефакторить в пределах разумного какой-либо хорошо документированный USB фреймворк.

Вот допустим в MQX есть отличная документация и полные исходники USB стека для Device, Host(EHCI, KHCI), OTG. Имеет реализации всех востребованных классов HID, CDC, MSD, Audio, Video, Composite, RNDIS

Десятки примеров законченных приложений. Полная интеграция в RTOS, файловую систему, TCP стек и т.д.

 

А все что "полностью своё" это будет как правило очень примитивно с урезанной функциональностью, не документировано и непереносимо даже на уровне компиляторов.

 

[jcxz 245]

Я бы TC предложил не делать "своё", а отрефакторить в пределах разумного какой-либо хорошо документированный USB фреймворк.

Ага - вон тут в соседних темах товарищ на букву Д (не будем показывать пальцем ;) "рефакторит" всё и "рефакторит" чьи-то шедевры.

Да и так полно тут "рефакторщиков" которые только говнокодом из тырнета живут.

Чем больше смотришь всякие "примеры" тем меньше хочется их рефакторить или вообще как-то использовать. :laughing:

 

[Kabdim 0]

Вот допустим в MQX

есть лицензия, которая запрещает использовать MQX где-то кроме фрискейловских процов.