Там хорошо работают ссылочные реализации, доступные для реализаций командной строки для встроенных систем?

Небольшую легкую вещь, которую можно использовать вперед. Его легко начать (четвертые ядра МАЛЕНЬКИЕ) посмотрите на figForth, LINa и GnuForth.

Отказ от ответственности: я не использую Forth, но openboot и шина PCI делают, и я использовал их, и они работают очень хорошо.

Альтернативный пользовательский интерфейс.

Вместо этого разверните веб-сервер на встроенном устройстве. Даже последовательный порт будет работать с SLIP, а пользовательский интерфейс может быть достаточно сложным (или даже обслуживать JAR и стать действительно очень сложным.

Если вам действительно нужен интерфейс командной строки, то вы можете указать ссылку и получить telnet.

One alternative is to use a very simple binary protocol to transfer the data you need, and then make a user interface on the PC, using e.g. Python or whatever is your favourite development tool.

The advantage is that it minimises the code in the embedded device, and shifts as much of it as possible to the PC side. That's good because:

• It uses up less embedded code space—much of the code is on the PC instead.
• In many cases it's easier to develop a given functionality on the PC, with the PC's greater tools and resources.
• It gives you more interface options. You can use just a command line interface if you want. Or, you could go for a GUI, with graphs, data logging, whatever fancy stuff you might want.
• It gives you flexibility. Embedded code is harder to upgrade than PC code. You can change and improve your PC-based tool whenever you want, without having to make any changes to the embedded device.

If you want to look at variables—If your PC tool is able to read the ELF file generated by the linker, then it can find out a variable's location from the symbol table. Even better, read the DWARF debug data and know the variable's type as well. Then all you need is a "read-memory" protocol message on the embedded device to get the data, and the PC does the decoding and displaying.

vxWorks включает командную оболочку, которая включает таблицу символов и реализует вычислитель выражений C, чтобы вы могли вызывать функции, оценивать выражения и получать доступ к глобальным символам во время выполнения. Оценщик выражений поддерживает целочисленные и строковые константы.

Когда я работал над проектом, который перешел с vxWorks на embOS, я реализовал ту же функциональность. Встраивание таблицы символов потребовало некоторой гимнастики, поскольку она не существует до момента связывания. Я использовал этап после сборки, чтобы проанализировать вывод инструмента GNU nm для создания таблицы символов как отдельного загрузочного модуля. В более ранней версии я вообще не встраивал таблицу символов, а скорее создал программу оболочки хоста, которая работала на хосте разработки, на котором находилась таблица символов, и взаимодействовал с отладочной заглушкой на целевой машине, которая могла выполнять вызовы функций по произвольным адресам и читать / писать произвольную память. Этот подход лучше подходит для устройств с ограничением памяти, но вы должны быть осторожны, чтобы таблица символов, которую вы используете, и код на целевой машине были для одной и той же сборки. Опять же, эту идею я позаимствовал у vxWorks, который поддерживает как целевую, так и основанную на хосте оболочку с одинаковой функциональностью. Для оболочки хоста vxWorks контрольные суммы - код для проверки соответствия таблицы символов; в моем случае это был ручной (и подверженный ошибкам) ​​процесс, поэтому я реализовал встроенную таблицу символов.

Хотя изначально я реализовал только чтение / запись в памяти и возможность вызова функций, позже я добавил оценщик выражений на основе алгоритма (но не код), описанный здесь . Затем после этого я добавил простые возможности создания сценариев в форме if-else, while и конструкций вызова процедур (с использованием очень простого синтаксиса, отличного от C). Поэтому, если вам нужна была новая функциональность или тестирование, вы могли либо написать новую функцию, либо создать сценарий (если производительность не была проблемой), чтобы функции были скорее «встроенными» в язык сценариев.

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

В других системах я реализовал интерпретатор потоков Forth, который является очень простым в реализации языком, но, возможно, имеет не очень удобный синтаксис. Вы также можете встроить существующее решение, такое как Lua или Ch.

У меня есть небольшой набор подпрограмм, который в основном состоит из 3 функций и таблицы поиска:

• функция, которая собирает данные из командной строки - это просто; нет истории командной строки или чего-то еще, только возможность вернуться на место или нажать escape, чтобы отбросить все. Но если бы я подумал, что нужны более изящные возможности редактирования, было бы несложно добавить их сюда.
• функция, которая анализирует строку текста в стиле argc / argv (см. Разобрать строку в argv / argc для некоторых идей по этому поводу)

• функция, которая принимает первый аргумент в проанализированной командной строке и ищет его в таблице команд и указателей на функции, чтобы определить, какую функцию вызывать для команды, поэтому обработчики команд просто должны соответствовать прототипу:

  int command_handler (int argc, char * argv []);

Затем эта функция вызывается с соответствующими параметрами argc / argv.

Фактически, таблица поиска также имеет указатели на основной текст справки для каждой команды, и если за командой следует '-?' или '/?' отображается этот фрагмент справочного текста. Кроме того, если для команды используется 'help', таблица команд выгружается (возможно только подмножество, если параметр передается команде 'help').

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

Для регистров и ОЗУ вы можете иметь подменю, которое просто выполняет дамп памяти по запросу.

Аналогичным образом, чтобы включить или отключить отдельные функции, вы можете управлять ими с помощью нажатия клавиш из главного меню или подменю.

Один из способов реализации этого - через простой конечный автомат. Каждый экран имеет соответствующее состояние, при котором ожидается нажатие клавиши, а затем изменяется состояние и / или обновляется экран по мере необходимости.

Вы можете проверить libcli. Она эмулирует CLI Cisco и, по-видимому, также включает в себя telnet-сервер. Это может быть больше, чем вы ищете, но все же может быть полезно в качестве справочной информации.