为什么需要CLI
在开发过程中——从硬件原型到制造——有必要一遍又一遍地运行测试代码来验证功能或执行系统级测试。这通常可以通过单步执行调试器中的代码来完成，或者通过重复重新启动设备来导致某些事情发生。这是引起可能的启动/初始化延迟的一个缺点，需要使用调试器，并假设非开发人员(即制造商)将拥有必要的专门知识和工具。嵌入式系统需要一种简单的方法，通过开发和制造期间可用的简单接口重复运行命令。
该解决方案是一个命令行界面（CLI），它可以提供执行各种特性和功能的功能，而不需要调试器或软件专业知识。可以使用最方便的通信接口（如UART、USB、RTT或蓝牙）从CLI运行测试。
虽然可以编写自定义CLI，但有几种开源解决方案可用。我们决定在开始一个内部项目之前，先看看开源解决方案，看看它是否能完全满足我们的需求，或者只需最少的修改。实现此解决方案的第一步是查看可用的开源CLI解决方案并比较它们的功能。然后，我们可以确定一个标准解决方案，在我们的模板项目中实现，以供广泛使用。
基本CLI功能
- Echo – anything you type in is printed back to the screen so you can see what you’re doing.
- Backspace – Echo lets you see the mistake but supporting backspace lets you fix it.
- Help messages – a quick reference on what is available and how it works
Candidates
After researching online I found a handful of candidates to evaluate:
- Embedded-cli
https://github.com/FARLY7/embedded-cli - Memfault firmware shell
https://github.com/memfault/interrupt/tree/master/example/firmware-shell/complex/shell
https://interrupt.memfault.com/blog/firmware-shell - Anchor shell
https://github.com/rideskip/anchor/tree/master/console - LwSHELL
https://github.com/MaJerle/lwshell
https://docs.majerle.eu/projects/lwshell/en/latest/ - embedded-cli
https://github.com/funbiscuit/embedded-cli
对比
Ref
https://dojofive.com/blog/embedded-command-line-interfaces-and-why-you-need-them/