Comments 17
Часть описанного - прямо маст хэв: загрузчик, отдельный код для поддержки контроллеров, плат, чипов, скрипты сборки. Но есть и прям специфичное. Например, CLI держать на борту - это очень спорно, особенно если это cli можно собрать из той же кодовой базы и запускать на pc. Нет кнопок - не нужен код анти-дребезга. Make - прошлый век, лучше пользовать ninja-build, под него есть генераторы, тот же cmake уже давно в него умеет.
В целом, список - очень годный!
make хороший, надежный. Вся спека GNU Make это всего-навсего 224 страницы.
Пуговицы тоже давно изобрели дак и сейчас им пользуются (не магнитами какими-нибудь).
Вот чем ninja лучше make? Прошивки и так собираются быстро. Jenkins за ночь вообще всё соберет.
CMake и make может генерировать.
Просто make позволяет удобнее управлять модульностью. Makefile(лы) лучше вручную писать. Так они хоть будут лучше читаться.
Когда нет CMake - значит нет и ошибок сборки на этапе CMake.
Make - прошлый век, лучше пользовать ninja-build
написать make all быстрее, чем написать ninja all. Поэтому make удобнее. )
А почему вдруг загрузчик обязательно надо обновлять по 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 происходит.
Удивительно, что никто не призывает пользоваться DeviceTree для описания аппаратуры в микроконтроллерных прошивках, подобно тому, как это происходит при разработке для Embedded Linux.
Что Должно Быть в Каждом FirmWare Pепозитории