Home > On-Demand Archives > Workshops >
Building a Clean and Simple Command Line Interface in an RTOS Environment
Peifang Zhou - Watch Now - EOC 2024 - Duration: 01:28:27
It is a sequel to last year’s two presentations: Design Considerations for Serial Communications in an RTOS Environment and Building a Simple Command-Line Interface.
After blinking a LED and sending out “Hello, World” over a serial port, the next step in a typical embedded development is to build a command-line interface (CLI) to bring up other components and interfaces.
This workshop will demonstrate how to design a clean and simple CLI in an RTOS environment by partitioning functionalities and distributing them to functional blocks. The key insight is to view a console command as an immutable object and it flows through individual functional blocks. As a result of this streamlined design, simplicity is achieved by eliminating interactions between any non-neighboring blocks. In particular, there are three key ingredients in this simple CLI design:
- A terminal utility program (e.g., Termite) as a builder to assemble command objects. Once a command object is fully constructed, it will be sent out to a target board over a serial interface.
- The UART ISR as a de-serializer to reassemble the command object and notify a console task of the availability of such command object.
- The console task as a dispatcher to find a command handler and delegate the rest of command processing to a worker task.
The workshop will first present the architectural design of the proposed simple CLI interface and then walk through its implementation with live coding. A low-cost STM32 Nucleo board will be used to demonstrate how simple it is to implement each functional block with less than a dozen lines of C code. After the workshop, the participants will be able to apply this clean and simple CLI design to their real-world projects.
11:04:09 From Michael : i don't see the presentation. do others? 11:04:21 From Caio J. B. V. Guimaraes : I don't see it either 11:04:25 From Sudesh : yes me too 11:04:25 From Thomas Schaertel : Replying to "i don't see the pres..." No 11:04:40 From Caio J. B. V. Guimaraes : Indeed a black screen only 11:04:53 From Caio J. B. V. Guimaraes : Still a black screen 11:05:16 From BobF : Reminds me of the old CRT monitors with green phosphor! 11:05:19 From Caio J. B. V. Guimaraes : Now it is 11:05:24 From Caio J. B. V. Guimaraes : no problem! 11:08:12 From Jim.Mrowca : will the slides be available? They are not on the https://embeddedonlineconference.com/workshop/Building_a_Clean_and_Simple_Command_Line_Interface_in_an_RTOS_Environment webpage 11:30:55 From BobF : RGB phosphors working well, now! 11:35:11 From Ian Rasmussen : only the IDE 11:35:17 From tyhw : Reacted to "only the IDE" with 👍 11:35:41 From Ian Rasmussen : yes 11:36:31 From tyhw : Seems faster than 1s 12:09:39 From Davy Baker : Is there a simple way to convert this project to a different STM32 target ? 12:12:05 From Ian Rasmussen : Replying to "Is there a simple wa..." If by target you mean different board/chip, sometimes. In the chip/board configurator on the Pinout tab, there's the pinout dropdown and then there's the option for pinout compatible chips. This should automatically swap necessary HAL libraries. But if they're not pinout compatible boards then you'll need to do it by hand. 12:12:17 From Ian Rasmussen : Replying to "Is there a simple wa..." If that's not what you meant, then I'm not sure 12:12:22 From Manoj : Great presentation. Thank you! What is the size of the gCommandLine[]? Where will the code be uploaded? 12:16:06 From Ian Rasmussen : Replying to "Is there a simple wa..." Actually I partially walk my first statement back, sorry. That utility will just tell you if it's directly compatible or not, it won't change anything one way or the other. 12:18:23 From Manoj : Thank you! 12:18:49 From BobF : Is this CLI applicable for any type of RTOS, or are there constraints!? 12:19:02 From Shuo Dong : When console task is parsing the command line buffer, if user type in the next command very quick, ISR will update the command line buffer while console task is parsing the buffer, will this introduce a risk that console task can get corrupted command message? Maybe using double buffer, e.g. ISR update one buffer, console task parsing the other buffer? 12:26:20 From BobF : Referring to the 'Termite' stage, is there any compatibility issues when it comes to different 'KeyPress' / 'KeyRelease' interface mechanisms? 12:28:00 From BobF : Applicable low-level code ! 12:30:22 From Ian Rasmussen : Thanks! 12:30:23 From Lyden Smith : Thank you Peifang! 12:30:26 From Andrew MacIsaac : Thank you! 12:30:31 From BobF : Entertaining as usual, thanks! 12:30:34 From Eric : Thank you! 12:30:35 From Shuo Dong : Thank you! 12:30:38 From Davy Baker : Thank you.