Home > Q&A Sessions >
Live Q&A - Using a Command Line Interpreter for developing and manufacturing embedded systems
Bandit Gangwere- Recording Soon Available
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.
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.
I hope you find this talk on Command Line Interpreter (CLI) illuminating on the uses of a CLI.
I was very happy to get comments from other CLI creators and users.
I encourage for you to get the code and start playing with it. There is a copy with the talk.
There is a bug I didn't fix. The first person to find it (it's really obvious) and reports it to me, I will give them the Arduino and the screw-terminal breakout board. Send email to tda@cruzio.com.
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.
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.
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
Thanks! I'm glad I expanded your knowledge and toolset!
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
Agree. It is a development tool. For most projects, I would not compile it in once the project is going to be released.
By popular demand, here's a Zip file of the Arduino CLI:
https://embeddedonlineconference.s3.amazonaws.com/eoc/files/arduino_cli_mega_9Apr22.zip
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!
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!
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
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!
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.
Appreciate hearing from another CLI fan.
I have more sophisticated CLI's for the bigger systems, too. I just wanted to introduce the concept.
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
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.
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.
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.
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!
Nice talk, Bandit. I've been using flex/bison for 25 years on MCUs--still going strong.
Thanks!
It seems CLI is an "old-fart" tool. The reason I gave the talk.
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!
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!
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!
Nice talk!, very affordable