STM32СubeMX и подобные Опции

[-AZ-]

Хотел собрать мнения специалистов, на примере STM32CubeMX.
Все-таки стоит ли применять подобные вещи или это для домохозяек?
При написании больших проектов на чистых С, С++ падает скорость разработки, но пока проверишь используемые ветки HAL, получается тоже не быстро.
Есть ли подводные камни и сложности "ручной" сборки например RTOS, в Cube довольно быстро, но качество неизвестно.
Может применение библиотек производителей, пусть не совсем хороших, не так уж плохо?
Очень интересно мнение тех, кто имеет практический опыт по этой теме.

[haker_fox]

Очень интересно мнение тех, кто имеет практический опыт по этой теме.

Как всегда на любой вопрос нельзя дать однозначного ответа. Всё зависит от ваших условий и вашего опыта. Я имею опыт использования библиотеки CMSIS для микроконтроллеров серии LPC. Мы решили в своё время её использовать как раз для упрощения работы, и, частично, полагали, что она избавит нас от рутины. Отчасти так и произошло. Но в каждой версии CMSIS'а я находит ошибки (I2C, DMA, SSP). Как правило, функционал этих библиотек никогда не соответствовал нашим требованиям (возможность работы с ОС, по прерываниям и т.п.). Да и самое обидное было искать ошибки в библиотеке, цель которое - избаватить нас от этого процесса. Но опыт мне дал возможность подумать, и сделать вывод: что сейчас я бы начал писать свой драйвер под каждый модуль микроконтроллера. Опираясь только на даташит, юзер мануал и т.п. Вполне возможно заглядывал бы в библиотеки как в референс-дизайн. Всё-таки люди там тоже не одну собаку съели, и некоторые моменты могут быть хорошо разжёваны. Поэтому смотрите сами. Если у вас опыт совсем небольшой, берите готовую библиотеку, ищите в ней ошибке по ходу работы, исправляйте под свои нужды. Если опыта достаточно, я полагаю вы бы не стали задавать этот вопрос. Но если опыта недостаточно, а времени - вагон с тележкой, то можете попробывать и подход, к которому я пришёл)))

[-AZ-]

Давно уже, гуру рекомендовали не использовать чужие либы, я так пошел.
Времени прошло много, да именно так как вы говорите, пишу свои драйвера на каждую периферию с полным пониманием регистров.
Но почему решил собрать актуальное мнение на сегодняшний день, сложность проектов растет, кол-во типов контролеров тоже, переносимость кода в общем-то получается никакая. И довольно сильно увеличивается время разработки. Хочется понять чем сегодня "дышит" мир гуру. Может все-таки время asm проходит...
Вопрос относится к разработкам в рамках производства, а не частных поделках.

Сообщение отредактировал phenixs - Feb 14 2018, 03:39

[haker_fox]

переносимость кода в общем-то получается никакая.

Это быть не должно. Я использую Си++ при разработке драйверов. Хотя это не важно. Но все драйвера имеют более-менее одинаковый интерфейс. Поэтому для софта не важно, работаете вы часами внутри микроконтроллера, или это часы на i2c висят. Или это часы вообще с sntp сервера.

Может все-таки время asm проходит...

Оно прошло ещё лет 15 назад.

Вопрос относится к разработкам в рамках производства, а не частных поделках.

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

[pitt]

Документация ко всем STM32, с которыми мне приходилось иметь дело не лезет ни в какие ворота - совершенно неоднозначная, написана не по-английски(по-видимому, французский или итальянский) и перевод ужасный. В таком случая Куб помогает понять, о чем же хотела сказать документация. Еще одно достойное применение Куба для электриков - быстро написать примитивный проверочный код для проверки железа/периферии. Для создания профессионального продукта его тоже "можно" использовать, если вас и ваших клиентов надежность интересует в последнюю очередь.
Сейчас молодые коллеги поднимут громкий крик о достоинствах этого индийского продукта, но, в конце концов, " думайте сами, решайте сами - иметь или не иметь..."

[scifi]

Документация ко всем STM32, с которыми мне приходилось иметь дело не лезет ни в какие ворота - совершенно неоднозначная, написана не по-английски(по-видимому, французский или итальянский) и перевод ужасный.

Люто минусую. За 10+ лет работы с STM всего пару раз столкнулся с неоднозначностью в документации, причём в мелочах. У писателей английский не родной язык, но текст весьма приличный. В общем, не надо напраслину возводить.

[-AZ-]

Вот, ключевые слова - если вас и ваших клиентов надежность интересует-
Значит все-таки получается не стоит рисковать с применением индусских библиотек.
Соответственно для увеличения скорости разработок необходимо увеличит штат программистов для реализации собственных драйверов(либо аутсорсинг),
основанных на полном понимании железа и регистров, а не бездумным тыканием в Cube.

[Quasar]

... не стоит рисковать с применением индусских библиотек.
Соответственно для увеличения скорости разработок необходимо увеличит штат программистов ...

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

[-AZ-]

Возможно не стоит содержать свой штат и писать драйвера которые кто то уже точно делал, а наверное под каждую задачу искать исполнителя на постоянной основе. Так будет ещё быстрее.

[Quasar]

Возможно не стоит содержать свой штат и писать драйвера которые кто то уже точно делал, а наверное под каждую задачу искать исполнителя на постоянной основе. Так будет ещё быстрее.

Не совсем понял, а что значит не содержать свой штат, но искать кого-то на постоянной основе? В смысле стороннего исполнителя на постоянной основе?

[-AZ-]

Не совсем понял, а что значит не содержать свой штат, но искать кого-то на постоянной основе? В смысле стороннего исполнителя на постоянной основе?

Это субъективное мнение, имею в виду обеспечивать постоянной работой одного или двух проверенных аутсорсеров.
Аутсорсеров потому что как правило не удается найти человека в штат с необходимым опытом, практика показывает, самородки раскиданы по стране, соответственно удаленка.

[Jenya7]

Категорически против CubeMX. Уж лучше SPL - намного лучше. А если его (SPL) подправить так вообще конфета получается.

[amiller]

С каждым днём на форуме всё больше вопросов по Cube, HAL, SPL и т.п.
По нужности применения - вопрос дискуссионный.
Но вот подумать над тем, чтобы выделить всё это добро в отдельную ветку, надо.
На мой взгляд дискуссии о том, какой параметр и в какой функции что обозначает и для чего применяется, уже не имеет никакого отношения к микроконтроллерам.
Пусть уж люди, которые сделали выбор в пользу использования этих инструментов варятся в собственном соку.

[-AZ-]

Категорически против CubeMX. Уж лучше SPL - намного лучше. А если его (SPL) подправить так вообще конфета получается.

Вот, тоже хотел озвучить это мнение, SPL в общем то и есть в чистом виде драйвера, стиль оформления кода конечно жесть, но привести в порядок и по моему очень даже ничего.
Но это применимо к ST, с другими производителями опять начнутся вариации...
Соответственно для стандартизации кода на предприятии наверное лучшим вариантом остается свои библиотеки.

[0men]

применяю HAL, код из куба только для первого ознакомления изредка