Forums » Software Development »
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
