Corviniol 10 янв 2015 в 00:03

Command line interpreter на микроконтроллере своими руками

4 мин

32K

Программирование микроконтроллеров *

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

grossws 10 янв 2015 в 01:37

Ожидал увидеть именно консоль/терминал, а оказалось, что просто реализация CLI.

Corviniol 10 янв 2015 в 08:54

После вашего комментария пошёл гуглить тонкости различия. Не могу сказать, что кристально ясно уловил их, но выделил одно:

Консоль контролирует всю видимую область, т.е. позволяет не только добавлять строку, но и перерисовывать экран целиком.
А Command Line Interpreter осуществляет только ввод-вывод текста, без последующего форматирования и заботы о перерисовке предыдущего.

Вы это имели в виду или что-то другое?

grossws 10 янв 2015 в 10:20

Консоль/терминал умеет управлять потоком. И является низкоуровневой частью взаимодействия с устройством.

CLI же — формат взаимодействия, в котором устройство/программа получает строковую команду и как-то на неё реагирует. Может пытаться управлять потоком (например выдавая cr без lf, чтобы показывать какой-нибудь progress-bar) посредством вывода управляющих последовательностей.

Простая реализация vt52-like терминала была в серии предновогодних статей год назад (http://habrahabr.ru/post/207136/, habrahabr.ru/post/206148/, habrahabr.ru/post/206692/, habrahabr.ru/post/206782/). Мой вариант — github.com/grossws/stm32-lcd/blob/master/term.c#L100.

abusalimov 10 янв 2015 в 14:09

Феерическаая расстановка точек: What is the exact difference between a 'terminal', a 'shell', a 'tty' and a 'console'?

В своё время помогла разобраться.

Elvish 10 янв 2015 в 09:16

Как-то сложно регистрируются команды…
У меня есть своя реализация более продвинутого «шела» для микроконтроллеров…
На С, минимально может работать на 100 байт памяти (можно уменьшить до 40 отрезав некоторые возможности). и немного стека (байт 20).
поддерживает неограниченное количество команд (сколько во флеш влезет),
есть автодополнение комманд, передача параметров для исполняемых функций.
типа того:
> plus 4 5
9
>
«шелл» может работать в условно-фоновом режиме (достаточно переодически вызывать обработчик шелла)
может и монопольно.
можно «вызывать» предыдущую команду с параметрами.
можно подключить как к UART, так и к другим каналам связи. (надо реализовать всего 3 функции putch(), getch(), kbhit())
краткая авто генерируемая справка по списку команд.
не зависит от стандартных библиотек
должна реализовываться на практически любом компиляторе и архитектуре. изначально затачивалась под 8 бит архитектуру.

один из минусов — это команды должны быть сведены в один константный массив
...{ «command1_name», function_obrabotka1 }, { «cmd2», func2 },…
другой минус — нельзя запустить несколько «шеллов» одновременно.

если есть высокая заинтересованность хабра-сообщества могу попытаться оформить это дело…

Corviniol 10 янв 2015 в 09:28

Для меня первый минус критичен — когда я разрабатываю новый функционал, я добавляю новые файлы. Там появляются новые команды.
Потом я могу решить в какую-то из сборок не включать часть функционала и в makefile закомментировать соотвествующие исходники.
А если сводить все команды в один массив, то придётся постоянно его редактировать. Либо делать автогенерацию этого массива в процессе сборки, но это ИМХО не легче чем мой способ.
А соль моего способа состоит в том, что я могу новые команды добавлять в любом файле просто макросом. Пример:

#include "commands.h" //здесь описан макрос REGISTER_COMMAND

REGISTER_COMMAND("command1_name", function_obrabotka1);
REGISTER_COMMAND("cmd2", func2);

А вот «продвинутость» вашего shell'a действительно интересна — я часто думал не сделать ли мне историю команд. Но каждый раз забивал, т.к. shell является не ключевой частью устройства, а скрытой от всех кроме разработчика отладочной фичей.

abusalimov 10 янв 2015 в 14:40

antonkozlov ниже уже упомянул Embox, хочу только подкинуть идею, как можно формировать константный массив из разных исходников. Под капотом у нас тоже используются секции компоновщика, но в исходниках массив представляется именно Си-шным массивом, а кроме того, один раз доработав линкер-скрипт, можно создавать и использовать сколько угодно разных массивов.

Определяем сам массив (один раз, например, в шелле):

ARRAY_SPREAD_DEF(const struct shell_cmd, __shell_cmds);

В каждом исходнике определяем структуру и заносим её в этот массив:

extern const struct shell_cmd __shell_cmds[];
ARRAY_SPREAD_ADD(__shell_cmds, {
        .name = "foo",
        .func = foo_func,
    });

Когда нужно проитерироваться по массиву, используем константу ARRAY_SPREAD_SIZE(__shell_cmds). Помимо этого, есть возможность определения NULL-терминированных (или не NULL-, а чем-нибудь другим терминированных) массивов, что тоже бывает удобно для итерирования.

Исходники в двух хедерах тут и тут, а линкер-скрипт вот:

SECTIONS {
	.rodata : {
		*(SORT(.array_spread.*.rodata))
	}
}

От билд-системы дополнительно ничего не требуется (ну, кроме добавления этого линкер-скрипта).

Corviniol 10 янв 2015 в 15:00

Спасибо! Особенно порадовала реализация ARRAY_SPREAD_SIZE.

но в исходниках массив представляется именно Си-шным массивом

А что вы здесь имели в виду? Что существует указатель по которому можно работать с распределённым массивом, как с обычным? Так это и у меня так.

Вообще создаётся впечатление, что мы идём параллельными, но разными путями.

abusalimov 10 янв 2015 в 15:35

Ну, да, что с точки зрения использования это обычный массив с типом

extern const struct shell_cmd __shell_cmds[];

Но это, конечно, более актуально в случае NULL-терминированных массивов указателей, где нам необязательно знать размер массива, и можно обойтись без ARRAY_SPREAD_SIZE.

Вообще создаётся впечатление, что мы идём параллельными, но разными путями.

Не без этого =)

