Комментарии 99
В общем распространение IDE это яркий пример известного ныне "технологического диктата" запада для стран второго и третьего мира.
В странах "первого мира" конечно же используют только мейк файлы, но тщательно это скрывают.
Язык make простой и это, в сущности, bash
вообще не баш, иначе ба зачем был нужен мейк
9--Язык make очень прост. Вся спека GNU Make это 226 страниц
прям запредельная простота
В странах "первого мира" конечно же используют только мейк файлы
Да. Разумеется. Я работал в английском автопроме. Прошивки для ECU собирают там из само писных makefile(лов). *.mk подвергают версионному контролю наравне с *.c *.h.
Всех всё устраивает.
Обобщать не стоит. Работал в немецком и американском автопроме, использовали cmake, bazel и bake, каждый хорош и плох по-своему. make и cmake перестают работать в сильно гетерогенных сборках, когда надо запустить 50 разных генераторов в разной последовательности и всё это дело соркестрировать в единый результат, желательно со временем компиляции, измеряемым в минутах, а не часах и днях.
> Всех всё устраивает.
примерно так, мне к примеру тоже без разницы, столько видел ddk, sdk, и пр., удивить трудно, чего никогда не понимал на habr, так это минусования вполне грамотных комментариев из-за того что у людей разный опыт
Навязывание GUI-IDE (Keil, IAR, CCS) это форма технологического диктата со стороны стран бывших метрополий. Они привыкли помыкать своими колониями и до сих пор продвигают эту подлую циничную политику подсовывая vendor loсking средств разработки.
Сами они этим суррогатом не пользуются. Понимаете? У них там CMake, Ninja скрипты сборки и полный DevOps в Docker контейнерах.
А туземцам они суют эту тухлую песочницу в которой только кривые куличи лепить возможно
прям запредельная простота
Дружище @tzlom, а напомни ка сколько страниц спека CMake? Уж не больше ли?
226 страниц Make это не так уж и много для второй книги, которую надо прочитать чтобы программировать МК после учебника по Си.
статья заслуживает внимания, конечно это типа начального чтения, для более серьезного например YOCTO -
В embedded разработке makefile по старинке ручками пишут, всякие autotools / configure для автоматизации, или альтернативы вроде bazel не распространены?
в embedded используют все что подходит по требованиям, например кроме Linux VxWorks 653, makefiles типа полезный ликбез, который всегда пригодится, посмотрите AECS (4.3 Build Subsystem ) -
https://ntrs.nasa.gov/api/citations/20160000333/downloads/20160000333.pdf
Спасибо за ссылку
У NASA есть еще такой хороший док The Power of Ten (Rules for Developing Safety Critical Code) 6 страничек всего
http://pixelscommander.com/wp-content/uploads/2014/12/P10.pdf
В embedded разработке иногда собирают из Cmake, который в свою очередь автогенерирует makefile или ninja.
Например так в ZephyrProject.
Но Cmake скрипты ненадежны для automotive так как часто дают осечки. В if(ы) не заходит например.
много глаз присматривают за CMake включая sandia и cern для тривиальных ошибок, если что возможно давно закрыто -
Я спросил Бинг/Чатгпт, он вспомнил про один баг с комментариями 2002-го года, и изменение в поведении 2014-го. Если очень-очень долго не обновляться, можно наверное словить.
There are a few possible reasons why CMake does not enter an if statement. Some common mistakes are:
Using incorrect syntax for the condition argument of the if clause. You can refer to the Condition Syntax section of ¹ for more details on how to write valid expressions for CMake if statements.
Using a variable name that is affected by Policy CMP0054¹, which determines whether quoted variables should be dereferenced. For example, if you write
if ("${VAR}"), CMake will treat it as a string unless you set CMP0054 to NEW¹.Using end-of-line comments inside an if statement, which may cause unexpected behavior such as skipping the first line of the if body or changing the evaluation of the condition³. It is recommended to avoid end-of-line comments and use separate lines for comments instead.
I hope this helps you debug your CMake issue.?
Source: Conversation with Bing, 3/18/2023(1) if — CMake 3.26.0 Documentation. https://cmake.org/cmake/help/latest/command/if.html Accessed 3/18/2023.
(2) [Cmake] cmake bug with IF statement and end-of-line comment. https://cmake.org/pipermail/cmake/2002-May/059634.html Accessed 3/18/2023.
(3) CMake IF (something OR something else) - Stack Overflow. https://stackoverflow.com/questions/19144020/cmake-ifsomething-or-something-else Accessed 3/18/2023.
Ну, воще то синтаксис у cmake местами действительно странный. Местами он декларативный - ожидается что он сам разберётся, в каком порядке выполнять инструкции. Местами порядок важен. Местами case insensitivity, местами case sensitivity. endif(условие, которое вроде как должно соответствовать условию в if(), но можно и без него) - полный кринж.
я только что бегло погуглил, во всем интернете включая stackoverflow не нашлось каких-либо свидетельств о багах в CMake вызывающих рандомные несрабатывания if'ов
Вот, пожалуйста. Cmake зашел в if в который не просили
этот ваш Сmake - маркетинговая хохма
Ну не склоняются английские слова, но вы аж в заголовок умудрились своё (ов) воткнуть.
IDE отжирают много ресурсов компьютера
IDE стоят дорого, порядка 3500 EUR
Статья в песочнице ждала с 1980-х?
Make это как пуговицы. Старая, простая и очень полезная вещь.
Старинные. Кованые кузнецом. По 100 грамм каждая.
Make скрипты - это как катализатор в химии. Благодаря GNU Make всё происходит быстрее.
Скрипты сборки Make - это как стапели, но не для корабля, а для программы.
Надо использовать CI/CD, чтобы прошивки собирались изолированно на отдельном сервере из Git репозитория.
Это позволяет гарантировать чистую сборку. А для таких автосборок необходимы скрипты сборки (GNU Make).
Чтобы не было такого, что одна и та же прошивка ведет себя по-разному в зависимости от того на чьём компе она была собрана.
Или такого, что код склонированный с репозитория вообще не собирается. Потому, что автор забыл закомитить какие-то файлы.
Если вы собираете из make, то очень вероятно, что у вас получится чистый, аккуратный репозиторий сам собой.
Так вот в чем секрет! :) Нужно не зелёную галочку нажимать, а в консоли make all набирать, и говнокод станет чистый и шелковистый.
Можно очень много ошибок отловить на этапе отработки утилиты make
Создать ошибок. Дебажить ошибки в makefile тот ещё квест.
Не знаю о чем статья. Работаю в IDE за 0 евро. Idea ce, vs code. При этом часто особенно для голанга для сборки использую старый добрый мейк, который вызываю во встроенном в ide терминале. Я вот в итоге и не знаю, автор бы меня похвалил или предал бы анафеме???)))
Не могу ничего сказать насчёт кода на C, но в целом использование Make для меня, как девопс-инженера, действительно очень упрощает автоматизацию. Для этого даже существует целая парадигма "три мушкетёра" — make, docker, compose.
Чет какая то труха в статье.
Иде отжирает не сильно больше браузера. Даже монстр на яве.
Есть IDE общего назначения умеющие во все мс студия, вс крд, клион, кривой эклипс.
Часть бесплатна. Но да, за хорошее надо платить, особенно когда контора делает дела, а не экономит мейкфайлами.
Потому что нефиг хранит описание сборки проекта в хмл. Есть смейки и мезоны для этого.
Тоже что и пункт 4.
Тоже что и 4.
Всегда можно сделать аналоговнетную. Ведь можно... Можно же?
В каком то кб грохнули лицуху на клон эклипса, теперь у дедов, которые сами себя закопали под проприетарную проектную систему весеннее обострение и мейкфайло рейдж.
make это замечательно, только вот есть маленькая такая проблема. Есть вендоры (Texas к примеру), у которых сборка только родными инструментами и возможна. Нет, вызвать компилятор cl6x и его инструментарий из командной строки вам никто запретить не может. Но в тот момент, когда вы захотите сделать что-то сложнее Hello World и начнёте использовать NDK, IPC и прочие библиотеки для работы с этими процессорами, вам потребуется великий и ужасный Code Composer Studio. Отладчик опять же у них работает только в нем.
Максимум, чего мне удалось добиться - запуск процесса сборки из консоли, что позволяет использовать sublime или qtcreator в качестве редактора кода.
Есть вендоры (Texas к примеру), у которых сборка только родными инструментами и возможна.
Поздравлю вас! Вы подпали под "технологический диктат". Хотя это и не удивително для политики США(Texas Instruments).
Вот попросите у TI техподдержки репозиторий из make.
Посмотрим, что они вам ответят.
Даже IDE-IAR не оказывает техподдержку по сборку из make.
Что уж говорить про TI
Есть вендоры (Texas к примеру), у которых сборка только родными инструментами и возможна.
Понятное дело. Это также сделано, чтобы разработчики IDE (TI) во всю могли добавлять всяческие программные закладки, такие как слив Ваших исходников в здание с пятью углами, уделенное отключение и всё на что им только фантазии хватит.
Это чтобы Вас под контролем держать. На ошейнике.
Есть вендоры (Texas к примеру), у которых сборка только родными инструментами и возможна.
Да что вы говорите? https://habr.com/ru/articles/726352/
о в тот момент, когда вы захотите сделать что-то сложнее Hello World и начнёте использовать NDK, IPC и прочие библиотеки для работы с этими процессорами, вам потребуется великий и ужасный Code Composer Studio. Отладчик опять же у них работает только в нем.
Так говорят только те, кто не понимает какой путь проходит Cи-код с момента написания до исполнения внутри МК.
Остальные могут написать скрипт сборки для любого кода.
Как по мне, так формат makefiles это абсолютнейший, лютейший бред (также как и bash, и то и другое - продукты одного исторического периода). Как можно вообще с этим ископаемым форматом комфортно работать? Почему нельзя сделать все структурированно, в xml или json. У каждого проекта есть корень, в нем указывается имя проекта, далее могут быть секции с конфигурациями, секции со списками файлов, у каждой секции опять же должно быть имя в корне и структурированное содержимое. Каждая конфигурация должна содержать внутренние секции, отвечающие за разные группы опций компиляции. Если нужны разные компиляторы и прочие инструменты - тоже можно придумать соответствующий тип секции, с явным указанием что это "инструмент сборки" и именем. То есть, формат должен быть такой, чтобы его можно было максимально прозрачно отобразить на GUI окно настроек проекта.
Как по мне, так формат makefiles это абсолютнейший, лютейший бред
В далёкие времена, когда компьютеры были большие, автор запилил себе программу с таким вот странным форматом, с табуляциями. Народу понравилось.
Почему нельзя сделать все структурированно, в xml или json.
Не нужно. Это машинные форматы, кодированные в текст. Для человеков есть 100500 других систем управления сборкой. scons, cmake, ninja.. Некоторые IDE их понимают.
Собственно и была целая эра сборщиков декларативных на xml и json. ANT, ms build, xbuild, maven, ... Имя им легион - неудобно, многословно, проблемы с порядком выполнения, уйма тайного знания. Любой кто на этом строит сборки рано или поздно понимает, что даже динозавры типа make удобнее в части управления задачами. Собственно дьявол во всяких плагинах, например в части ракетных менеджеров. Но где этот вопрос решён нормальными консольными командами или прямо встроено в тулчейн опять же проблемы с мейком нет. Как краевед говорю, который 15 лет евангелировал ms build, затем maven и большие проекты с кастомными плагинами на грэдле собирал.
Так вот yaml лучше xml и json, процедурное типа градла лучше декларативного типа мавена, мейк и баш вообще всего лучше решают всё в лоб и по простому и где есть возможность действительно проще быстрее и понятнее сделать на них
Смешно. make, вообще-то, на десятилетия старше и XML, и, тем более, JSON. Почему же его авторы не использовали эти форматы? Вот что-то даже не знаю...
А как авторы make могли использовать то чего нет. Я вам раскрою может секрет, но xml и json не популярны не только в девопс, но и в обработке данных, так как избыточные и не поточные, там царствуют добрые старые csv и прочие такие форматы.
Xml и json это форматы для сериализации древовидных структур с сохранением (особенно xml) метаданных. Зачем это всё в make, который является сборочным скриптом?
Вам то чем они так милы. Целое десятилетие было царствование xml, wsdl soap и всё такое, осталось только в мире легаси и кровавых межведомственных систем. Потом типа rest, json это наше всё... Ну и что по сути сейчас наметился возврат к классическим бинарным форматам но там с блэкджеком и прочим, типа протобафа. Json же смещается в более нишевое использование. Форматы, тренды, приходят и уходит. А бессмертная классика типа мейков и башей остаётся независимо от степени мощности своего синтаксиса. Причина одна они чётко знают свою работу и хорошо её делают)))
Как по мне, так формат makefiles это абсолютнейший, лютейший бред
Раз Вы @NeoCode не можете осилить скрипты сборки, то могу лишь предложить Вам программировать на языке microblocks
https://wiki.microblocks.fun/en/ide
Там зайка подсказки дает. Удачи!
Как по мне, так формат makefiles это абсолютнейший, лютейший бред (также как и bash, и то и другое - продукты одного исторического периода). Как можно вообще с этим ископаемым форматом комфортно работать?
Да, написание make скриптов требует некоторого образования и сноровки, но это плата за масштабирование, автосборки, единообразие, наследование конфигов и модульность репозитория. Усилия инвестированные в изучение make окупаются сторицей!
Благодаря скриптам можно автоматизировать не только сборку кода, но и аж сам процесс загрузки прошивки в чип Обновление Прошивки из Make Скрипта
https://habr.com/ru/articles/857416/
О как!
Фигня какая то - сначала придумаем недостатки IDE, а потом начнем их побеждать.
IDE монолитные и неделимые. Если вы захотите поменять препроцессор, компилятор или компоновщик, а остальные фазы ToolChain(а) оставить как есть, то ничего из этого не выйдет, так как капот IDE закрыт на замок.
О как, а мужики по не знают ...
IDE стоят дорого, порядка 3500 EUR на один компьютер.
Мы в одной вселенной живем?
IDE(шные) xml очень слабо документированы или не документированы вовсе. У всех вендоров xml имеет свой особенный язык разметки.
А что, все должны иметь один стандарт разметки? Да, документированы не очень, но Вам точно нужно лезть под капот, если все работает правильно?
Затруднена сборка из консоли.
А никто и не обещал такое, хотя многие IDE позволяют сделать make файл и дальше делайте с ним , что хотите.
Обратная несовместимость с новыми версиями IDE
То есть при использовании make можно код с фичами C++17 скомпилировать под C++11 компилятором - честно говоря не знал о подобных возможностях, Вы открыли мне глаза.
IDE стоят дорого, порядка 3500 EUR на один компьютер. Мы в одной вселенной живем?
Вот что мне писали дилеры, продающие IDE IAR
Фигня какая то - сначала придумаем недостатки IDE, а потом начнем их побеждать.
Крайне рекомендую Вам посмотреть этот вебинар
CI/CD прошивок для микроконтроллеров в Wiren Board ( начало на 25:20)
и этот
Конвеерум #30: Эволюция рабочего окружения для embedded разработки
Фигня какая то - сначала придумаем недостатки IDE, а потом начнем их побеждать.
Сборка прошивок GUI-IDE плагинами, а также из-под Keil, IAR ССS - это признак Junior разработчика.
А сборка из скриптов - это фундаментальная технология, которая по плечу только программистам с качественным опытом.
Фигня какая то - сначала придумаем недостатки IDE, а потом начнем их побеждать
Если проводить аналогии с атомной энергетикой то, сборка через GUI-IDE - это как реакторы на горизонтальных ТВЭЛах (сборках), а сборка из скриптов это реактор на вертикальных ТВЭЛах.
Горизонтальные реакторы неудобны, так как надо минимум две точки подвеса ТВЭЛа при загрузке топлива. Плюс нужны дополнительные усилия, чтобы проталкивать стержни в активную зону. Потом стержень может расплавиться и застрять. Тогда жди беды.
Напротив, вертикальные ТВЭЛы загружаются под действие силы тяжести и для транспортировки сборки нужна только одна точка подвеса. Расплавленные ТВЭЛы просто стекают в поддон. Easy!
Фигня какая то - сначала придумаем недостатки IDE, а потом начнем их побеждать.
Почему в программировании микроконтроллеров, да еще и в России не особо прижились скриптовые системы сборки?
Ответ прост. Прошивки это маленькие программы. Бинарь 128kByte. Даже самая крупная прошивка собирается максимум за 3 мин.
Её всегда можно из-под IDE собрать кликнув мышкой на зелёный треугольник.
А системы сборки прежде всего изначально использовались в циклопических программных продуктах: BackEnd сайтов, DeskTop ПО, CAD системы, GameDev. Там *.exe бинари могут запросто быть по 2Gbyte. Да и компы в 1970....1990 слабые были. Один проект мог собираться три часа.
Естественно проектов много и собирают артефакты крупных проектов по ночам, пока программисты спят. Собирают автоматически дергая скрипты сборки.
Вот в этом тексте есть более развёрнутый ответ на Ваш вопрос.
Почему Сборка с Помощью Есlipse ARM GCC Плагинов это Тупиковый Путь
https://habr.com/ru/articles/794206/
Сборку из скриптов уже оценил ряд серьезных и успешных российских организаций. Вот, например, Whoosh написал даже текст про свой опыт настройки DevOps: Сборка и отладка прошивки IoT-модуля: Python, make, апельсины и чёрная магия. Ещё Wiren Board выступали на конференции с докладом CI/CD прошивок для микроконтроллеров в Wiren Board.
Я знаю и другие компании, которые пользуются этой фундаментальной технологией, но пока не пишут про это сообществах.
Собирать код из-под GUI-IDE (IAR KEIL) и из-под скриптов (Make/CMake) - это как писать учебники в Microsoft Word или на языке разметки LaTex.
Понятное дело, что выгода LaTex появляется, когда кода становится больше чем 3 экрана текста.
Апологеты GUI-IDE (IAR, KEIL) сложнее Hello World в своей жизни ничего не писали поэтому и топят за GUI-IDE.
Скрипты сборки GNU make (или СMake) хороши тем, что в скриптах сборки вы всегда можете написать текстовые комментарии.
Вы можете рядом с каждым ключом компилятора или опцией компоновщика явно указать себе и коллегам подсказку , что это значит и для чего нужно.
Понимаете?..
Одновременно с этим в GUI-IDE нет возможности в GUI форме указать в сombo-box-e, что значит тот или иной ключ GCC .
И это делает *.xml конфиг абсолютно нечитаемым.
В программировании микроконтроллеров нет царских путей!
Если одно вы сделали просто, то в другом будет тяжко.
И наоборот.
Закон сохранения сложности.
del
Фигня какая то - сначала придумаем недостатки IDE, а потом начнем их побеждать.
Обычно при коллективной разработке прошивок общий процесс и инструментарий подстраивается под самого слабого разработчика.
Условно в компаниях, где есть коллективная разработка за стандарт банально выбирают eclipse с gcc плагинами или iar или keil.
Поэтому коллективная разработка не сулит никакого профессионального развития.
Фигня какая то - сначала придумаем недостатки IDE, а потом начнем их побеждать.
Программировать в GUI-IDE (типа IAR, Keil ) это как ездить на трёхколесном велосипеде.
Вы собираете код с помощью СMake?
Я понимаю, что есть cmake --build, но строго говоря вызовы компилятора и линкера делает не cmake, а " a native build tool ". То есть, если было cmake -G Ninja , то сборка всё-таки с помощью ninja.
Тут небольшая путаница в терминологии: Cmake - это способ управления компилятором. IDE (integrated development environment) - это интегрированная среда разработки, куда помимо инструментов управления компилятором, входят другие полезные вещи, вроде отладчика, терминалов, инструментов работы с репозиториями и т.п.
Я вообще не представляю, как без помощи IDE производить отладку программы?
И да, если мы говорим про Embedded, то Eclipse (и IDE на нём базирующиеся, наподобие STM Cube IDE, ESP-IDF), VSCode + PlatformIO - бесплатны. Очень хороший инструмент VisualGDB для Embedded систем стоит 100 долларов в год (https://visualgdb.com/buy/).
Я вообще не представляю, как без помощи IDE производить отладку программы?
Тут есть 4+ ответа:
1--> Использовать связку GDBClient + GDBServer и отлаживать код из командной строки.
https://habr.com/ru/post/694708/
2--> Отлаживать код через интерфейс командной строки CLI поверх UART.
https://habr.com/ru/post/694408/
3--> В коем-то веке покрывать код модульными тестами
https://habr.com/ru/post/698092/
4--> Использовать другие косвенные признаки отладки кода: HeartBeat LED, Утилита arm-none-eabi-addr2line.exe, Assert(ы), DAC, STMStudio, Health Monitor
https://habr.com/ru/post/681280/
CMake или GNU Make?
Если вы никогда не писали никаких скриптов сборки, то сразу кидаться писать CMake пожалуй нет резона.
Дело в том, что CMake это даже не система сборки, а надстройка над всеми возможными системами сборки: Ninja, Make и проч. СMake в зависимости от опций командной строки сам генерирует скрипты сборки.
И вам будет с непривычки очень сложно разобраться с огромным калейдоскопом разнообразных новых для себя расширений файлов: *.сmake, СMakeList.txt. *.c.in *.mk и прочие. CMake очень избыточная система.
Если у вас цель просто собирать код из скриптов для CI в Jenkins, то лучше остановиться на GNU Make. Тогда у вас в репозитории, фактически, будут только три типа файлов для версионного контроля: *.c *.h и *.mk файлы. Easy!
СMake же - это очень навороченная утилита и там много избыточного функционала. Много того, что вам никогда даже не пригодится. В случае выбора CMake вам, например, придется помимо ошибок компилятора чинить ещё ошибки отработки CMake скриптов, которые порой по логу даже понять трудно, просто cmake что-то не понравилось, а вы день с этим колупаетесь. Потом чинить ошибки GNU Make, потом чинить ошибки компилятора и наконец компоновщика.
CMake перед сборкой зачем-то занимается тестированием компилятора. Строит hello world проект. В результате долго отрабатывает скрипт. Да и сами скрипты сборки make которые генерирует CMake обычно очень грязно составлены. Да, они работают, но читать их человеку просто нереально.
Лучше, быстрее, лаконичнее и надежнее просто ликвидировать лишнюю стадию отработки CMake скриптов и просто самим писать причесанные скрипты сборки GNU Make.
С точки зрения DevOps результат будет тем же: сборка из скрипта. А раз так, то зачем платить больше?
Не надо слишком сильно увлекаться FrameWork(остроительством). FrameWork(остроительство) - это бесконечная дорога.
Cmake - это способ управления компилятором.
СMake (Сross-platform Make) был разработан для кросс-платформенности. Переводя на кухонный язык, это чтобы одну и ту же программу можно было собирать в разнообразных операционных системах Windows, Linux, MacOS, FreeBSD. Если же Вы все в своей организации работаете только в Windows 10, то вам CMake нужен как собаке бензобак. Да.. Именно так.. Вам много проще будет самим писать GNU Make скрипты, раз нужна только сборка по клику на *.bat файл.
Разработчики встраиваемых систем такие смешные. Очень быстро (особенно если писать на ассемблере для примитивных контроллеров x51, AVR, PIC) возникает ощущение всемогущности. Сам таким был.
Потом приходят маркетологи и просят написать под Cortex-A, свой блютуз-стек, с утилизацией многоядерности, прикрутить толстую внешнюю библиотеку, что-нибудь из мира Unix и это проезжает бульдозером по твоей самооценке. Выясняется, что твой любимый инструмент превращается в тыкву. Потому что он не может Cortex-A, RISC-V, MIPS, C++ - там странный кривой диалект, не может стырить толстую либу с гитхаба. А работа под отладчиком это для маленьких детей и большие пацаны так не пишут.
Итого, есть два сценария - первый, самый распространенный, вы продолжаете использовать свой любимый инструмент и отказываетесь от работ, которые вы не в состоянии выполнить.
Второй сценарий - вы просто используете то что используется в толстой внешней библиотеке которая вам необходима, и которую вы не напишете никогда, потому что она стоит сотен человеко-лет разработки.
Но самый зубастый сценарий - все писать под Линукс, без отладчика, с любой необходимой системой сборки: cmake, ninja, makefile, bazel... как со своей родной. Если действительно нужен отладчик, то лучший вариант gcc с платным плагином для Visual Studio. Вы сразу получите все возможности работы с С++ и удобный аппаратный отладчик.
это проезжает бульдозером по твоей самооценке. Выясняется, что твой любимый инструмент превращается в тыкву.
В программировании микроконтроллеров самооценка еще рушится при переходе на очередную RTOS.
В каждом проекте взяты за основу разные RTOS(ы).
Если вы senior в FreeRTOS с 10 годами опыта за плечами, то при переходе на TI-RTOS вы мгновенно превратитесь в Junior(а).
Если вы senior в TI-RTOS с 15 годами опыта за плечами, то при переходе на RTOS Zephyr вы мгновенно снова превратитесь в Junior(а).+ учите CMake, Ninja, KConfig и DeviceTree.
Затем та же история с RTEMS 5, Tizen, VxWorks, ThreadX и так далее?
Поэтому в программировании микроконтроллеров Senior может на следующий день стать Junior(ом) и это более чем нормальное явление.
В профессии программист MK развитие и экспертиза обнуляется каждые 2-3 года.
у меня картина мира следующая.
Чиновники США в 60х оплатили разработку новой операционной системы. Туда были приглашены реальные звезды, технологические компании и университеты. Это проект Multics. Проект провалился, так как сроки были нереальные. Но именно там были придумали сущности: файл, директория, файловая система...
На обломках возникла сильно кастрированная операционная система UNIX. (яндекс голосовой переводчик часто переводит это название как "евнух-кастрат" и это действительно одна из версий происхождения названия) Система получилась удачной и чиновники США стандартизируют ее как проект POSIX. Итак, человечество получило единый стандарт для того чтобы портировать приложения. Прямо сейчас POSIX-приложения можно портировать на Андроид, МакОС, игровые приставки, суперкомпьютеры, Линуксы, ФриБСД и так далее.
В этом мире все должно поставляться в исходниках.
Проекты make (autotools), cmake, ninja и так далее это просто решение этой задачи портирования.
Я думаю ваши проблемы от незнания Линукса. Вы пытаетесь заучивать рецепты. Хотя, если бы имели навыки и понимание, то ни одна из сущностей вашего перечисленного не казалось бы чем-то новым и удивительным.
Мне тоже казалось что Линукс это всего лишь подобие Винды. Нет. Расстояние от Линукса до Винды такое же как от Винды до пальцевого интерфейса Айфона (Андроида).
Линукс (UNIX) это долго и очень больно для изучения. Порог вхождения очень высокий.
Но с каждым шагом есть ощущение что вы возвращаетесь домой. Здесь Си, наконец-то, базовый родной язык. Но после преодоления порога уже ничего не шокирует. Ничего не вызывает раздражения и новые инструменты изучаются легко и естественно. И вы больше не джуниор.
Я думаю ваши проблемы от незнания Линукса.
Где linux с его POSIX, и где микроконтроллеры..
перечисленные автором проблемы: CMake, Ninja, KConfig, DeviceTree, Tizen, VxWorks и так далее это все из мира UNIX.
Где linux с его POSIX, и где микроконтроллеры.
Сейчас микроконтроллеры во всей пригожей Европе программируют из-под Zephyr Project. А там надо знать west, Yaml, Python, KConfig, DeviceTree, CMake и Ninja как отче наше.
https://zephyrproject.org/
Я думаю ваши проблемы от незнания Линукса.
В микроконтроллерах(МК) нет MMU, поэтому Linux на МК не запускают. На МК крутят разнообразные как снежинки RTOS(ы).
UNIX это эталонная реализация Машины Тьюринга поверх фоннеймановской архитектуры. И мы живем с этим много лет, пока не появится некий новый квантовый компьютер или биологическая вычислительная система для которых придется все проектировать заново.
То есть все ваши ОС являются проекциями базовой системы. Достаточно понять первичную чтобы разобраться.
DeviceTree - это такое "ардуино" для взрослых, общее описание оборудования. Придумали когда устали бороться с зоопарком железа. Сейчас используется везде, кроме x86.
KConfig - часть системы сборки ядра Линукс
VxWorks - POSIX система, те же яйца только в рилтайме
Tizen - снова Линукс.
Zephyr - опять распотрашенный Линукс. Весь инструментарий оттуда.
язык Си - бессмертный пока существует POSIX
С++, большинство прочих языков программирования долгое время существовали как надстройки над бэкендом Си и его стандартной библиотеки.
Все эти RTOS, как FreeRTOS содержат те же мьютексы и семафоры только в сильно кастрированном виде. Вернее чаще это голый планировщик задач.
ucLinux смотрит на вас с осуждением xD
Назовите хоть одну организацию, где бы в самом деле применяли ucLinux на микроконтроллерах.
@aabzel, я бы с радостью, но тут такое дело... К сожалению они мне не отчитываются о выборе ОС, RTOS и так далее.
Но у достаточно современных МК более чем достаточно для этого. Один из примеров, с которым я имел дело в свое время: Moxa UC-7101, там внутри ucLinux.
Соответственно, те кто используют вышеуказанное устройство - используют ucLinux, на микроконтроллере с ARM9 ядром
FreeRTOS не POSIX совместимый.
Для отладки консоль и только консоль. Обычно отладка нужна для капризных интерфейсов, работающих в реальном времени и фоном. Поэтому все что остается делать - складывать все переменные и регистры что могут понадобиться в массивы внутри прерываний, а потом считывать их консольным gdb. По другому заглючивший интерфейс отлаживать я хз как. ИМХО в остальных случаях отладка не нужна, т.к. какой нибудь алгоритм можно и тупо на компе погонять, проверить.
Для отладки консоль и только консоль.
Согласен. Нужен Debug CLI terminal over UART.
Все ARM Cortex-M давно уже по JTAG или сокращенному варианту его же (SWD). По нему же зашиваются, по нему же отлаживаются. У меня пока ручки до CC2640 Ti и ESP32 с Nordic NRF51 не дотянулись (их думаю через opencocd, swd over ftdi). Но вот STM32 давно уже по gbd через st-link utility по swd, причем под линуксом, в репозиториях уже все есть.
del
Почему важно собирать код из скриптов