Application-Based CLI Uses Monitor CLI

Assume I have an application that wants to interface to the console port with its own CLI. The application has installed its own serial port drivers and uses its own interface to the user . However, I still want the application to be able to use some of the commands in the monitor. The application has application-specific commands, but the monitor still has a lot of useful facilities for software/hardware analysis and easy interface to the file system. Its very easy to extend the applications command set to include the monitors command set because the CLI processing of MicroMonitor can be accessed by one function ( docommand() ) and because the application can access docommand() through the monitor API function called mon_docommand() . So, the applications CLI can simply pass all unknown command strings (strings that do not parse into an application-specific command) to mon_docommand() for further processing by the monitors CLI.

In the CLI chapter, I pointed out that the monitor ignores (or strips off) a leading underscore from the incoming command string. Now, given the context of an application running on top of the monitor, I can better explain why this behavior is useful. It is very possible that there are duplicate command names in the application and monitor (The help command is a good example.). To access the monitors version of the command, the user precedes the command with an underscore. The applications command processor does not recognize the token; it is passed to mon_docommand() , and the underscore is stripped off. Thus, help is processed by the applications CLI, and _help is passed to the monitors CLI.

This case where the applications CLI falls through to the monitors CLI deserves closer inspection. The interface to the serial port that the monitor normally uses is now changed (because the application has most likely established a new serial driver). If a monitor command is called through the applications CLI, how can it print to the console? We can address this problem through a small modification to the putchar () function (see Listing 11.7).

Listing 11.7: putchar() .

 int putchar(int C) {     extern int  (*remoteputchar)();     int timeout;     if (remoteputchar) {         return(remoteputchar(C);     }     for(timeout=0;timeout<MAX_WAIT;timeout++) {         if (XMIT_HOLD_EMPTY())             break;     }     if (timeout == MAX_WAIT) {         ERROR();     }     STORE_XMIT_HOLD_REG((char)C);     return((int)C); } 

 

Now putchar() includes references to the remoteputchar() function pointer. If this pointer is non- NULL , then instead of using the monitor-specific code for interfacing to the serial port, some other remote function is used. The remote function pointer is assigned to the monitor through a mechanism similiar to that used to set up the mon_XXX functions. The only difference is that this function pointer is in monitor space instead of application space. The mon_com() function is a wrapper around the _moncom() function pointer used by monConnect() .

 #include "monlib.h" mon_com(CHARFUNC_PUTCHAR,appPutchar,0,0); 

This call tells the monitor to use the function appPutchar() instead of its own device interface. The function pointer remoteputchar (in monitor space) is loaded with the address of appPutchar() (in application space). Similar function replacements exist for a few other monitor device interfaces, and the logic is the same.