Home >

Using a Command Line Interpreter for developing and manufacturing embedded systems

Bandit Gangwere - Watch Now - Duration: 40:30

Using a Command Line Interpreter for developing and manufacturing embedded systems
Bandit Gangwere

A Command Line Interpreter (CLI) is a very useful tool for both development and system monitoring. Issues/topics include:

  • 1: What is a Command Line Interpreter (CLI)?2: Why and How to use CLIs in embedded systems.
  • 2a: Using a CLI for writing device drivers
  • 2b: Using a CLI in bare-metal systems
  • 2c: Using a CLI in RTOS systems.
  • 3. CLI Architecture
  • 4: Production testing with a CLI
  • 5: Using different input sources
  • 5a: Serial port
  • 5b: Ethernet socket
  • 5d: Scripts

By popular demand, here's a zip file for the Arduino CLI:
https://embeddedonlineconference.s3.amazonaws.com/eoc/files/arduino_cli_mega_9Apr22.zip

M↓ MARKDOWN HELP
italicssurround text with
*asterisks*
boldsurround text with
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with
`backticks`
strikethroughsurround text with
~~two tilde characters~~
quote
prefix with
>

lmano
Score: 0 | 2 months ago | no reply

Nice talk!, very affordable

Otzen
Score: 0 | 2 months ago | 1 reply

Nice talk.
Just wanted to add my comment, I am quite often using a CLI on embedded systems. But again I also fit in the "old fart" category you mention in anoter comment ;-)
My input here is that I ussually use a design where I have test modules, with commands and parameters so any command looks like.
module,command,arg1,arg2
And the modules almost always match a module in the HAL, so I have a test-module for the GPIO module, a testmodule for the eeprom module a.s.o.
This is always a really great help when developing those HAL modules, i can test the hell out of a singe module, not worrying if other modules work or is implemented (except the serial interface)
In some products the CLI can exsist in paralele with the normmal business layer, in other products I have to boot into a special testmode.

mr_banditSpeaker
Score: 0 | 2 months ago | no reply

Spot on!
Your command form seems better for scripts. Mine assumes input via a keyboard, so I use spaces as a delimiter. But - whatever works for you!
I also try to match a command set with the HAL.

MaxP
Score: 0 | 2 months ago | 1 reply

Hi Bandit Gangwere, thank you for your presentation. I used CLI in my projects (on RTOS) for a while now since I find it very simple and straightforward to expose new features in the firmware without requiring additional PC development to access them.
In my design, I use a different approach to the "repeat" requirements. My design leaves to the command the burden of implementing the repeat schema the reason is that not all commands benefit from repeating and you may want to update a parameter between the iterations (e.g. memory dump). Each command is composed of two functions - the entry function and an optional iterative function. These two function have the same return type - an enumeration that reports whether the command succeeded, failed, or requested to run the next iteration.
At each command iteration, the console loop does an iteration, in this way you have an option to kick the watchdog or perform other housekeepings, or just simply relinquish the CPU for a while for other tasks.

mr_banditSpeaker
Score: 0 | 2 months ago | no reply

Another CLI fan!
About repeat: You are correct that there are more than one way to do it. I included a couple of ways to do it.
Bottom line: It's a tool that you should modify as you need. There are more than one way, but the concept remains the same.

leandropg
Score: 0 | 2 months ago | 1 reply

Hi Bandit Gangwere... Is an amazing idea create a CLI instead of include only debug lines... The idea to automate the tests using the CLI is fantastic... Thanks for this idea... Is a game changer

mr_banditSpeaker
Score: 0 | 2 months ago | 1 reply

Thanks! I'm glad I expanded your knowledge and toolset!

leandropg
Score: 0 | 2 months ago | 1 reply

I complemented your CLI idea that use only development environment and disable it in production to avoid maintain an open door for security weakness on IoT projects

mr_banditSpeaker
Score: 0 | 2 months ago | no reply

Agree. It is a development tool. For most projects, I would not compile it in once the project is going to be released.

Stephane.Boucher
Score: 2 | 2 months ago | no reply

By popular demand, here's a Zip file of the Arduino CLI:
https://embeddedonlineconference.s3.amazonaws.com/eoc/files/arduino_cli_mega_9Apr22.zip

Thomas.Schaertel
Score: 1 | 2 months ago | 2 replies

Good talk! I use sometimes a more interpreter like approach for CLIs, but this is just impossible on small embedded system. I use it mainly in the field as a support companion. By the way, do you offer the source code for your sample Arduino CLI as a whole? Just for education purposes this would be very helpful. Thank you so much for your presentation!

