Comments 39
Нелогично, вы выкинули RTOS, но добавили самодельный планировщик и несколько других пунктов, которые по своей сути представляются отдельными потоками.
Если не ориентировать эту базу на что-то типа 8/16/32 атмег, то, наверное, можно спокойно везде использовать FreeRTOS как основу.
С RTOS тянется слишком большой overhead.
Да и потом. Чтобы запустить RTOS вам как ни крути нужны CLK, PLL, TIMER, SYSTICK, NVIC и т п.
Зато, в свою очередь, задачи типа Heartbeat LED и другие не realtime задачи не требуют отдельных таймеров и прерываний, а работают как потоки RTOS просто в цикле засыпая на нужное время или ожидая сообщения в очереди.
Нелогично, вы выкинули RTOS, но добавили самодельный планировщик и несколько других пунктов, которые по своей сути представляются отдельными потоками.
Я имел в виду кооперативный планировщик. Не вытесняющий.
наверное, можно спокойно везде использовать FreeRTOS как основу.
Нельзя. Так как прошивку порой надо еще симулировать как процесс на PC.
Чтобы тестировать математику.
Как вы запустите FreeRTOS в консольном приложении?
Ось в современном embedded абсолютно необходима.
Ее осутствие говорит о том что система недоработана в плане масштабируемости, унифицированности и универсальности.
Поэтому некая "каноническая форма" никак не может быть без RTOS.
Без RTOS ни стек TСP/IP, ни Bluetooth, ни файловую систему ни что-то другое серьезное невозможно нормально интегрировать.
Все они так или иначе будут уворовывать ресурсы времени, которые без RTOS у них отобрать и поделить не получится.
Остальные пункты - вкусовщина.
Claude Opus за минуты может сделать инфраструктуру для компиляции хоть GNU хоть LLVM
И сорсы переделает под них.
Но реально на сегодня лучшие инструменты отладки имеют коммерческие тулсы типа IAR или Keil. Поэтому многие SDK от производителей чипов имеют варианты для IAR. И даже Zephyr уже имеет порт для IAR.
Сейчас писк моды - делать отладку через WEB интерфейс.
Поэтому "каноническая форма" должна обязательно иметь WEB сервер и хранилище WEB страниц. Потому что Claude Opus идеально генерит WEB интерфейс. С графиками, таблицами, формами, редакторами - всем чем хочешь.
Поэтому некая "каноническая форма" никак не может быть без RTOS. Без RTOS ни стек TСP/IP, ни Bluetooth, ни файловую систему ни что-то другое серьезное невозможно нормально интегрировать.
Вы сейчас действительно про Embedded приложения говорите ? Тогда понятно откуда у холодильников и СВЧ печей потребность в облачных сервисах. ;-)
И личный кабинет у электрической зубной щетки с BLE.
Да знаете ли, паровоз не ждёт пассажиров.
Не успели сделать IoT в своих девайсиках — сделают без вас.
И облака теперь тоже горячая тема.
Особенно убедительно, когда приплетают холодильники и всякое такое в духе представлений прошлого века. Надеюсь, облака для пылесосов и счётчиков уже не шокируют?
А так вообще-то речь шла об отладке.
Без RTOS , ни файловую систему невозможно нормально интегрировать.
Как же я тогда LittleFs без RTOS на китайском МК запустил?
https://habr.com/ru/articles/925372/
Но реально на сегодня лучшие инструменты отладки имеют коммерческие тулсы типа IAR или Keil.
Не согласен. IAR - это IDE для школоты.
Вот пояснительная записка про вред GUI-IDE-шек
https://habr.com/ru/articles/794206/
Ох сейчас Вас запинают за такое... но я Вас поддержу. Makefile и vi - наше всё! :)
Извините, но сразу видно, что для Вас это исключительно хобби и Вы никогда не писали чего-то серьезного, где необходимо обеспечивать функциональную безопасность (ISO 26262, IEC 61508, IEC 62304, DO-178C и др.) и сертифицироваться. Ладно, статический анализатор на MISRA/CERT/CWE можно прикрутить внешний. Но Вы ярко отгребете на этапе доказательства пригодности инструмента (Tool Qualification) с gcc, а потом еще что делать с LTS не будете знать. Называть сертифицированные промышленные инструменты "IDE для школоты" это, извините, показывает Ваш уровень далеко не в лучшем ключе.
Проблема IDE-IAR-в том, что все конфиги хранятся в xml подобном ewb файле.
В результате при создании отдельной похожей сборки происходит 100% дублирование конфигов (макросы препроцессора, пути к заголовочным файлам и индексация исходников). Всё копируется.
Это существенно препятствует масштабированию кодовой базы.
Для прототипирования единичных поделок IAR-идеальное решение.
Для DevOps IAR - беда и проблема.
IAR не позволяет наследовать конфиги. Понимаете?
У меня был случай, когда была одна Legacy IAR-IDE сборка 55-ю конфигурациями для разных клиентов.
Надо было для всех конфигураций написать ещё пару *.c файлов. Дак вот...
Код я написал за 3-4 часа. Однако у меня ушло две недели тупо на то, чтобы просто в каждую конфигурацию мышкой в IDE-IAR добавить папку, прописать пути к этой папке и добавить макросы в GUI IDE.
Вот так, господа…
В GNU Make это же делается одной строкой.
Вот и делайте выводы..
Сейчас писк моды - делать отладку через WEB интерфейс
Вот именно, что моды.
Мода приходит и уходит. Классика - остается.
Но реально на сегодня лучшие инструменты отладки имеют коммерческие тулсы типа IAR или Keil. Поэтому многие SDK от производителей чипов имеют варианты для IAR.
Любовь к IDE IAR/Keil - это типичный признак молодых начинающих программистов микроконтроллеров.
Те кто в теме собирают прошивки самостоятельно написанными CMake скриптами.
CMake на ура теперь конвертируются в IAR XML с помощью Claude.
Вообще никакой проблемы. И линкерные файлы с тем же успехом конвертирует.
Сейчас про скрипты писать - высасывать тему из пальца.
Я за час превел весь хостовый стек с CMake Espresiff на IAR.
И еще кучу хлама от туда выкинул.
Дебажу теперь его c C-Spy в хвост и в гриву. Юзаю всю мощ таймлайнов, ITM ивентов, live view , RTT monitor, tracing. Потому что Espresiff со своим GNU создал неимоверный шлак.
CLI - просто жалкий лепет зеленого джуниора, которого только что от ардуины оторвали.
CMake на ура теперь конвертируются в IAR XML с помощью Claude.
Обожаю, когда меня называют джуном. Чувствую себя снова молодым.
Почему бы Вам не написать на Habr заметку про это?
Название может быть таким:
"Сборка компилятором IAR через скрипты CMake".
Возраст здесь ни при чём.
Я видел пенсионеров, которые ради фана подсаживаются на архаичные практики — и это нормально.
Но не надо выдавать это за ноу-хау, чтобы получить признание.
Я вам так скажу.
Если вы работаете с 8–16-ногими микроконтроллерами, используйте чипы с no-code-фреймворком вроде MSP Zero Code Studio и оставьте свои скрипты в прошлом.
Если чипы более мощные, то RTT, SWD, USB — обязательно. И чтобы ОЗУ хватало для развёртывания веб-сервера. Тогда вы получите и скорость, и мощность отладки.
Чем быстрее отладочный вывод получает Claude, тем больше итераций в час он успевает сделать.
Боюсь, что Ваша ортодоксальная каноническая прошивка в наш православный MIK32 не влезет. Приходится ограничиваться минимумом: WTD, SysTick, UART и Heart Beat. :-)
PS: Вы забыли про режимы "сна".
Боюсь, что Ваша ортодоксальная каноническая прошивка в наш православный MIK32 не влезет.
Очень даже влезет.
Вот сборка
https://github.com/aabzel/trunk/tree/main/source/projects/start_mik32_v1_generic_gcc_m
NVRAM на EEPROMе сделал.
https://habr.com/ru/articles/815639/
Просто код исполнять надо из SPI-FI.
Просто код исполнять надо из SPI-FI.
Ну это совсем не спортивно. :)
Кстати, как Вы сообщаете компилятору чтобы он перенес строки текста в SPIFI ? Ничего лучше чем attribute ((used, section (".spifi.text"))) перед обьвлением переменной я пока не придумал.
Там надо сделать только одно изменение в ld файле для компоновщика.
И прошивка специально соберется для SPIFI.
Не нужны аттрибуты.
Поясню. В наших проектах используется оба вида памяти - EEPROM и SPIFI. По умлолчанию компилятор запихивает все строки в сегмент .rodata, который размещается в EEPROM (нам важно чтобы .rodata был именно в EEPROM). Как сказать компилятору, чтобы все строки уходили в сегмент .spifi.text или в .spifi.rodata которые размещаются в SPIFI ?
Боюсь, что Ваша ортодоксальная каноническая прошивка в наш православный MIK32 не влезет.
Вот пожалуйста,
Исчерпывающая инструкция про то, как запустить ОКФП на нашем MIK32
https://habr.com/ru/articles/854050/
Настройка ToolChain-а Cборки Прошивок для MIK32 (K1948BK018 + C + GCC + GNU Make + OpenOCD)
++Сорцы
https://github.com/aabzel/trunk/tree/main/source/projects/start_mik32_v1_generic_gcc_m
Более-менее согласен с содержанием, но по форме (т.е., архитектуре) есть вопросы :).
2--Сборка без RTOS.
Согласен для прошивок < 100KB. Для сложных приложений на > 1MB сложно поддерживать приложение на самописном планировщике, в том числе переносимость на экзотичные MCU.
3--В сборке присутствуют драйверы для следующих базовых фундаментальных аппаратных подсистем: Clock, MCO, PLL, NVIC, SysTick, GPIO, PINMUX, FLASH, TIMER, DMA, UART.
Здесь я бы разделил драйвера или точнее добавил бы пункт в "джентельменский набор": 3.1 стартап (инициализация PLL, Clock, MPU, RAM/Flash, переменные bss/data и т.д.) и 3.2 драйвера для приложения. Также, налиние Flash драйвера в приложении приведет к вопросам от аудиторов проекта.
4--В сборке присутствует HeartBeat LED.
Это можно сделать и через переодический опрос устройства по интерфейсу связи, тот же UART. То что LED мигает не означает что устройство полностью функционально.
11--Также следует сразу подготовить отдельную сборку загрузчика через UART-CLI.
У вас загрузчик и приложение в одной прошивке? (в моей интерпретации, прошивка это софт собранный как отдельный/самостоятельный исполняемый файл)
Ортодоксально Каноническая Прошивка (ОКФП)