Как стать автором
Обновить

Комментарии 16

Часть описанного - прямо маст хэв: загрузчик, отдельный код для поддержки контроллеров, плат, чипов, скрипты сборки. Но есть и прям специфичное. Например, CLI держать на борту - это очень спорно, особенно если это cli можно собрать из той же кодовой базы и запускать на pc. Нет кнопок - не нужен код анти-дребезга. Make - прошлый век, лучше пользовать ninja-build, под него есть генераторы, тот же cmake уже давно в него умеет.

В целом, список - очень годный!

make хороший, надежный. Вся спека GNU Make это всего-навсего 224 страницы.

Пуговицы тоже давно изобрели дак и сейчас им пользуются (не магнитами какими-нибудь).

Вот чем ninja лучше make? Прошивки и так собираются быстро. Jenkins за ночь вообще всё соберет.

CMake и make может генерировать.

Просто make позволяет удобнее управлять модульностью. Makefile(лы) лучше вручную писать. Так они хоть будут лучше читаться.

Когда нет CMake - значит нет и ошибок сборки на этапе CMake.

Makefile(лы) лучше вручную писать. Так они хоть будут лучше читаться.

Если у вас сборка основана на CMake, то вам вообще не надо будет читать сгенеренные Makefile'ы (вот честно, мне за десяток лет ни разу не пришлось) - нужно будет читать только сами CMakeLists.txt.

Ну правда, уже очень давно в сколь-менее серьезных и сложных проектах мейкфайлы ручками не пишут, потому что это дико неудобно и неэффективно, особенно если у вас CI с большим количеством вариантов, или в прошивке много частей с разными внутренними зависимостями между ними (а менеджмент зависимостей на чистом make это боль). Шансов же ошибиться, описывая все ручками в чистых мейкфайлах гораздо больше, да и время разработчика слишком дорого, чтобы тратить его на это.

И даже начав делать все на чистом make, со временем вы рано или поздно обрастете костылями типа makedepend или запилите свой высокоуровневый велосипед. Как метко сказали на одном сайте: to be honest, a simple Makefile is very simple to write and efficient once you know the syntax fairly well. Then you add more and more things as the time pass, and it starts to morph into a giant huge monster that eats puppies.

А если вам по каким-то причинам не нравится CMake (он не идеален и есть вещи, за которые его авторам хочется оторвать руки), то стоит присмотреться, например к Meson, который вообще целиком и полностью нацеливается на гибкость и читаемость.

Make - прошлый век, лучше пользовать ninja-build

написать make all быстрее, чем написать ninja all. Поэтому make удобнее. )

Эти команды оьычно вызываются из IDE или из CI-пайплайна, так что разницы никакой :)

Во-первых, при прочих равных - ninja отработает быстрее, и когда счёт идёт на десятки секунд - не хочется ждать ни одной лишней. Во-вторых, при правильном скрипте - all писать не обязательно. В-третих, сделайте алиас на одну-две буквы и пишите ещё быстрее )

А почему вдруг загрузчик обязательно надо обновлять по UART?! Например по CAN он тоже отлично обновляется, и даже по, прости господи, USB

Проше UART интерфейсов нет. Всего пару регистров читать писать.
Драйверы CAN и тем более USB могут просто не поместиться в 32kByte On-Chip NorFlash памяти загрузчика.

32KB вам мало чтобы USB device сделать? Интересно как же я USB host запихнул в 16. А на счёт CAN так и вообще смешно, там сложность не сильно больше UART.

Ну а вообще у меня больше претензия к обязательности обновления по UART декларируемой в статье. Возьмите туже Tesla там все блоки обновляются только по CAN, а про UART большинство инженеров даже не знают.

Работали с одной OutSource компанией.
От них был загрузчик для STM32F413ZGJ6. 32kByte на весь загрузчик.
Писали они на С++ 17 в IAR. Все что им туда удалось утрамбовать это драйвер-SPI (на SPL), драйвер SPI-NOR FLASH для MX25L6433F и все.
Больше ничего не влезло.

CAN это замечательно. Вот только переходники с USB-CAN(12910 RUR) стоят дороже чем переходники с USB-UART (335 RUR) раз в 10...20

Зануда мод: UART требует делителя Частот, настройки скорости передачи, настройки наличия и количества старт/стоп битов, настройки проверки на четность, etc. SPI передает тактовый сигнал от мастера к слейву синхронно с данными, с опциональной адресацией слейвов по chip-select, а потому весь интерфейс SPI на слейве состоит из двух сдвиговых регистров и двух регистров буфферов для синхронизации с тактовой частотой контроллера. Самый простой драйвер UART всегда будет сложнее, чем самый простой драйвер SPI-slave.

Для CAN нужен чип физики.
В микроконтроллерах, как правило, есть только CAN-MAC.

Физика же UART всегда присутствует в микроконтроллерах.

Вот и получается что UART загрузчик будет работать всегда и везде.

CAN загрузчик будет работать только в платах, где есть чип CAN физики.

Мне кажется вы не поняли о чем я пишу. Моя главная мысль, что нет никакой обязательности иметь какой-то определенный протокол для обновления. Этот протокол всегда выбирается под конкретную задачу. Где-то UART зайдёт, а где-то без CAN никуда. Есть устройства где все взаимодействие только по USB происходит.

CAN,UART,USB это не протоколы.
CAN,UART,USB это всё интерфейсы.

Удивительно, что никто не призывает пользоваться DeviceTree для описания аппаратуры в микроконтроллерных прошивках, подобно тому, как это происходит при разработке для Embedded Linux.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.