[uriy 4]

Я бы USB host ни за что не запустил без cubemx. А так получилось немного доработав исходники запустить host для hid и чистых bulk.

[bingo 0]

45 minutes ago, uriy said:

Я бы USB host ни за что не запустил без cubemx. А так получилось немного доработав исходники запустить host для hid и чистых bulk.

Я еще лет 5 назад запустил Host USB с  wireless профиль на ST32F105 на основе STMicroelectronics-билиотеки.

Да,  помучился, но все получилось очень маленьким по размеру кода.

Именно для этого и нужна SPLibrary  и ей подобные.

[haker_fox 60]

3 hours ago, bingo said:

Например,  чего стоит самостоятельное написание библиотек для USB  и т.п.

Вообще, вопрос такой неоднозначный. С одной стороны написав свои драйвера, вы становитесь полным хозяином в них, и можете разобраться в них в случае каких-либо проблем. С другой стороны, вам потребуется время на то, чтобы понять, как функционирует железка, для которые вы пишите драйвер. И, применяя готовый код, вроде бы экономится время. Но если в готовом коде возникает проблема, то как быть? Всё равно придётся изучать тот же USB Device, чтобы отыскать ошибку. И не факт, что не придётся изучить весь документ. Вот у меня и возникает сомнение: может быть сразу изучить, и реализовать?

С другой стороны, вот, к примеру, ОС писать смысла вроде как нет. Но здесь есть надёжные и проверенные решения, которые проверены большим количеством человек: FreeRTOS, TNKernel, scmRTOS. И это решения даром. А вот где протестированные годами драйвера USB, I2C, Ethernet MAC? В сложных случаях приходится брать готовое, и править, либо писать своё, смотря в приглядку.

[Arlleex 131]

Дык библиотекарям писать сам драйвер не имеет смысла почти никогда. Например, взять тот же Ethernet. Ну, допустим, нашли готовый драйвер, где каждым битом периферийных регистров можно управлять как угодно. Дальше что? Сегодня оно в standalone работает и хорошо, а завтра ресурсы МК поджались и надо логику программы по-другому организовать, и это, в большинстве случаев, приведет к переписыванию драйверов. Именно поэтому всякие FreeRTOS, FATFS, LwIP и подобные изменять не требуется - это код, не зависящий от внешнего окружения. А вот драйвера переписывать или допиливать приходится чуть ли не всегда.

[mantech 34]

3 часа назад, uriy сказал:

Я бы USB host ни за что не запустил без cubemx. А так получилось немного доработав исходники запустить host для hid и чистых bulk.

По себе скажу, драйвера для таких устройств, как UART, SPI, ADC, таймеров  и подобных однозначно пишу с нуля по даташиту, ибо разбираться в готовых либах, где все через многоуровневые дефайны и структуры - себе дороже, но вот для таких, как SDIO, USB, Video, Ethernet  и подобных, где даташитов может не быть, или много страниц убористым шрифтом, под сотню регистров с не всегда однозначным и понятным описанием... Тут уже кроме даташита приходят на помощь исходники и здравый смысл, ибо писать это с нуля потребуются месяцы. В таком случае поступаю так, беру чужой исходник, перевожу его в себе понятный вид (если это сотня мелких файлов, то группирую по смысловой нагрузке в несколько файлов побольше) убираю ненужный мусор, и пытаюсь запустить. Если результат положительный, начинаю проверять, как это сочетается с даташитом, что позволяет понять, принцип работы устройства и драйвера, и последняя стадия - тестирование с имитацией нештатных ситуаций, исправление лагов и глюков при этом. Для чего нужен этот этап? Просто надо понимать, что большинство всяких SDK пишется с демонстрационной целью, а не для надежной работы, но понять принцип в них проще, чем только в даташите...

[jcxz 184]

6 часов назад, bingo сказал:

Ведь, если все делать вручную (CubeMX  не учитываем в данном случае),  то это не продуктивно.

Почему это?

6 часов назад, bingo сказал:

Например,  чего стоит самостоятельное написание библиотек для USB  и т.п.

И что? Зачем какие-то "библиотеки"? Если USB-стек писать неохота - можно взять готовый. И он от железа не зависит. А нижний уровень взаимодействия с периферией написать самому, читая мануал. А можно и стек свой написать, а потом портировать его при необходимости на другие МК.

Да и в реальных проектах "библиотеки" ничего не облегчают. Они ускоряют натаскивание кучи малопонятного автору кода в проект. Пока эта куча делает более-менее тривиальные и простые действия и пока требования к ней низкие - это прокатывает. И такой кодер выигрывает во времени. Но стоит проекту свернуть чуть в сторону от проторенной "библиотекописателями" тропы и этот самый кодер попадает в тупик и начинает постить в форумы бескрайние портянки своего творения с воплями "помогите, что-то не работает, не понимаю что!". И пытается наугад воткнуть костыли в разные места. И в результате тратит намного больше времени, если бы он сразу сел, и сам разобрался по мануалам как работает его МК.

