Built-in dispatch support with GUI Composer to send target-side events to event handler function?

Hi Gordon,

You are correct, JTag is a memory/register read and write model and you will need to watch for memory/register change on your target, and trigger the function in your firmware code. Where as for UART, you can write code on both host and target to handle your custom protocol.

May I ask what you are trying to do in your target side monitor handler? We are looking into exposing DSS script in future release. So when a button is clicked, it can execute a DSS script. Perhaps you might find this useful for your host application.

Regards,
Patrick 

Hi Patrick,

For my target side monitor handler, I would like to have a callback notification function which is linked to GUI Composer host-side events (e.g. OnButtonPressed).  It would be useful if the standard UART protocol on the target side (perhaps a monitor library that I link with my firmware app) supported a RPC remote procedure call mechanism for sending commands to the target (amongst other protocol features).  There is a feature for this in the real-time UART serial debug protocol for a similar product from a competitor (Freescale Freemaster). See AN4752 Freemaster Serial Driver App Note (http://bit.ly/17HmwRF) and the downloadable Freemaster communication driver protocol document and code examples ( http://bit.ly/14ZSxXs ). I just wanted something which is functionally similar but designed from scratch (i.e. no IP infringement).

The sort of support for registering a callback event handler on the target, and a typical event handler function for injecting a posted button press event to my finite state machine engine on the target would look as follows:

//------------------------------------------------------
// Function: 
//  RPC_RegisterAppCmdCall
//
//  Input:
//       nAppCmdCode - an application command code for which the callback is to be registered
//       pCallbackFunc - a pointer to a callback function which is to be registered. 
//                       Use NULL to un-register a callback previously with this application command.
//  Output:
//       none
//  Return Value:
//       This function returns non-zero value when the callback function was successfully registered or 
//       un-registered. It may return zero when you try to register a callback function for 
//       a nAppCmdCode which exceeds the maximum alloted number of application commands.
//
//  Notes:
//       This function can be used to register a given function as a callback handler for an application 
//       command. The application command is identified using the single-byte code. The callback function 
//       is invoked automatically by a target-side RPC (remote procedure call) driver
//       which uses a SCI UART protocol to receive commands from a DSS script on the GUI Composer host.
//       The prototype of the callback function is:
// 
//              RPC_APPCMD_RESULT rpc_HandlerFunction( RPC_APPCMD_CODE nAppcmd, RPC_APPCMD_PDATA pData, RPC_SIZE nDataLen);
//       where
//              nAppcmd - is the application command code
//              pData - points to application command data received (if any)
//              nDataLen - is the information about application command data length
//       The return value of the callback function is used as the application command result, and is returned to the host GUI composer
//       tool.
//       
//------------------------------------------------------

bool_t RPC_RegisterAppCmdCall( RPC_APPCMD_CODE nAppCmdCode, RPC_PAPPCMDFUNC pCallbackFunc)
{
}

//------------------------------------------------------
// Function: 
//  rpc_handleOnCmdRcvd
// 
// Purpose:
//  This function is registered as a application command handler.
//  It gets automatically invoked when the GUI Composer DSS script
//  on the host sends appropriate application command.
//
//  Input:
//       nAppCmdCode - an application command code identifying the command
//       pData - parameter which points to a block of variant data (command-specific)
//       nDataLen - length of the variant data block
//  Output:
//       none
//  Return Value:
//       RPC_APPCMD_RESULT eRetCode - result of command execution
//
//-------------------------------------------------------
RPC_APPCMD_RESULT rpc_handleOnCmdRcvd(RPC_APPCMD_CODE nAppcmd, RPC_APPCMD_PDATA pData, RPC_SIZE nDataLen)
{
    // Default return value (event handled OK) is used as the application command result code
    RPC_APPCMD_RESULT eRetCode = Q_HANDLED();
    ActiveObjEvent *pe;
    uint32_t *puiButtonIdParam;

    switch (nAppcmd)
    {
        case RPC_APPCMD_POST_BUTTON_PRESSED_SIG:                      // Handle request to post Button signal event to state machine 
            pe = Q_NEW(ActiveObjEvent, BUTTON_PRESSED_SIG);           // allocate Quantum Leaps QEP event
            puiButtonIdParam = (uint32_t *) pData;
            pe->Num = *puiButtonIdParam;
            QActive_postFIFO(AO_MyStateMachineActObj, (QEvent *)pe);  // Direct post event to active object event queue
            return eRetCode;
        case RPC_APPCMD_PWR_DOWN:
            break;
        case RPC_APPCMD_nnn:
        default:

        .

        .

        .
        break;

         
    }

    return eRetCode;    
}

I hope this provides an example of what I was looking for with respect to functionality on the target for command dispatch (without having to poll variables).  Incidentally, there is a similar open standard command dispatch functionality available in the ASAM CCP CAN Calibration Protocol (now called XCP eXtensible master-slave calibration protocol since it runs on SCI UART, CAN, or TCPIP transports).  See http://www.asam.net/nc/home/standards/standard-detail.html?tx_rbwbmasamstandards_pi1%5BshowUid%5D=519.

As an aside, it would be worthwhile to look at something similar to either Crosshairs COMMROS variables or Freemaster TSA target-side addressing variable descriptors as a mechanism for describing available variables on the target in a data dictionary which can be imported into a pallet of vars inside GUI Composer for selecting from a Binding dialog for widget variables.  For a UART style GUI composer app which does not use JTAG, the COFF debug symbol info is not available for a release build .out file, and it would be good to have an alternative mechanism for variable descriptors (data dictionary). 

Regards,

Gordon Finlay

Patrick,

P.S.  If you were to expose DSS scripting on the GUI Composer Host where I could associate DSS javascript handlers with GUI Composer OnClick or OnButtonUp events, that would be very useful. One thing I want to be able to do is to dynamically modify attributes of other GUI widgets as a result of a button press or a checkbox pressed. E.G. I would like to be able to make certain GUI widgets read-only or enabled / disabled (greyed out or not) in response to a checkbox (e.g. for (X) Enable Dianostic Mode).    I would also like to be able to dynamically modifywidget values as well as widget Minimum/Maximum limit attributes. I don't know if this would be possible with a DSS script.

Gordon

Hi Gordon,

GUI Composer doesn't have support to handle a generic RPC call like that one you have described. We did discuss this generic RPC model in the past, but no work has be done on it AFAIK.

There is a custom streaming model that you can use to do what you want. It provides a serial communication between host and target, you will need to write some javascript code and target code to process the RPC calls.

See this link for more detail. http://processors.wiki.ti.com/index.php/Streaming_GuiComposer

Regards,
Patrick