Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

Command Interpreter

Posted by Matthew Kendall on February 15, 2012
I was very pleased recently to discover the Command Interpreter in Demo/Common/Utils. One often has to add some sort of command interface to products and having a standard framework to build from is a big time saver. I like the architecture of this one; it seems well thought-out.

Having used it I have a couple of suggestions and comments:

First, the semantics of the return value of xCmdIntProcessCommand surprised me. I was expecting the value to indicate "I did something" or "I did nothing", so one would use it thus:
while (xCmdIntProcessCommand(line, buf, size)) {
printf(pcCmdIntGetOutputBuffer());
}

Instead, the return value indicates whether there is anything further to do, hence:
do {
more = xCmdIntProcessCommand(line, buf, size);
printf(pcCmdIntGetOutputBuffer());
} while (more);

which seems less elegant.

Second, the pcCmdIntGetParameter() function is handy but I was surprised to see that when requesting parameter N I actually get a string that extends from the beginning of the Nth parameter all the way to the end of the line. I see that the pxParameterStringLength will tell me how many characters actually constitute the parameter. Interpreters I have used previously have had the tokeniser replace the delimiting characters in the command string with nulls, cutting the string in to chunks, so that when later fetching a particular parameter one gets a sub-string containing just that particular parameter. That seems a little more convenient.

Lastly, and somewhat trivially, the long, mixed-case filename CommandInterpreter.c does not really match the style of the other FreeRTOS filenames. Can I suggest cmdint.c (since CmdInt seems to be used as the "module prefix" for functions)?

Anyway, overall I'm very happy. Thanks for making this available.

RE: Command Interpreter

Posted by Richard on February 15, 2012
The command interpreter is hiding in the code, but not yet formally announced or documented (other than a news snippet to say it is there). It will be formally announced in a couple of weeks - and at the same time separated out of its current location to a separate download. It is now fully documented and has some example applications, and these will appear on the web site at the same time.

Thanks for your feedback points:

+ I can see the semantics may seem odd, to me they were ok and it didn't occur to me until you pointed it out. The idea is that you keep calling the function until there is nothing left to do - the concept being to minimise RAM usage - and the semantics work from that perspective. I will consider that.

+ The behaviour you are seeing for pcCmdIntGetParameter() is not what it should do, and not behaviour I have ever seen myself. The string should be tokenised in exactly the way you are saying. That relies on the string being in writable memory though, were you passing the string in RAM?

+ The file name has changed for the V1 release (the one in a couple of weeks), as have the names of the functions it defines. They are documented now. They won't change again after the formal release though.

Regards.

RE: Command Interpreter

Posted by Matthew Kendall on February 15, 2012
I am definitely seeing the behaviour I described for pcCmdIntGetParameter(). I register a command "foo" with 2 parameters. On the command line I enter "foo bar baz". The callback gets called. Within it I have p = pcCmdIntGetParameter(pcCommandString, 1, &len) and the result is that p is a pointer in to the original string, starting at the first 'b', i.e. *p is "bar baz\0". The space between the first and second params has not been replaced with a null. I see no code in xCmdIntProcessCommand() or pcCmdIntGetParameter() that would make such a substitution.

I am using the version of CommandInterpreter.c from the 7.10 distribution. Perhaps there has been a change since then?

RE: Command Interpreter

Posted by Richard on February 15, 2012
My apologies. It used to be done that the command was terminated, but to prevent the command string being altered as a side effect of calling the API function the API function was changed to instead return the length of the parameter string. You are quite correct.

I just checked one of the demos and it looks like this:

/* Obtain the name of the first parameter, and the length of its name. */
pcParameter1 = ( int8_t * ) FreeRTOS_CLIGetParameter( pcCommandString, uxFirstParameter, &xParameter1StringLength );

/* Terminate parameter string. */
pcParameter1[ xParameter1StringLength ] = 0x00;


This means the application terminates the string if it wants to, which was considered safer.

Sorry for the confusion.

Regards.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists