Comments 47
В общем конкретно CLI — удобный протокол, но мне кажется важнее само наличие общей структуры проектов, соответствующего метода отладки, протокола общения с устройством и набора сопутствующих утилит. И такой есть, наверное, у всех embedded программистов которых я видел. Но у всех разный.
Эх, ну вот опять, декларируется обязательность UART CLI. Мы уже вроде обсуждали это в другом посте, но я повторюсь.
В той же Tesla S, около 200 ECU, и ни в одном из них нет UART, все делается только по CAN и совсем они там от этого не страдают. Model 3 и Supercharger тоже на CAN. UART в Supercharger прикрутил я в CCS версию т. к. нужно было TCP/IP отлаживать.
В своих проектах я всегда UART первым поднимаю, но индустрия в целом вполне обходится без него и без CLI.
По CAN сильно удобней работать если это много устройств как в автомобиле. Достаточно подключиться в одном месте к шине и можно отлаживать или обновлять прошивку на всех устройствах на этой шине. Ну вот как вы такой трюк с UART провернёте
Вы мешаете теплое с кислым. Как вам поможет CAN для отладки прошивки?
И то что UART не выводится в блоках Tesla совершенно не означает, что его нет блоках и он не использовался для отладке или тестировании блока при производстве. Ведь UART это не внешний интерфейс, каким является шина CAN.
CAN для отладки помогает отлично. Туда выводятся все нужные сигналы, записывают трейсы и анализируют их во времени. Мало того, это все делается ещё и удаленно, когда трейс отправляется на сервер и можно видеть все сигналы в онлайн. Это дело ещё и работает не просто на один блок а сразу на всю машину и на одном графике можно смотреть сигналы от разных блоков.
все делается только по CAN
В прошивке ECU после коммита сломался CAN. Нет CAN Link(а).
Ваши действия?
По CAN достаточно подключиться в одном месте к шине и можно отлаживать или обновлять прошивку на всех устройствах на этой шине. Ну вот как вы такой трюк с UART провернёте?
Легко, можно подключится ноде A к ее UART CLI и набрать shell команду проброса данных из UART в CAN (Data Forwarding) и этими командами по UART обновить прошивку на любой ноде подключенной к этой же CAN мети.
Сама нода ECU выступает как переходник UART<->CAN.
RS-485
Ладно. Допустим в Automotive привыкли отлаживаться по CAN. Там так административный ресурс приказал.
Но электроника не ограничивается только автомобильными ECU.
Вот Вам, например, домофон в котором вся конфигурация производится по UART-CLI
декларируется обязательность UART CLI.
Тут можно провести аналогию. У каждого микропроцессора есть система команд. Это список Assembler инструкций, которые может исполнять этот микропроцессор.
Аналогично и у электронной платы должна быть тоже своя система команд. То есть список действий которые может выполнять эти плата.
Вот такое простое рассуждение приводит к заключению, что у прошивки должна быть UART-CLI.
В своих проектах я всегда UART первым поднимаю
Еще очень важный момент. Если в прошивке визуально работает UART-CLI, то это автоматически означает, что правильно сконфигурировалось тактирование процессорного ядра и периферии, значит что включен контроллер прерываний NVIC, что работает GPIO и FIFO. Работающий CLI это отличный smoke test.
В своих проектах я всегда UART первым поднимаю
CLI в прошивке нужна для эмуляция прошивки как процесса на PC.
Если у вас в прошивке есть CLI, то вы можете собрать прошивку прямо на NetTop (x86).
Прошивку можно запустить на исполнение как Win консольное приложение в командой строке cmd.
Затем исполняя shell команды в stdin и наблюдая за цветным выводом в stdout вы можете отладить огромные куски кода, которым всё равно на архитектуру. Протестировать реализацию протоколов, математику, алокатор памяти, криптографию, компрессию/декомпрессию, fifo, lifo, циклический буфер, алгоритмы расчета контрольных сумм, шрифты графических экранчиков, триггер Шмитта, распознаватели строчек и многое-многое друге, что не зависит от архитектуры. Без CLI вы бы не смогли отлаживать микроконтроллерный кода на "большом компьютере".
Эх, ну вот опять, декларируется обязательность UART CLI.
CLI - это дополнительная ценность
Когда у Вас в прошивке есть CLI, любое ваше устройство помимо базового функционала превращается в супер калькулятор. Только вместо кнопок и клавиатуры UART.
Можно прямо в консоли TeraTerm попросить микроконтроллер расшифровать кусок Base64, RLE, AES256,вычислить SHA256, посчитать CRC16, решить задачку на поиск пересечения временных интервалов, определить точное количество дней между 2мя датами, вычислить расстояние между двумя GNSS координатами, найти угол между векторами, вычислить формулу и прочее и прочее.
Все эти программные компоненты как правило и так есть в 70% проектов на MCU
Когда есть CLI прошивка превращается в Swiss Army knife
все делается только по CAN и совсем они там от этого не страдают.
Структура CAN Payload(а) жестко регламентирована отраслевыми стандартами (например протоколы j1939/ CANopen). Поверх CAN просто так не воткнуть произвольный payload. Плюс в один пакет помещается только 8 байт. Работа с CAN требует работать с бинарной структурой пакетов. В этом смысле отладка по CAN связывает руки.
С другой стороны, CLI по UART ничем Вас не ограничивает. Можете посылать открытый текст в любом удобном для данной ситуации способом (например в ascii с поддержкой цветов в консоли). Читать вывод прямо глазами.
но индустрия в целом вполне обходится без него и без CLI.
CLI для экономии денег и времени
Если у Вас в электронной плате нет CLI, а только какой-то проприетарный бинарный протокол, то Вам надо тогда писать ещё утилиту переходник на PC чтобы подключиться к устройству.
А потом еще такую же утилиту для Win, Linux, Mac, Android, iOS, MS-DOS, OS/2, IBM POWER8 и БЭСМ-6.
Не проще ли просто реализовать текстовый UART-CLI протокол c раскраской логов, ASCI таблицами на уровне firmware и подключаться по любому терминалу последовательного порта (Putty/TeraTerm), которые и так есть для всех OS?
CLI избавит Вас от написания калейдоскопа ненужных no-name утилит-переходников под все известные платформы.
Ну сами посчитайте, откуда у СНГ(шной) электронной embedded конторы деньги на зарплату 250к RUR/мес для С#/Java программиста для написания какой-то одноразовой PC утилиты-переходинка?
Как вы по CAN прочитаете email разработчикив или дату сборки прошивки?
А вот cli это прямо в power up логе показывает.
Цена JTAG программаторов, кажется, вообще ничем не ограничена. Видел от 7kRUB до 5kEUR.
Вот прям сейчас посмотрел на али -- клон j-linkа стоит около 300 рублей (из дешёвых).
UART-CLI менее подвержен статическому электричеству в сравнении с SWD и JTAG.
Чото вообще не в тему. Если статикой вынести IO-ногу, то ни swd/jtag, ни uart с дохлым пином не заработают.
так как нужно всего 4 провода (Rx Tx GND VDD) вместо 20 проводов JTAG.
Можно обойтись тремя (без питания). В том числе и с SWD.
Можно передавать куски прошивки в формате base64 или просто hex в виде ASCII (получается base16).
А можно ещё Z-modem :)
Использую такую вещь в своих разработках, но с некоторыми отличиями - мк не отправляет обратно каждый введенный символ, а реагирует только на строку с /n. Работа с терминальными программами вроде putty в данном случае невозможна, зато возможен вывод информации в процессе ввода команды.
CLI это вообще универсальный протокол.CLI — это вообще-то Command Line Interface, а не протокол.
В недостатки я бы добавил пару пунктов:
CLI не нарушает timing(и) время исполнения программ протекает в естественном режиме.CLI нежелательно использовать для вывода значений переменных и прочей информации в runtime, поскольку на подпрограмму обработки UART тоже требуется время.
На форуме Electronix видел реальные случаи влияния на работу прошивки с UART-отладкой и без неё.
CLI и подпрограмма обработки занимает место, как в постоянной, так и в оперативной памяти МК.
В противоположность этому интерфейс JTAG/SWD реализован на уровне ядра МК и не требует дополнительного софта на нём.
Не против CLI, но поддерживаю комментаторов выше:
— вместо 20-pin разъема давно уже изобрели разъём c гораздо меньшим числом выводов
— вместо дорогого JTAG/SWD отладчика можно обойтись более дешевым
CLI — это вообще-то Command Line Interface, а не протокол.
CLI просто название неудачное. Всем же понятно, что CLI работает на прикладном уровне модели OSI так как взаимодействует непосредственно с человеком.
А Interface это как раз физический уровень модели OSI.
Когда говорят про интерфейсы, то подразумевают такие понятия как SPI, I2C, UART, CAN, LIN ,1-Wire, 100BASE-TX, I2S, JTAG , MDIO , RMII ,RS485 ,SDIO , USB.
Поэтому CLI -это прежде всего протокол. Причем такой который не нуждается в спецификации, так как в хорошей реализации CLI сам себя объясняет (TAB(ы), подсказки , автозаполнение) во время работы с ним.
Ещё раз, термин CLI всегда означал и продолжает означать окно терминала, т. е. интерфейс командной строки (Command Line Interface), а не протокол. Вы сами об этом пишете в первом же предложении статьи:
Есть такая классическая технология отладки Firmware как интерфейс командной строки поверх UART
Поэтому утверждение о том, что CLI является протоколом — технически некорректно. Я бы даже сказал, безграмотно.
Примеры протоколов: TCP/IP, HTTP.
Примеры интерфейсов: API, UI, CLI.
Так что CLI — это интерфейс. Потому что I = Interface, а P = Protocol.
И ещё, не забудьте поставить тире перед «это»: CLI это вообще универсальный
CLI не просто требует памяти, а еще и не везде влезет. Это занимает место в буферах и ROM. И вносит задержки.
Выглядит прикольно, но. Зачастую вместо него можно логи на одну TX ножку в debug сборке тащить, а RX не инициализировать. И настроить логгер который можно переключать при компиляции дефайнами: включать-выключать для модуля или уровень подробности менять.
Далее два подхода к тестам:
1) Модульные тесты, которые на железе пускаются с включенными логами и проверяются куски кода по сценариям. Тут можно наловить урожай достаточный чтобы дальше вручную не проверять много всего.
2) Интеграционные - собирать стенд, который умеет продёргивать ножки или по сети команды бросать и собирать логи. Цеплять такое можно к CI/CD (никто из команды не уронит код на мастере). Если макетировать на отладках, там уже часто есть board controller к которому в тестах можно цепляться по тому же CLI и ножки переключать. Сами тесты на каком-нибудь питоне можно писать наподключив кучу библиотек, которые умеют все что надо делать. И сами производители чипов для сетевых протоколов специфичных не редко дают библиотеки на питоне.
Второй подход дороже по времени, но позволяет тестировать и Debug и Release. При тестах дебаг сборки можно бонусом получить логи с железки в тест репорте и быстро продиагностировать.
Звучит как будто на тесты уйдет прилично времени. И да и нет. CLI написать тоже время - и каждый раз поддерживать, лечить при обновках. Тест написать один раз - и он будет автоматически проверяться каждый запуск. Не надо ничего каждый раз отлаживать вручную.
CLI только один раз понадобился в жизни чтобы сделать "нано утилиту" на один вечер.
Выглядит прикольно, но. Зачастую вместо него можно логи на одну TX ножку в debug сборке тащить, а RX не инициализировать. И настроить логгер который можно переключать при компиляции дефайнами: включать-выключать для модуля или уровень подробности менять.
Ну будет у Вас прошивка непрерывно флудить в UART и что хорошего?
Даже прочитать ничего не успеешь в этом ниагарском водопаде из белых логов.
Плюс процессор это будет тормозить.
А вот когда есть CLI, то прошивка не флудит, а только коротко отвечает, когда ее спрашиваешь по UART что-н.
Если прочитать мой комментарий и описанный подход, то "процессор не будет тормозить". В релизе ни cli ни логи не нужны. Только на этапе тестирования (и то не acceptance) и диагностики. А на счёт Ниагарского водопада - логировать надо то, что действительно нужно, а не каждый вызов функции и что попало.
Cli выглядит как ручной подход к отладке и тестам. Причем странным т.к. приёмочное тестирование должно осуществляться по сценариям использования с релизной конфигурацией железа и софта.
Если есть модульные и интеграционные тесты, CI/CD то CLI бесполезен.
Если есть модульные и интеграционные тесты, CI/CD то CLI бесполезен.
Модульные тесты как раз и вызываются через CLI как бы...
Или у Вас микроконтроллер от вибраций QFN корпуса распознает русскую речь?
Зачем CLI чтобы вызывать модульные тесты? О_о. Зашил и они сами запустились. Потом список прошедших и заваленных в логи капнут. Так можно в тест раннерее даже спокойно крутить написав мини bash скрипт который шьет все тесты в одном бинаре, вызывает ребут, забирает логи и руинит пайп если тесты не пройдены (простым grep-ом искать "All tests passed")
Когда есть CLI у Вас есть выбор. Либо запустить Debug(жную) сборку прошивки в штатном режиме и пользоваться ей. И она в этом случае отличается от релиза только бОльшим bin файлом.
Либо тут же прямо на Target устройстве прогнать конкретные модульные тесты (по имени или по номеру).
Либо прогнать все тесты сразу (30мин длиться).
Либо прогнать все тесты кроме конкретных .
и т. п.
Очень удобно, когда можно вызывать тесты из UART-CLI.
Ограниченная применимость CLI. Это, конечно, супер, что в конкретном проекте с мягкими условиями получилось использовать. Но:
1) Я всегда могу подключить программатор и одним тыком залить тесты и увидеть результаты прогона в логах. Даже могу по целям разным разложить и лить и запускать то одни, то все.
2) Не везде есть столько памяти чтобы и тесты и прошивку (масс прод всегда экономит деньги)
3) Всегда лучше когда тесты никто не запускает руками, а они сами запускаются на стенде когда коммит попадает в репозиторий (да, для этого кли не нужно, все автоматически через CI/CD делается).
Я Вам про автоматизацию и нормальные процессы, Вы мне про то как удобно подключить провода, прошить, открыть консоль и писать команду запуска)
В Израиле есть компания TechPack Lab, которая оказывает контрактные услуги по написанию firmware софтвера.
И одной из её услуг является запуск полноценного интерфейса командной строки внутри прошивок.
Смотрите, что получается.
Я пришел к выводу удобства CLI и при этом совершенно другие люди в другом государстве за несколько тысяч километров и через 2 моря (размером с несколько стран) независимо от меня тоже так решили. Значил CLI это действительно нужная вещь.
А те люди которые говорят, что CLI якобы не нужна они просто банально не понимают про что идет речь они CLI никогда не видели (это GUI поколение) и они просто не в теме.
Я пришел к выводу удобства CLI и при этом совершенно другие люди в другом государстве за несколько тысяч километров и через 2 моря (размером с несколько стран) независимо от меня тоже так решили. Значил CLI это действительно нужная вещь.
так себе аргумент.
миллионы людей на разных континентах занимаются уринотерапией, это не делает её нужной вещью.
Вот кодовая база Embox оказывается тоже по полной использует UART-CLI для микроконтроллеров
https://habr.com/ru/articles/777302/
Хорошие идеи не запретить.
Если вы знаете еще известные коммерческие встраиваемые системы с интерфейсом командной строки в serial порте (например маршрутизаторы Cisco), то пишете в комментариях.
Программируемые мини АТС, телефонные модемы (AT-команды), некоторые жёсткие диски (serial разъём рядом с SATA). Много чего, сразу не вспомнить.
Вот, например, прошивка рассчитывает ёмкость керамического конденсатора по его трехбуквенной маркировке. До использования CLI это была головная боль. Теперь - наслаждение.
Когда есть CLI прошивка превращается в Swiss Army Knife.
Почему Нам Нужен UART-Shell? (или Добавьте в Прошивку Гласность)