Если коротко, то GUI-IDE не позволяют масштабироваться при увеличении ассортимента прошивок в организации. В то время как переход на скрипты сборки на порядки повышает производительность труда программиста.
Я сейчас поддерживаю на плаву примерно 150 прошивок. И меня это даже не утомляет, так как все они собираются из скриптов.
В фирменном Hal для китайских микроконтроллеров Artery Yuntu SDK как раз и написан на битовых полях в объединении . На каждый регистр сделано битовые поле.
Китайцы делают поддержку своих МК намного лучше ,чем европейцы
Ирония в том ,что наши русские вендоры МК решили тупо копировать именно самый галимый на планете Hal от st
Главный инструмент забыли, золотой стандарт сообщества, Альфа и Омега отладки: светодиод! :)
Тут я полностью согласен.
При включении всяческих оптимизаций пошаговый JTAG/SWD отладчик становится абсолютно бесполезным. При высокой оптимизации пошаговая отладка показывает прыжки на случайные участки кода и это не дает никакой ценной информации о реальном пути по которому исполняется Си код. У меня это происходило при отладке загрузчика в EEPROM для MIK32 (K1948BK018) размером 8kByte.
Однако вы можете сделать программный компонент GPIO mapper и отдельной функций натуральному числу ставить в соответствие его бинарный код на наборе конкретных свободных GPIO пинов. Таким образом вы узнаете до куда доползла прошивка перед тем как зависнуть. Или делать GPIO toggle вообще на одном пине. Так можно без отладчика определить, где именно внутри system_init зависла прошивка. Достаточно просто на осциллографе посчитать количество перепадов напряжения.
Рано или поздно Вам скажут, что надо сделать 55+ конфигураций одной и той же прошивки с косметическими изменениями для разных клиентов.
И Вы замучаетесь мышкой в интерфейсе IDE все это курсором проклёвывать.
При работе в IDE, если Вы случайно что‑то поменяете в XML (ewp IAR) и сохраните, то в один утренний день у Вас просто не откроется IDE проект.
Знакома такая ситуёвина?
О сборке даже и говорить не придется.
Далее у Вас начнется приступ судороги, конвульсии и паралич.
Нормально так, да?...
И это правильно. Make скрипты лучше писать самим. Так можно в большей степени контролировать процесс сборки.
Что еще за GYP? Гиперссылка не открывается.
У меня 6.9.0 и эта версия не предлагает генерацию проекта на основе CMake.
На то у меня есть два развернутых ответа в виде отдельных текстов:
Почему Сборка с Помощью GUI-IDE — это Тупиковый Путь https://habr.com/ru/articles/794206/
Почему важно собирать код из скриптов
https://habr.com/ru/articles/723054/
Если коротко, то GUI-IDE не позволяют масштабироваться при увеличении ассортимента прошивок в организации. В то время как переход на скрипты сборки на порядки повышает производительность труда программиста.
Я сейчас поддерживаю на плаву примерно 150 прошивок. И меня это даже не утомляет, так как все они собираются из скриптов.
Там нет переменной
CMAKE_BUILD_DIRПримеры будут?
Меня тоже тошнить от gui-ide. Хочется собирать проекты скриптами.
Что Вам кажется проще для понимания: GNU Make или CMake?
Так получилось, так вышло (с)
https://habr.com/ru/articles/1010484/
Сборка прошивки STM32 компилятором IAR при помощи GNU Make скрипта (IAR+Make=CI/CD)
https://habr.com/ru/articles/996544/
STM32: Виртуальный COM порт на USB (Serial Over USB)
Если собирать через CMake, то прогресс-бар Вы получаете бесплатно.
Буквально из коробки.
https://habr.com/ru/articles/1019118/
STM32 + GCC + CMake + Win10
Да. Это было бы очень полезно.
В фирменном Hal для китайских микроконтроллеров Artery Yuntu SDK как раз и написан на битовых полях в объединении . На каждый регистр сделано битовые поле.
Китайцы делают поддержку своих МК намного лучше ,чем европейцы
Ирония в том ,что наши русские вендоры МК решили тупо копировать именно самый галимый на планете Hal от st
Тут я полностью согласен.
При включении всяческих оптимизаций пошаговый JTAG/SWD отладчик становится абсолютно бесполезным. При высокой оптимизации пошаговая отладка показывает прыжки на случайные участки кода и это не дает никакой ценной информации о реальном пути по которому исполняется Си код. У меня это происходило при отладке загрузчика в EEPROM для MIK32 (K1948BK018) размером 8kByte.
Однако вы можете сделать программный компонент GPIO mapper и отдельной функций натуральному числу ставить в соответствие его бинарный код на наборе конкретных свободных GPIO пинов. Таким образом вы узнаете до куда доползла прошивка перед тем как зависнуть. Или делать GPIO toggle вообще на одном пине. Так можно без отладчика определить, где именно внутри system_init зависла прошивка. Достаточно просто на осциллографе посчитать количество перепадов напряжения.
Rtt без Cli - деньги на ветер.
https://habr.com/ru/articles/1018168/
Отлаживать прошивки можно самыми разными способами.
16 Способов Отладки и Диагностики FirmWare
https://habr.com/ru/articles/681280/
CLI через Segger J-Link RTT на ARM Cortex-M
https://habr.com/ru/articles/1018168/
del