Мы когда-то тоже использовали решение точь-в-точь как у вас. Проблема в том, что с добавлением каждой новой подсистемы (тесты, драйверы, файловые системы, обработчики протоколов сетевого стека, ...) каждый раз приходилось править линкер-скрипт. Поискал сейчас по проекту, нашел 30 разных массивов, определнных через ARRAY_SPREAD_DEF. Кроме того, мы используем эту технику под капотом своего фреймворка юнит-тестирования, чтобы определять новые тест-кейсы без явной регистрации: вот тут alexkalmuk разбирал это.

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

Corviniol 10 янв 2015 в 15:50

А разве const-данные не автоматически в секцию ro записываются? Я не уверен, но не казалось что в том и прелесть атрибута section, что он сложит все данные в одну секцию. И она ляжет в ro, если в ней есть только константные данные.
Генерация кода билд-системой бывает вполне мила (по опыту общения с DSP/BIOS от TI), но там свои косяки вылезают. Иногда мне очень хотелось подправить тамошнюю систему tconf (textual config).

abusalimov 10 янв 2015 в 15:56

Вы имеете в виду, зачем нужен const? Здесь он не обязателен, поскольку мы явно указываем секцию через атрибут, но это полезно для дополнительного контроля со стороны компилятора. А куда пойдет секция, определяется в линкер-скрипте, в нашем случае мы отправляем её в .rodata.

Corviniol 10 янв 2015 в 16:11

наоборот — зачем нужен линкер-скрипт, если мы уже указали квалификатор const? Разве gcc не автоматом складывает const в .rodata?

abusalimov 10 янв 2015 в 16:19

Просто const уложится в .rodata, да, но у нас-то (и у вас) ещё и атрибут section. И эти секции нужно уложить в правильном порядке: указатель на голову, потом элементы, потом терминирующий элемент, если есть, и указатель на конец. Для этого нужен SORT в *(SORT(.array_spread.*.rodata)).