Так что "библиотеки" продуктивны могут быть только если надо помахать несколькими ножками и выдать несколько байт в UART.

[jcxz 184]

4 часа назад, bingo сказал:

Я еще лет 5 назад запустил Host USB с  wireless профиль на ST32F105 на основе STMicroelectronics-билиотеки.

Пока ваши проекты находятся на уровне игрушек, то ничего страшного. А когда окажется что написанное вами ПО для серийного устройства периодически (очень редко!) сбоит на реальных объектах при каких-то условиях и эти сбои не получается воспроизвести у себя на столе. То поможет тут только полный ревью кода сбоящих частей (или всего кода). Только полностью глазами пройтись по всему алгоритму. Вот тогда Вы может и поймёте разницу между своим досконально понятным кодом и непонятно кем написанными дебрями. И свой код в таких случаях как правило многократно меньше готового, так как реализует только тот функционал, который нужен в данном проекте, а не требует универсальности на все случаи жизни. Вот тогда и поймёте в каком случае нужно больше времени, а в каком меньше. И чего реально стоит "ускорение" полученное при помощи "библиотек".

А такие баги они бывают почти в любом более-менее сложном проекте. И бывает что и неоднократно.

[jcxz 184]

3 часа назад, haker_fox сказал:

С другой стороны, вот, к примеру, ОС писать смысла вроде как нет. Но здесь есть надёжные и проверенные решения, которые проверены большим количеством человек: FreeRTOS, TNKernel, scmRTOS.

Я в своих проектах собственно единственное что использую готовое - это РТОС. Именно по этой причине, что Вы указали - так как оно многократно проверено. Да и то её исходники частично изучаю и переделываю.

[jcxz 184]

1 час назад, mantech сказал:

но вот для таких, как SDIO, USB, Video, Ethernet  и подобных, где даташитов может не быть, или много страниц убористым шрифтом, под сотню регистров с не всегда однозначным и понятным описанием...

В Ethernet кстати тоже не такая уж сложная периферия. Да, например в XMC4xxx тоже - вроде общее число периферийных регистров в ETHERNET-модуле == где-то несколько сотен. Но это на первый взгляд, а если приглядеться внимательнее, то оказывается что 90% их - это регистры с разной статистикой, а реально нужных для работы - даже меньше чем в UART.  

И в Ethernet, USB и пр. нужно всё-таки отделять middleware (стеки) от низкоуровневой работы с железом. Последней как правило в разы меньше. И при переносе на другой МК, править нужно только эту часть.

[haker_fox 60]

3 hours ago, Arlleex said:

Именно поэтому всякие FreeRTOS, FATFS, LwIP и подобные изменять не требуется - это код, не зависящий от внешнего окружения.

Как правило, да. Не требуется. Но это снова, пока их функционал не наступил вам на пятки. Хотя вот тот же LwIP вроде проверенный стек. А статический анализатор (cppcheck, и встроенный в IAR) находит немало предупреждений в нём. И некоторые из них, такие как разыменование указателей без проверки на ноль, заставляют задуматься. Впрочем, анализаторы иногда выдают ложные срабатывания. В целом стек работает.

3 hours ago, Arlleex said:

А вот драйвера переписывать или допиливать приходится чуть ли не всегда.

Ну здесь пришёл к одному выводу - писать с нуля самому. Ну, можно приглядывать в какие-нибудь библиотеки. Там тоже иногда годные решения попадаются. А так - бонусом освоение периферии МК, отыскание багов, не описанных в errata, общее представление того, как работат система.

1 hour ago, jcxz said:

А можно и стек свой написать, а потом портировать его при необходимости на другие МК.

Кстати, повышается конкурентноспособность на рынке. Работодатель вас спрашивает: "Какие коммуникационные интерфейсы у МК знаете?" А вы ему в ответ: "В пять лет написал стек TCP/IP, в шесть - USB Device, и только к 12, но написал стек USB Host". При этом знания не ограничиваются прикручиванием готового, и поверхностным пониманием, как это работает. А есть реально глубокое, осознанное понимание.

1 hour ago, jcxz said:

А когда окажется что написанное вами ПО для серийного устройства периодически (очень редко!) сбоит на реальных объектах при каких-то условиях и эти сбои не получается воспроизвести у себя на столе.

+100500!!!!

Иногда подобные сбои допустимы для какого-то измерительного оборудования - ну поматерятся рабочие, да снова померят. Но если железка работает в реальном времени, например мониторит качество электроэнергии, или обеспечивает РЗиА, то любой лишний сбой - как бы очень и очень дорого может обойтись.

1 hour ago, jcxz said:

