Интересно, есть шанс дожить до времени когда появление девушки-технаря в чате не будет провоцировать разговоры на тему гендерных стереотипов :)

ну если будет здоровая дискуссия это хорошо :)

нэт

Всем привет,
Тут выше была речь про cubeMX, и замечания в его сторону, что он плох и фу фу фу, а можно конкретнее, чем именно плох(если рассматривать его для генерации проекта) ?
1. Написан на джаве.
2. Генерит кучу мусора в виде конфиг файлов, и комментов в коде.
3. Не работает для перегенерации проекта из одной иде в другую.
4. Стирает код при перегенерации проекта(если код указан за пределами допустимых мест).
5. Может по разному генерить код для одной и той же версии stm драйверов.

Только эти причины? Или есть еще более менее глобальные?

Коннект закрыт типа

основная причина того что люди считают что он плох состоит в том что когда-то они все трахались писать на ассемблере под АВР или писали под тот же стм32 но все вручную и считают что другие люди тоже должны трахаться))

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

Ммм...не подскажу..

хал это не куб

1. плохая причина. хоть на питоне лишь бы работало.
2. тоже не аргумент
3. работает.
4. если пользуешь инструмент то учись им пользоватся правильно
5. все зависит от используемой версии FW которая подгружается по интернету

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

Все эти пункты не минусы. Ни один не относится к коду в прошивке

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

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

У меня на работе есть мужик который вообще считает что под микроконтроллеры надо ОБЯЗАТЕЛЬНО писать на ассемблере, а те кто пишут на си - быдлокодят и упускают множество нюансов.
Точно так же как сейчас сторонники писать ручками через регистры хейтят HAL.

Все это субъективщина потому что все считают правильным только свой путь.

а зачем?

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

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

По поводу пункта 4 писать код мимо, равно сильно обижаться на кошку которая не ходит в лоток

в конце концов если так боитесь за работоспособность проекта на HAL то вопрос к тому как вы тестируете свой код.

Спасибо за развернутые ответы.
По поводу перегенерации проекта, например перегенерация проекта из куба в атоллик у меня из коробки не завелась

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

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

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

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

точнее файлы в проект добавить