Corviniol 10 янв 2015 в 16:54

А зачем вам указатель на голову и указатель на конец? У меня они автоматически генерируются линкером, и при этом не занимают места, потому что это просто символы линкера, а не байты в памяти. Это позволяет ещё чуть-чуть уменьшить overhead.
Для секции secname у меня линкер автоматом генерит что-то вроде:

SECTIONS {
    .rodata : {
         _start_secname = .;
         *(.secname)
         _stop_secname = .;
    }
}

Потом я эти символы объявляю как extern указатели и при линковке они автоматически подменяются на соответсвтующие адреса. Возможно что это свойcтво gcc-arm-embedded, но я беззазрительно им пользуюсь.

abusalimov 10 янв 2015 в 17:04

А, теперь понимаю, о чем вы. Да, скорее всего, это есть не во всех версиях binutils, с ходу так не могу сказать, почему мы это не использовали. Может, ещё и из-за необходимости NULL-терминированных массивов указателей.

и при этом не занимают места, потому что это просто символы линкера, а не байты в памяти. Это позволяет ещё чуть-чуть уменьшить overhead.

Указатели в нашем решении тоже не занимают байтов в памяти, это такие же символы, которые определяются через массивы нулевой длины.

antonkozlov 10 янв 2015 в 12:20

Наша ОС Embox начиналась как монитор для встраиваемых систем. С тех пор у нас есть очень похожий репозиторий команд, основанный на линкер секции.
Со временем мы решили перенести регистрацию команд из исходных файлов в файлы описания системы сборки (она, кстати, описывалась на хабре: habrahabr.ru/post/144935/). Туда же мы помещаем метаинформацию о командах: краткую справку и man. Получается как-то так: описание для системы сборки