Я в своих проектах собственно единственное что использую готовое - это РТОС. Именно по этой причине, что Вы указали - так как оно многократно проверено. Да и то её исходники частично изучаю и переделываю.

Насколько я знаю, вы используете uc/OS-II. Её переделываете? Кстати, немного офф, но всё же... как эта оська в работе? Почему не свободная FreeRTOS, TNKernel, nuttx, mbed OS? Сертификаты важны?

57 minutes ago, jcxz said:

В Ethernet кстати тоже не такая уж сложная периферия.

Мне тоже так кажется. В целом MAC (на все не претендую, только LPC2478, LPC4337), условно конечно, не сложнее обычного UART. По-крайней мере задачи, которые они решают, отдалённо похоже. Вот USB Device, с которым мне предстоит разобраться - это что-то. Хотя, возможно на первый взгляд. Я даже беру смелость попытаться сам написать стек USB Device CDC. Но это пока. Может быть чихну, и поищу что-то готовое...

[Arlleex 131]

17 минут назад, haker_fox сказал:

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

Вообще как-то самонадеянно проверять указатели на 0. Вот о чем это может сказать? Ровно почти ни о чем.

Локальный не инициализированный указатель содержит мусор, как и любая такая же переменная. Ну передали в функцию этот указатель, а та функция проверяет ее на 0. Ну не равна она 0, а равна какой-нибудь локализации Flash или чего еще угодно. И та функция спокойно поработает с этим ненулевым указателем и получим тот же HF, к примеру, потому как полезли куда не надобно. Помог ассерт на 0? Нет, конечно же. Ну а если изначально 0 записывать при инициализации - тогда зачем парсить входные параметры на равенство 0, если итак уверены, что мусора там не будет?

Более того: в некоторых микроконтроллерах размещение областей памяти может быть таким, что на 0-й адрес придется область ОЗУ и ничего не мешает разместить в этой области свои переменные. Например, в STM8S003 так. Положил свой глобальный флаг по адресу 0x0000 и пользуйся. А код с проверками указателей на 0 доступ к этой переменной уже не допустит. Правильно ли это? Очевидно, что нет.

ИМХО, гораздо правильнее парсить аргументы по их допустимому диапазону. Или же предоставить такую возможность MPU (если есть).

Изменено 10 января, 2019 пользователем Arlleex

[scifi 1]

1 hour ago, haker_fox said:

Хотя вот тот же LwIP вроде проверенный стек. А статический анализатор (cppcheck, и встроенный в IAR) находит немало предупреждений в нём. И некоторые из них, такие как разыменование указателей без проверки на ноль, заставляют задуматься. Впрочем, анализаторы иногда выдают ложные срабатывания. В целом стек работает.

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

19 minutes ago, Arlleex said:

Более того: в некоторых микроконтроллерах размещение областей памяти может быть таким, что на 0-й адрес придется область ОЗУ и ничего не мешает разместить в этой области свои переменные. Например, в STM8S003 так. Положил свой глобальный флаг по адресу 0x0000 и пользуйся. А код с проверками указателей на 0 доступ к этой переменной уже не допустит. Правильно ли это? Очевидно, что нет.

Я один раз налетел на такое с 8051. Стандарт гласит: гарантируетируется, что нулевой указатель не указывает ни на какой объект в программе. Очевидно, чтобы это выполнялось, надо немного подрихтовать скрипт линкера.

[one_eight_seven 3]

29 minutes ago, Arlleex said:

Вообще как-то самонадеянно проверять указатели на 0. Вот о чем это может сказать? Ровно почти ни о чем.

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

Как пример вызов функции:

gauss_filter(p_coefficients, to_scratch(p_original));

где p_coefficients указатель на коэффициенты, который - да, вряд ли есть смысл проверять на NULL,  а вот второе - подготовка данных для обработки, которая может содержать malloc или memcpy, которые могут вернуть null, и которая возвращает результат этих функций.

[mantech 34]

3 часа назад, jcxz сказал:

В Ethernet кстати тоже не такая уж сложная периферия.

Да как сказать... Если делать по-простому, то наверно да, а если приделывать ДМА, плюс все остальные запросы в прерываниях и как можно меньше грузить основной цикл программы, тут не все так тривиально.

С УСБ тоже не все так однозначно, контроллеры разные бывают, особенно, если МК "осчастливит" программным УСБ контроллером, не EHCI и пр. то тоже не так все просто.. Хотя, это сугубо ИМХО, может для кого это и как дважды два 

[serglg 0]

10 hours ago, uriy said:

Я бы USB host ни за что не запустил без cubemx. А так получилось немного доработав исходники запустить host для hid и чистых bulk.

Я даже и браться не стал за  USB host (мне надо было читать/писать файлы на флэшдиск). :-)

Оно конечно, и медведя можно научить плясать.

В СССР бы я так и делал. Там сидя на окладе, много чего поизучали. :-)