Stephane.Boucher
Score: 1 | 2 months ago | no reply
mr_banditSpeaker
Score: 1 | 2 months ago | no reply

I passed along the CLI as a zip file. Feel free to use it for whatever you need. I am putting it into the public domain.
I have used my CLI on very small atmels/arduinos where I had to conditionally compile in commands.
Thanks for watching!

Daniel.Jasinski
Score: 1 | 2 months ago | 1 reply

Thanks for the talk!
I am also a big fan of providing a convenient way for interacting with the device - and the CLI is my best friend.
@Thomas.Schaertel - please take a look at this library:
https://github.com/marcinbor85/microshell
or if you would like a more AT+... approach:
https://github.com/marcinbor85/cAT

mr_banditSpeaker
Score: 0 | 2 months ago | no reply

Amen to the CLI as a best friend!!
The advantage is they are easy to scale and are a flexible tool.
Glad to see other CLI fans. Thanks!

Ilias.A
Score: 0 | 2 months ago | 1 reply

Thanks for the nice talk!
I also use CLIs in my projects, using my own bare-metal or RTOS systems. They help a lot during initial development or debugging later.
A started with a stripped down version on AVR where I needed low memory footprint. Code and some description is available in AVRILOS
I now use a more advanced CLI in 32-bit MCUs where I can probe all my devices (I2C, SDCard, FPGA etc). I liked the REP state implementation.

mr_banditSpeaker
Score: 0 | 2 months ago | no reply

Appreciate hearing from another CLI fan.
I have more sophisticated CLI's for the bigger systems, too. I just wanted to introduce the concept.

LeroyLe
Score: 0 | 2 months ago | 1 reply

Interesting presentation. Formalizing a CLI is not something I've run across in my embedded education adventure but definitely a useful addition to the toolbox.
Thanks

mr_banditSpeaker
Score: 0 | 2 months ago | 1 reply

I included the zip file for the CLI I demoed.
Play around with it. I have more sophisticated CLI's, but I wanted to introduce the concept to engineers who have only worked with and seen the Big Tools.

LeroyL
Score: 0 | 2 months ago | no reply

Thanks for passing along the zip file. I've based my usage off of another implementation. but thank you for the idea/inspiration. Already seeing benefits and passing along to some fellow developers.

Steve_Wheeler
Score: 0 | 2 months ago | 1 reply

I've done things similar to a CLI on small (8- and 16-bit) systems, although not quite as capable as what you present here. On a larger system, though, wouldn't it be better to use an embedded language such as Forth or Python? That would get you the benefits of of the CLI, with the added capability of being able to change the programming on the fly without having to rewrite/recompile/reload the on-board software.

mr_banditSpeaker
Score: 0 | 2 months ago | no reply

Tools need to scale to the size of the project/resources.
Yes, a bigger system could use Forth or Python. I am generally using small systems.
Good point!

CMiller
Score: 0 | 2 months ago | 1 reply

Nice talk, Bandit. I've been using flex/bison for 25 years on MCUs--still going strong.

mr_banditSpeaker
Score: 0 | 2 months ago | no reply

Thanks!
It seems CLI is an "old-fart" tool. The reason I gave the talk.

Erin RobotGrrl
Score: 0 | 2 months ago | 1 reply

This is likely a newbie question- How would you design a CLI parser to handle a floating point number as input if the microcontroller does not have a FPU? Specifically, how to go from the input chars to numbers in Q notation? See you at the Q&A!

Erin RobotGrrl
Score: 0 | 2 months ago | 1 reply

Trying to clarify this question a bit. Say for example you want to store 3.141 all as fixed point. The CMSIS DSP libraries have typedef int8_t q7_t;. Would the parser be something like store left of decimal point (3) as a uint8_t, then for the right of the decimal point, do a mathematical operation, and store it as a q7_t? Hope this makes sense, sorry if the question is confusing!

mr_banditSpeaker
Score: 1 | 2 months ago | no reply

I have used fix-point. The "trick" is to assume/enforce the number of fixed bits.
So: 3.141 Limit the number of bits to 3. Handle the cases like 3.1 3.14, 3.14159 - truncate them to 3 bits (or expand 3.1 to 3.100), then multiply the number by 1000.. Make sure you will never overflow the variables in all of the math (does no good to do a calculation, and you overflow in the middle). When you want to print the value, divide by 1000 for the mantissa, the rest is the exponent. . Take a look at https://www.bbc.co.uk/bitesize/guides/zthbgk7/revision/2#:~:text=The%20mantissa%20holds%20the%20detail,larger%20range%20of%20possible%20numbers for a good discussion. Hope that helps!

OUR SPONSORS