@AutoCmd
@Cmd(name = "help", help = "Shows all available commands", man = '''...'''
module help {
        source "help.c"
        ...
}

А в help.c

int main(int argc, char **argv) {
        ...
}

Никакой высокой науки, но команды выглядят как обычные хостовые программы (точка вхождения — функция main), хотя внутри реализуются так же, как статье.

Для нас перечисленные в этой статье минусы не играли большой роли. Для разных архитектур используется gcc с единообразными линкер скриптами. Для тулчейнов других производителей линкер скрипт действительно может потребовать изменений, но они должны быть косметическими.

Конечно, вокруг команд есть много всего интересного: шеллы (управление задачами), терминал/консоль. Если сообществу интересно, как у нас это реализовано, то можно расписать подробнее.

Corviniol 10 янв 2015 в 13:14

А почему решили перенести? У вас это не порождает проблем с синхронизацией между исходниками и системой сборки? Опять же — изолированность изменений в системе контроля версий. Как-то не хочется добавив команду в один исходник изменять ещё скрипт сборки. Мне кажется что это захламляет changelog скрипта.

antonkozlov 10 янв 2015 в 14:42

Перенесли из-за желания сделать команды максимально стандартными, тем самым уменьшив порог вхождения. Как бонус, получили возможность собирать команды из нашей ОС на unix хостах (без изменений), наоборот — тоже получается достаточно хорошо.

При добавлении новой команды нужно сообщать системе сборки о новом файле. Описание лежит рядом с исходником, как например Cat.my и cat.c.
Отделение исходников от информации о межмодульных взаимодействиях является одной из основных фич проекта, с её помощью нам удается включать в целевой образ только необходимый программный код.
Конечно, расхождение возможно и случается. Это больше относится к другим типам описаний, чем к информации о командах, забыть изменить мануал можно и в текущем файле. Над автоматическим извлечением другой метаинформации мы работаем в следующей версии системы сборки. Пока же, проверка соответствия исходников их описанию не представляет больших неудобств.
Но в случае с командами деление даже полезно: справка в одном файле, исходник — в другом.

Corviniol 10 янв 2015 в 15:23

Перенесли из-за желания сделать команды максимально стандартными, тем самым уменьшив порог вхождения. Как бонус, получили возможность собирать команды из нашей ОС на unix хостах (без изменений), наоборот — тоже получается достаточно хорошо.

Это понятно. Но, как я понимаю, относится к сигнатуре обработчика команд, а не к способу регистрации команд.

При добавлении новой команды нужно сообщать системе сборки о новом файле. Описание лежит рядом с исходником, как например Cat.my и cat.c.

Вариант, если к каждому исходнику всё равно прилагается его описание для MyBuild. Иначе придётся плодить дополнительные файлы. Но даже в этом варианте добавление/удаление новой команды требует редактирования двух файлов.

забыть изменить мануал можно и в текущем файле

Можно, но если этот мануал у тебя идёт рядом с самой функцией, то глазами на него натыкаешься, когда код редактируешь. А вот если у тебя тело функции от мануала отстоит строк хотя бы на 30 — то легко забыть.

abusalimov 10 янв 2015 в 15:44

Перенесли из-за желания сделать команды максимально стандартными, тем самым уменьшив порог вхождения. Как бонус, получили возможность собирать команды из нашей ОС на unix хостах (без изменений), наоборот — тоже получается достаточно хорошо.
Это понятно. Но, как я понимаю, относится к сигнатуре обработчика команд, а не к способу регистрации команд.

В отдаленных планах, кстати, есть отказ и от этого. То есть команда неотличима от обычного приложения с функцией main, а при сборке глобальные символы (в т.ч. main) манглятся, и команда регистрируется «как обычно».

Но даже в этом варианте добавление/удаление новой команды требует редактирования двух файлов.

Для нас это что-то вроде неизбежного зла. Любой модуль так и так требует этих двух файлов, да и забыть поправить справку к команде не такая уж беда.

Corviniol 10 янв 2015 в 16:35

У меня пока проект на EFM32 с 32КБ RAM не разросся до таких высот как несколько приложений, поэтому реализовывать команду как приложение не получается =). Вот и изобрёл «на скорую руку» такой огрызок.
Второй момент — когда разработчиков в проекте мало, то затраты на собственную систему сборки/полноценную RTOS не окупаются. А вот быстрая регистрация команд (и такой же механизм для задач в OS) уже зарекомендовала себя, т.к. сильно ускорила разработку аппаратных «fork-ов» от исходной платы. Так из диктофона получились: стерео USB-микрофон, USB-адаптер для управления несколькими реле, переходник USB-I2C для отладки работы с новыми микросхемами, 8-ми канальная микрофонная решётка совместимая с USB-audio драйверами Windows и Linux. Возможно скоро и ещё что-нибудь получится.

abondarev 10 янв 2015 в 18:57

Странно, Вы же сами дали пример

REGISTER_COMMAND(«command1_name», function_obrabotka1);
REGISTER_COMMAND(«cmd2», func2);

то есть регистрируете две команды. Плюс описана функция поиска команды, Значит все таки несколько приложений или команд у Вас в проекта есть.
Второй момент тоже спорный, На мой взгляд, при маленькой команде стоит посмотреть на готовые RTOS, они на себя возьмут часть рутины и тем самым ускорят разработку. Хотя конечно свои велосипеды для конкретных случаев никто не отменял.:)

Еще вопрос, а все перечисленные устройства были сделаны на EFM32 c 32кБ RAM? Тогда мои поздравления это действительно круто! Просто у нас на EFM32 правда младших моделей (4кБ ОЗУ) только простенький shell крутиться.

Corviniol 10 янв 2015 в 19:20

