Комментарии 67
В разделе "Линковка"
r — доступно для исполнения;
Скорее всего имелось в виду "доступно для чтения"
не используя ничего, кроме текстового редактора и командной строки
Я придираюсь, но как пом не компилятор тут ну никак нельзя исключать. Плюс отладчик.
При помощью одной командной строки - это когда через POKE во вcтроенном BASIC набить программу в маш кодах. Да и то, в старых компах типа РК86 в "командой строке" уже были дизасм и отладчик вроде?
В мониторе РК-подобных есть команда типа POKE и команда просмотра фрагмента памяти в hex-дампе. Дизасма и отладчика нет. Там всего 2 килобайта.
Бесконечные холивары типа "сделать всё мышкой в гуёвой программе" или "реализовать всё в консоли в unix-style" будут существовать вечно ровно потому, что у адептов каждой из религий есть свои козыри в рукаве.
Статья была бы более полной, если бы автор привел пару примеров того, что практически полезного (т.е. помимо чувства удовлетворения от большего понимания процесса) может дать ручная сборка, недостижимого при использовании IDE.
практически полезного (т.е. помимо чувства удовлетворения от большего понимания процесса) может дать ручная сборка
Автоматизация, CI/CD, тестирование..
Покуда это не разжевано на понятных сравнительных примерах, всё это лишь набор букв или лозунгов, типа как "за всё хорошее и против всего плохого". Плюс, это звучит так, как будто вы, используя IDE, уже прямо на старте не получаете большое количество функционала, связанного с "автоматизацией и тестированием" (рефакторинг, всевозможный анализ кода, стека, рекурсий итд итп), так, что при ручном подходе, продемонстрированном автором, можно потеть-писать - и даже за год малой доли этого всего не осилить. CI/CD в прошивках МК - ну такой себе, прямо скажем, бенефит...
Сборку средствами Ide используют обычно ну очень слабые программисты. Школота и junы.
Нормальные программисты способны писать скрипты сборки сами.
Сборку средствами Ide используют обычно ну очень слабые программисты. Школота и junы.
"Нормальный" программист и отличается от "ненормального" тем, что знает уместность применения каждого инструмента в каждом конкретном случае, и ценит своё время, а не пишет скрипты ради того, чтобы @aabzelего посчитал "нормальным программистом". Идите уж со своей логикой true-программиста до конца, не пользуйтесь ни богомерзким компилятором, ни компоновщиком, только машинные коды, только хардкор.
Если разработчиков > 1, то , если не вставать из-за IDE, даже нумерация версий прошивок становится проблемой ;)
В IDE есть prebuild- и postbuild-скрипты, парсеры всех мастей, работа с репозиториями (git и пр.). Можно реализовать на них почти любую дополнительную автоматизацию, не вставая из-за IDE.
Плюс, под капотом по сути используется тот же тулчейн, что и в статье, только флагами и параметрами командной строки можно управлять хоть визуально через интерфейс, хоть дописать вручную (также, не вылазя из IDE).
Не удивлюсь, если вскроется, что концепцию разработки в Ide придумали американцы, чтобы в других странах деградировала IT индустрия.
В Stm32cubeide с какойто версии добавили headless режим, можно стартовать сборку из командной строки.
А Keil так давно умеет, мы его таким образом запускали на виртуальной bild-машине, которой рулил jenkins.
Но он к сожалению платный, и я до сих пор версию ARM Clans/ ARM ASM не нашел для Linux :(
А если Eclipse c плагинами запустиь из командной строки вот так
cls
echo off
set project_name=Some_Project
set project_dir=%cd%
echo project_dir=%project_dir%
::set ide_tool=C:\eclipse\eclipsec.exe
set ide_tool=eclipsec.exe
set workspace_dir=%project_dir%\..\..\..\
echo workspace_dir=%workspace_dir%
call %ide_tool% -nosplash -application org.eclipse.cdt.managedbuilder.core.headlessbuild -data %workspace_dir% -build %project_name%/Debug -cleanBuild %project_name%/Debug | tee build_log.txt
То сборка всё равно заклинивает так как надо сперва проделать Refresh мышкой из-под IDE.
В общем сборка из-под IDE это только для кактус-solo разработчиков.
Да и то при условии, что в репозитории только один проект для одной единственной электронной платы.
Сборка из консоли необходима для автосборок в jenkins.
Сейчас даже для одной платы нужно мин 5 прошивок. Загрузчик, genеric, assembly tests, mbr, debug, release.
За всем этим можно уследить только с CI cd.
Мой пример: портирую софт, поэтому запускаю на специально собранных бинарниках юниттесты на реальном железе. Тесты отрабатывают и возвращают статус, и заодно пишут логи в консоль. (Да, в ARM имитация обычной консоли встроена в дебажные инструкции и железо)
Рискну предположить, что польза от понимания происходящего "под капотом ide" не столько в чувстве удовлетворения, сколько в том, что гораздо понятнее становится, что делать, если что-то пошло не так при сборке. Что автоматически сильно сокращает время на починку сломавшейся сборки.
Всякие там автосборки и ci/cd - это уж как пойдет, а вот понимание, что и как происходит - оно здесь и сейчас.
Опять же, настроил однажды тулчейн под stm32 - потом значительно проще будет разбираться с тулчейном от какого-нибудь nordic, у которого даже не знаю, есть ли своя ide :)
Превосходное изложение материала по микроконтроллерами! Сам добывал эту информацию с большим трудом. Респект за статью!
Хорошо описано всё. Сохраню.
В GUI IDE есть какое-то окно с выбором частоты, делителей и так далее. Как без IDE правильно выставить частоты? В каком месте это делает IDE?
Это делается в коде, в разделе инициализации RCC. IDE лишь подставляет значения в соответствующие константы, не более
IDE лишь подставляет значения в соответствующие константы, не более
IDE ведь что-то знает о конкретном типе контроллера и какие значения нужно записать в константы. Есть ли какие-то утилиты для их вычисления без IDE?
Я из того лагеря который не использует IDE. Пока что мне никогда не требовалось устанавливать частоты - использую умолчания. Но рано или поздно это может случится.
Рекомендую открыть HAL от ST, лучше LL-версию из набора библиотек для конкретногл интересующего вас МК и посмотреть как инициализируется тактирование. Там в целом все очень просто и понятно.
Можно пойти еще дальше: поюзать визуальный редактор тактирования в CubeIDE, который и введенные цифири провалидирует по конкретному камню (при этом, ненавистный многим HAL использовать в своем проекте не обязательно, достаточно подглядеть у него что и как он устанавливает, и реализовать всё то же самое в CMSIS). Но если
Я из того лагеря который не использует IDE
то остаётся только страдать вдумчиво читать RM, хотя в случае с ST и это частенько не помогает, т.к. документация хромает, многие моменты постигаются лишь реверсом того же HAL.
Вот не надо. У stm с документацией всё намного лучше чем у российских производителей микроконтроллеров типа Миландр или Нииэт.
И всё-таки есть моменты, которые из документации невозможно однозначно понять. Нужно либо пробовать возможные варианты интерпретации, либо посмотреть в коде от производители, например в HAL - это выходит быстрее.
для Миландра кстати как раз сделали небольшой визуальный кодогенератор как раз для клоков и некоторой периферии. а общий принцип везде одинаков
Вот не надо. У stm с документацией всё намного лучше чем у российских производителей микроконтроллеров типа Миландр или Нииэт.
А причем тут лучше или хуже. Если есть примеры и похуже, то это не снимает проблем, собственно, документации ST. Факт в том, что документация освещает далеко не всё. Куча битов регистров поименована, но идет без описания. Многие настройки описаны лишь поверхностно и не очевидны, приходится либо смотреть как сделано в HAL, либо реверсить GUI СubeIDE, либо вообще действовать методом тыка. Текст RM изобилует опечатками и орфографическими ошибками, как будто он даже ни разу не вычитывался редактором. Баги, кочующие из семейства в семейство, не описанные даже в errata, которыми изобилует форум ST без какого бы то ни было ответа от официалов...
Вот вроде бы всё это по частицам/понимал/где-то находил за годы, но ни разу не видел материала, где всё сводилось бы в достаточно простую форму "на один раз". Благодарю, это хороший материал.
Неистово плюсую за полезный материал!
Благодарю автора!
Каким образом текстовые редакторы например в Eclipse во время пошаговой отладки ассоциируются с gdb и показывают зелёную стрелку?
Можно ли сделать пошаговую отладку кода в notepad++?
Майкрософт создали Debug Adapter Protocol, который предоставляет интерфейс для взаимодействия с дебагером без деталей конкретной работы. gdb и lldb можно использовать через него.
Большое спасибо за статью. Сейчас хочу перебраться на что-то современное 32-х битное, с gcc компилятором и нормальным кодом. Так чтобы классический makefile и погнал. По началу открыл для себя Raspberry Pico, обрадовался куче документации, двум ядрам, мьютексам и прочим радостям. Но при попытке собрать это всё по классике, обломался. Всё через cmake и остальное ардуинопуть через библиотеки, которые криво работают (таймер вынесенный из основного кода в библиотеку отказался работать). Вот и ищу для себя более-менее приемлемое решение.
про cmake что то какое то сильное заявление. вроде ну никак не ардуино путь, вовсе не обязательно библиотеки использовать вообще, и зачем вообще из основного кода переносить что то в (чужую?) библиотеку. В этом плане как раз контроллеры НИИЭТ показательны, там cmake и простенькие библиотеки для периферии, которые скорее как пример кода, но их прямо таки никто не заставляет инклудить, код из них вполне можно скопировать и поправить как удобно.
esp32 гораздо более закрыт в этом плане будет, там наслоений куча
вот atmel/microchip на arm прямо таки заставит копаться в регистрах, там и готовые примеры, и кодогенераторы, но так сделано что без внутрянки никак
ну и еще renesas нам тут сватают регулярно
Тут видимо меня не поняли. Я ничего не имею против cmake.
Я привык написать Makefile раскидав проект по разным файлами и отдельно каждый файл собирать в объектник и потом их линковать. Такой подход мне не удалось реализовать в pico. Только монофайл, либо если хочется вынести часть кода в отдельный файл, то его требуется оформлять как библиотеку (для cmake). И там начинаются неприятные приколы, как уже написал, не работает таймер.
Странная цель - странные средства - странный результат. cmake всего лишь генерирует Makefile. Если у вас сломался таймер от того что вы его вынесли в библиотеку - у вас там ошибка на уровне С. cmake не запрещает разбивать на части хоть код, хоть сборочные скрипты.
Ничего странного нет. Совершенно обычная практика дробить код на логические узлы: код для клавиатуры, код для дисплея, код какой-то логики. Как это делать на pico без танцев с бубном я не понял. Переписывать генерируемый makefile как-то не правильно.
Если у вас на Makefile получается разбить код на несколько файлов, а в cmake нет - значит вы что-то делаете не так. Серьезно. Вот зачем там понадобилась библиотека?
Мне не нравится формат беседы. Я не отрицаю отсутствие компетенции в этом вопросе. И готов учиться. Поэтому открыто прошу помощи.
Могли бы вы пожалуйста привести пример, допустим выноса функции
void hello(void) {
printf("Hello world\n")
}В отдельный си-файл и показать как оформить cmake так, чтобы это всё корректно работало, для rpi2040 (за основу можно взять)? Буду благодарен за ссылки на обучение.
https://github.com/raspberrypi/pico-examples/blob/master/hello_world/serial/CMakeLists.txt
add_executable(hello_serial
hello_serial.c
)
# pull in common dependencies
target_link_libraries(hello_serial pico_stdlib)
# create map/bin/hex/uf2 file etc.
pico_add_extra_outputs(hello_serial)
# add url via pico_set_program_url
example_auto_set_url(hello_serial)Например, добавляете во 2 строку все необходимые исходники, через пробел. Если этот helloworld с одним файлом работает - точно так же будет работать и с 2.
Только собираться оно должно, няп, отсюда - https://github.com/raspberrypi/pico-examples/blob/master/CMakeLists.txt - там инклудится какая-то pico-специфичная магия.
В общем у меня получилось, спасибо большое. Делал по мануалу, раздел 8.Creating your own Project.
Вышло так:
cmake_minimum_required(VERSION 3.13)
include(pico_sdk_import.cmake)
project(habr C CXX ASM)
set(CMAKE_C_STANDARD 11)
set(CMAKE_CXX_STANDARD 17)
pico_sdk_init()
add_executable(habr
habr.c
hello.c
)
pico_enable_stdio_usb(habr 1)
pico_add_extra_outputs(habr)
target_link_libraries(habr pico_stdlib )habr.c и hello.c
//habr.c
#include <stdio.h>
#include "pico/stdlib.h"
void hello(void) {
printf("Hello, world!\n");
}//hello.c
#include <stdio.h>
#include "pico/stdlib.h"
void hello(void) {
printf("Hello, world!\n");
}//hello.h
#ifndef __HELLO_H__
void hello(void);
#endif //__HELLO_H__@moderator кода в режиме редактирования подсвечивается, но после публикации нет. (от всей души не люблю новый интерфейс).
Пардон, заработало.
Тут опечатка, и только сейчас заметил. habr.c выглядит так:
#include "pico/stdlib.h"
#include "hello.h"
int main() {
stdio_init_all();
while (true) {
hello();
sleep_ms(1000);
}
}
За совет по контролем спасибо. Ну вот мне понравилась статья, вроде всё по классике.
Обратил внимание что в reset_handler копирование кода из флеш в память выполняется побайтово, хотя то же зануление переменных делается 32-битными словами.
Для этого есть какие-то причины?
Чип и его регистры вроде как 32-битные, без помощи оптимизатора должно быстрее копировать по-словно.
STM32. Процесс компиляции и сборки прошивки