Средства и методы разработки

STM32CubeMX и Eclipse C++, наконец-то заработало. Достаточно было отказаться от настроек проекта плагином GNU MCU Eclipse и довольствоваться Makefile. В общем, поняв, что примеров работы с регистрами напрямую для нужного мне STM32F1xx чипа попросту нет, как и нет рефренс-мануала с примерами работы с регистрами (важны количество мест и последовательность настройки периферии), вынужден был взяться за HAL CubeMX. Ранее на уровне регистров удалось в необходимой части освоить Microchip ATSAM4S16C, тоже Cortex, тоже с CMSIS. Осваивал, скорее, вынужденно, так как в Linux нет вариантов запустить ATMEL Studio. Пришлось разгрести HAL ASF. Повторить такое с CubeMX STM32F оказался не готов просто потому, что STM32CubeMX отлично работает в Linux. В общем, стояла задача работать в проекте, шаблон которого создан STM32CubeMX в среде Eclipse, так как в Eclipse у меня отлично работала отладка. Проверил все варианты целей генерации кода. Оказалось, что в свежий Eclipse C++ нельзя импортировать никакой из вариантов, кроме Makefile. Вариант экспорта/импорта SW4STM32 не заработал, хотя мог бы - одно из конфигурационных полей не распознавалось Eclipse, решения не нашёл. В итоге, остался лишь вариант с Makefile. Попробовал вручную перенести настройки сборки (определения, параметры сборки, пути) в настройки плагина GNU MCU Eclipse. Первая попытка неудачна, сборку невозможно было выполнить. Начал с нуля, всё получилось. Получил идеальный проект, который полностью собирался, бит-в-бит как при make в терминале. Конечно, перенастроил ключи оптимизации, предупреждения по своему вкусу. Всё ОК. Но при добавлении периферии в CubeMX, при таком раскладе, придётся добавлять пути в Include, что не удобно. Попробовал иначе. Тупо создал и настроил проект в STM32CubeMX, сгенерировал код с Makefile. И забил на настройки плагина GNU MCU Eclipse. Через GUI Eclipse настройка параметров сборки недоступна, но пока забил на это. Важнее сейчас заставить работать прототип устройства. Впоследствии или поправлю конфигурацию прямо в Makefile, или перенесу настройки вручную, если будет желание (что уже вряд ли). Маленький нюанс: сборка в Eclipse сразу после создания проекта CubeMX не работает. Ошибка 127. Достаточно разок запустить make в папке проекта из терминала. И всё ОК, собирается бит-в-бит. Что приятно, отладка с использованием OpenOCD заработала сразу, без настроек. Все мои переменные видны как на ладони по наведению курсора мышки. Я балдею, это круче MPLAB X IDE от Microchip, как по функционалу, так и по скорости. В общем, такой путь: 1. Создаю проект STM32CubeMX, со всеми фишками Куба. Генерирую код в варианте с Makefile. 2. Захожу из консоли в папку проекта. Даю make. Убеждаюсь, что всё ОК. Собралось. 3. Импортирую проект в Eclipse CPP как существующий с Makefile. Захожу в настройки проекта C/C++ Build. Убеждаюсь, что Build directory соответствует виду ${workspace_loc:/ПапкаПроекта}. Жму Apply and Close. 4. Делаю Clean Project и Build Project. Есть бинарник! 5. Захожу в настройки отладки. Кликаю на нужном варианте интерфейса, в моём случае OpenOCD Debugging. Параметры отладчика уже настроены глобально, например, OpenOCD options: "-f /usr/local/share/openocd/scripts/interface/cmsis-dap.cfg -f /usr/local/share/openocd/scripts/target/stm32f1x.cfg". Всё подтягивается автоматически. Ставлю Enable auto build. Жму Debug. Работает! 6. Изменения в код вношу стрго внутри разраничителей /* User code start */ /* User code end */, сделаных Кубом. Не забываю сохранять, если хочу вернуться к работе с Кубом. 7. Изменения в Кубе делаю свободно, важно лишь сохранить исходники в Eclipse, если внесены изменения. Для применения изменений Куба в железе достаточно: а) Нажать Generate Code в Кубе и б) Нажать Debug в Eclipse. Всё! IDE и Make видят обновление файлов и пересобирают, по факту, весь проект (так как Куб обновляет все файлы). Изменения в железе работают. Насчёт отношения к HAL. Что скажу, я настроен не так скептически, как многие говорливые из местных. Да, много опосредованности и есть не эффективность. Но, по-моему, ничем не хуже Microchip MCC (Гармонию даже не пробовал - она монстр). Со второго тыка запустил АЦП+DMA со стартом от таймера. Передача UART вообще заработала сразу, и сразу с использованием прерываний. Сначала попробовал вставить свои диагностические затычки в низкоуровневые функции прерываний. Убедился, что работает как надо и нужный код вписал уже в шататные колбэки (как по-русски будет callback?). Глянул код обработки прерывания UART. В чистом остатке там строчек меньше чем на страничку экрана ноутбука. Из-за нагромождения #ifdef и прочих вспомогательных проверок, тестов, assert'ов кажется - мрак! Но при включении оптимизаций - код приемлемый. Сами процедуры передачи данных и обработки ошибок, статуса - хорошо проработаны. В общем, у меня впечатление от Кубового Хала скорее приятное. Спасибо за внимание.