Project

General

Profile

DSP HelloWorld Message Queue Buffer Length

Added by Doug Browning about 10 years ago

I'm modifying the DSP HelloWorld example code from the Wiki site to transfer data types other than strings (see SW Forum message "Data Transfer over DSPLink").

While debugging the transfer of an array of ints, I noticed that in the ARM source code file "arm_main.cpp" that the message length argument in the handleInboundMessage() function is not the same length as the message.

Original code:

int handleInboundMessage(void *apBuffer, uint16_t anLength, void *apUserArg) {
printf("ARM received a message from the DSP:\n");

// Print the message we received
printf("\tDSP Message = \"%s\"\n", (char *)apBuffer);
// Notify the main function that we have received a message from the DSP and are done
gbDone = true;
return 0;
}

With comparative printf's:

int handleInboundMessage(void *apBuffer, uint16_t anLength, void *apUserArg) {
printf("ARM received a message from the DSP:\n");

printf("Length of message = %d \n",anLength);
printf("strlen() = %d \n",strlen((char *)apBuffer));
// Print the message we received
printf("\tDSP Message = \"%s\"\n", (char *)apBuffer);
// Notify the main function that we have received a message from the DSP and are done
gbDone = true;
return 0;
}

When I run the project code, I get the following in the serial port terminal window:

ARM received a message from the DSP:
Length of message = 128
strlen() = 28
DSP Message = "DSP Initialization finished."

My question is "Should the anLength variable reflect the size of the data buffer in the message queue?"
The comment for the function in the source code indicates that it should:

/**
Handle inbound messages from the DSP.

\param apBuffer        Pointer to the buffer containing the message.
\param anLength       The length of the message.
\param apUserArg     User defined argument.
\return 0.

*/

Thanks,
Doug


Replies (2)

RE: DSP HelloWorld Message Queue Buffer Length - Added by Jonathan Cormier about 10 years ago

Doug,

As far as I understand the anLength is really the length of the buffer passed between the DSP and ARM and is likely going to be bigger than your actual message. I agree that the description of the parameter is misleading.

When creating a non string based message scheme it is common to use structs with a common header. Note that seq_no, majrev, minrev may not always be useful.
For example:

typedef struct
{
    uint8_t                         sig1;          // 2 byte identification
    uint8_t                         sig2;          // 
    uint8_t                         id;            // message ID
    uint8_t                         seq_no;        // sequence number
    uint8_t                         majrev;        // message revision
    uint8_t                         minrev;        // message revision
    uint16_t                        length;        // following bytes of data
} header_type;

typedef struct
{
    header_type                     header;         // length 4
    int32_t                         value;          // generic message type to pass integer
} tsIntValMsgType;

typedef struct
{
    header_type                     header;         // length 8
    uint32_t                        num_data;
    uint32_t *                      data_ptr;       // Pointer to shared memory. copied to ARM using tcDspApp::ReadMemory() call.
} tsData;

And have a union that combines all your message types for inital parsing.

union dsp_messages
{
    header_type                     header;

    tsIntValMsgType                 int_val_msg;

    tsData                          data_response;

    unsigned char                   data[MAX_MSG_LENGTH + sizeof(header_type)];
};

Then in your inbound message handler you can do something like.

    if (buffer != NULL && length != 0)
    {
        const dsp_messages *pmsg = (const dsp_messages*) buffer;

        // Check the message signature
        if (pmsg->header.sig1 != cnSig1 || pmsg->header.sig2 < cnSig2)
        {
            // PRINT ERROR MESSAGE
            goto inbounddone;
        }

        // Other data handling/verification

        // Switch on header.id and cast pmsg to the correct struct. And call a function that handles that particular message type.

RE: DSP HelloWorld Message Queue Buffer Length - Added by Doug Browning about 10 years ago

Thanks for the clarification on the message handler code, and the message structure recommendation.
It definitely will help me in crafting the ARM/DSP comms.
Regards,
Doug

    (1-2/2)
    Go to top
    Add picture from clipboard (Maximum size: 1 GB)