Pipe Size Limitations and Name Creation
JimKaidyNASA opened this issue · comments
I am inferring that the pipe names created in eci_interface.h are from concatenation of the Simulink bus name and the Simulink signal name. If this is the case, two modestly sized names are likely to be under the limit (16 characters?). If this is the case, I recommend using the signal name only to allow for name limits not to be violated, or, increase size limit (likely more difficult).
An example from eci_interface.h where GDN_CMD_MSG_GDN_CMD_MSG_SIG_MID appears to be a product of concatenated bus name gdn_cmd_msg and signal name gdn_cmd_msg_sig:
{ GDN_CMD_MSG_GDN_CMD_MSG_SIG_MID, &gdn_cmd_msg_sig, sizeof(gdn_cmd_msg), NULL,
NULL },
Jim,
The snippet you posted is the definition of a macro defining the message ID of your of your input or output message. That macro is handled by the compiler's pre-processor and the actual string you see there is replaced with the value defined by that macro before the code is compiled. So that can't be causing a length error.
Because that macro doesn't make it into the compiled code, there's no limit on the length of that identifier. The generated identifier is a little verbose (as you point out, it combines the bus name and signal object name) to guarantees uniqueness. I know that we can't just use the bus name (because there may be multiple packets which have the same structure, in which case it wouldn't be unique), but I'll have to check if just the signal name is sufficient for uniqueness. Thanks for the suggestion.
The pipe names are actually set by the SIL-generated macros ECI_CMD_PIPE_NAME and ECI_DATA_PIPE_NAME, which ECI uses to register the pipes within the CFE. The code which generates those macros can be found here.
As you can see, the format is:
"%<model_name_upper>_CMD_PIPE"
and
"%<model_name_upper>_DATA_PIPE"
From looking through the CFE codebase, it looks like the macro OS_MAX_API_NAME governs the size of pipe names (and other system resources). That's set in the OSAL. I don't know what OS you're running on, but for all of the OSAL's in the repo, it appears to be set to 20. It may be different if you're using a different/custom OSAL.
As long as your model name (excluding extension) is less than 10 characters, based on the format of the pipe name SIL is generating, you should not exceed a 20 character limit for either of those pipe names.
The reason the model name is prepended to those pipe names is because that name must be unique in the system you're running in. An easy way to do that is to prefix the app's name (which CFE requires to be unique), which is what the SIL does. Since app names are typically (in my experience) 2-3 characters, we've never yet run into a length issue.
@skliper Is the practice of naming apps with 2-3 character identifiers codified anywhere? Either in a code limitation or a best practices document? If best practices specify longer app names are allowed, then I'll be happy to look into what we can do to ensure the SIL facilitates that.
So then it isn't the length of the combined signal name and bus name. It is the name of the model that is breaking the 20 character limit when combined with the pipe names. Right now that name is Controller. If I shorten that to cnt, we should be good right?
If you name your model cnt, you should expect to see the SIL-generated eci_interface.h define the pipe names as CNT_CMD_PIPE and CNT_DATA_PIPE, which are 12 and 13 characters respectively. Those are under the 20 character limit present in all the public OSAL's, and so should work fine assuming you're using one of those. If not, you'll have to find the limit for your OSAL and adjust accordingly.
I am using the stock OSAL.
@skliper Is the practice of naming apps with 2-3 character identifiers codified anywhere? Either in a code limitation or a best practices document? If best practices specify longer app names are allowed, then I'll be happy to look into what we can do to ensure the SIL facilitates that.
Under "APP_" it specifies the application identifier is up to 5 characters, and the underscore is the 5th (so really up to 4 letters). CFDP_ and TIME_ are at the limit.
Sample_app is really the only place I know of that this guidance is broken.
@skliper Thanks!
@JimKaidyNASA Based on that, I don't plan to make any changes to the pipe names themselves, because they already support the recommended lengths (and then some). I do plan to look into if the signal name is sufficient to identify the output packet. If so, that might help shorten those macros, which will help readability (but otherwise has no effect on the code).