У меня вся прошивка собирается в одно приложение, с кооперативной многозадачностью на манер co-routines из FreeRTOS. Поэтому я и сказал про «одно приложение». Это позволяет существенно экономить память.
Второй момент сложился исторически, из-за ошибки планирования на старте проекта. Изначально делали макет для оценки параметров MEMS-микрофонов с цифровым выходом. При этом лепили «из того что было» (EFM32LG), больше интересуясь не системными вещами, а поднятием драйверов переферии и замерами энергопотребления и качества звука.
А потом руководство сказало что надо срочно сделать из этого продающийся диктофон. Т.к. к этому моменту уже была сделана запись звука на NANDFLASH и вычитывание через USBCDC-драйвер, то пришлось срочно доделать, а не начинать разработку софта заново.
Но после самостоятельной реализации псевдомногозадачной RTOS с поддержкой композитного USB-устройства, описанным в данной статье CLI, механизмом событий для межзадачного взаимодействия, динамического изменения частоты MCU и т.д. я дал себе зарок в следующей подобной разработке использовать что-нибудь вроде FreeRTOS.

Про EFM32 c 32кБ — как показал опыт этого вполне достаточно, если все задачи используют один и тот же стек. Для экономии же памяти я отказался от динамического выделения. Вообще всё что можно я регистрирую с помощью линкера =). А что вы делаете на EFM32ZG, если не секрет?

abondarev 10 янв 2015 в 19:38

Да на FreeRTOS я и намекал:)

Не секрет, у нас есть знакомые из Северо-Восточного федерального университета. Они делали проект по автоматизации теплиц (сенсоры управление освещением и тд) и попросили портировать на EFM32 поскольку у нее очень хорошие показатели энергопотребления. Мы собственно это сделали, затащили BSP запустили shell и на этом пока остановились, сейчас в основном STM32 используем и там уже кучу всего сделали.

Corviniol 10 янв 2015 в 20:07

Вот и мы взяли EFM32 за энергопотребление. Но нам был критичен USB, поэтому используем LG. Ну и 4кБ RAM при работе с NANDFLASH со страницами 3кБ тоже были бы грустны :).

abondarev 10 янв 2015 в 19:05

Вариант, если к каждому исходнику всё равно прилагается его описание для MyBuild. Иначе придётся плодить дополнительные файлы. Но даже в этом варианте добавление/удаление новой команды требует редактирования двух файлов.

Тут ведь как, Вы когда добавляете команду тоже меняете два файла, один Си-шный второй Makefile и у нас тоже самое. Мы просто позволяем писать в своеобразный файл для сборки больше информации и она у нас в декларативном виде представлена.

Dreadatour 10 янв 2015 в 12:30

github.com/Helius/microrl

grossws 10 янв 2015 в 13:20

Спасибо, выглядит прилично. Легкая замена readline — это хорошо.

Hellitron 10 янв 2015 в 16:04

Вообще у меня есть cubiboard, а у нее вывод терминала в uart. Я контроллер цеплял к плате, а он с консолью общался. Но это было jast for fun. Логинился, писал Hello linux в файл и все.

HurrTheDurr 10 янв 2015 в 20:21

Не CLI, конечно, но я когда-то давно, по тем же причинам, написал скрипт на Python для генерации С-кода текстовых менюшек произвольной сложности.
Может, кому-то пригодится: github.com/sirgal/Easy-Console-Text-Menu-Generator

Corviniol 10 янв 2015 в 20:45

Интересно. Почитал результат работы вашего скрипта и имею к нему несколько вопросов:

Зачем там динамическое выделение памяти? Ведь все данные уже известны на момент генерации исходников.
Зачем там столько memcpy при создании меню? Можно ведь
```
memcpy( menu[0].welcome_string, "Hello! Welcome to the test menu.\n", string_lengths[0] );
```
заменить на
```
menu[0].welcome_string = "Hello! Welcome to the test menu.\n";
```
Или потом эти данные как-то изменяются?

Хотя вообще идея генерации исходных кодов мне нравится — она позволяет каждую часть проекта писать на том языке, который для этого лучше подходит. Ну и изобретать при этом свой язык, при необходимости.

HurrTheDurr 10 янв 2015 в 21:06

Так можно выгрузить все из памяти, когда меню уже не используется, что полезно, если оно запускается лишь раз в жизни устройства, при монтаже, или при редком сервисном доступе, после ребута. Год назад писалось, всех тонкостей уже не помню. Точно помню, что была идея сделать это на статической памяти, точно помню, что стало лень :)