Matlab Coder - How to force generated code to keep Matlab functions prototypes

I generated the C code with Matlab Coder, but the generated code functions interfaces are not the same as the interfaces for appropriate Matlab functions, which I did not expect to happen. Typically if I pass a structure as an argument, but the function does not use all elements of the structure, the generated code passes each individual set of elements of the structure that is used in the function, rather than pointer to entire structure. The problems with that is that the number of input arguments to a C function becomes too big. Plus, more importantly, if the implementation of the function get changed, that number of used elements in the structure is different, the generated C interface changes too, which means that it is not possible keep stable interface. That is not acceptable.

I see that there are options to control the interface with Simulink Coder and Embedded Coder but I cannot find how is that possible with just Matlab Coder. I cannot see a problem for Matlab C Coder to respect simple C stile interface defined in Matlab language. There must be a way to simply control that?

[Ezra Stein]

Hi Dusko,

In general, any generated functions which are not explicitly specified as Entry Point functions will have an unstable interface. You should avoid relying on these non-Entry Point functions since their signature, names, or existance, could be affected by various codegen optimizations or perturbations in the original MATLAB code.

To ensure that a correct and stable interface is generated, you can instead specify the function as an Entry Point for codegen.

If you are instead observing an unstable signature on an entry point function, could please provide us with a small reproducible example which exhibits this issue?

[Dusko Vujadinovic]

Hi Ezra,

Thanks for your reply.

As far as I understood to specify the function as the Entry function for the code generation I need to write the "%#codegen" after the function prototype as explained here:

https://uk.mathworks.com/help/coder/ug/code-generation-for-more-than-one-entry-point-matlab-function.html

The rest of the instructions in the link, as far as I can see, are related to general code generation, which has not been a problem - I have generated plenty of the code so far that works well. However, I have a number of examples where it seems to me I do everything correctly but the C generated function prototype does not correspond to the matlab function prototype.

For example the Matlab function prototype below:

function [trackingLoopsState, updateTrackingLoopsFlag] =...

dynamicReconfigFsm(tickMillsecCnt, numOfTrackedChannels, trackingLoopsCommonParams, ...

acqResultsChannelList, trackingLoopsState, dynamicReconfig, updateTrackingLoopsFlag)%#codegen

gets generated following C code prototype:

extern void dynamicReconfigFsm(uint32_T tickMillsecCnt, uint32_T

numOfTrackedChannels, uint32_T c_trackingLoopsCommonParams_trackersUpda,

boolean_T c_trackingLoopsCommonParams_doCarrierAid, const AcqResultsChannel

b_acqResultsChannelList[32], TrackingLoopsChanState b_trackingLoopsState[8],

uint32_T dynamicReconfig_switchScheme_ms, uint32_T

dynamicReconfig_normalUpdatePeriod_ms, uint32_T

c_dynamicReconfig_switchToExtendUpdatePe, uint32_T

dynamicReconfig_extendedUpdatePeriod_ms, boolean_T *updateTrackingLoopsFlag);

This a common behaviour where instead of passing just pointer to the structure a number of members of the structure are passed instead making the interface too big and ugly. For example the dynamicReconfig structure is one of the structures where that problem is shown. The structure is defined as:

%#codegen

dynamicReconfig = struct('switchScheme_ms', uint32(0),...% we cannot use the loops until at least 2 ms has gone to have previous values of taps

'normalUpdatePeriod_ms', uint32(0),...

'switchToExtendUpdatePeriod_ms', uint32(0),...

'extendedUpdatePeriod_ms', uint32(0),...

'msToProcess', uint32(0)); %[ms]

coder.cstructname(dynamicReconfig, 'DynamicReconfig');

[Ezra Stein]

Hi Dusko,

Unfortunately, specifying the %#codegen pragma next to the function prototype in MATLAB is not enough to mark that function as an entry point for codegen. In order to mark a function as an entry point, you must explicitly pass it as an argument to the 'codegen' command. Each such argument to the codegen command should also have a corresponding '-args' argument which specifies the input types for that function.

For instance, to mark the functions 'foo' and 'bar' as entry points, you would need specify them in a codegen command such as:

>> codegen foo -args {0, 0} bar -args {ones(10,10)}

This indicates to MATLAB Coder that foo is an entry point accepting two doubles as input and bar is an entry point accepting a 10x10 matrix as input. All other functions which codegen discovers as a result of compiling foo and bar will not be considered entry points and may have unstable signatures.

In your case, the codegen command would need to pass dynamicReconfigFsm as an argument, for instance:

codegen dynamicReconfigFsm -args {0, 0, true, ones(32,1), ones(8,1), dynamicReconfig, true}

where 'dynamicReconfig' is an example struct value. The above line uses just an example set of arguments, your particular use case might require something different.

Let me know if passing dynamicReconfigFsm and specifying its arguments in the 'codegen' command helps stabalize the signature of the generated function.

-Ezra

[Dusko Vujadinovic]

Hi Ezra,

Thanks for the explanation.

However this approach, is not good enough for us, providing that I understood the proposal. It requires so much of manual work to do that we have to swallow the problem of "unstable signatures" and live with that for time being, but it is far from being ideal.

Can you imagine one execution thread with hundreds of files and normally even more functions. So the user has to specify each single function in the command line. Not only that. Each single element of the structures that are part of the function signature needs to be specified. That is the admin work beyond believe - do not mention the maintenance cost. Is my understanding correct?

Matlab derives the function argument types from the input script that calls the entry function, so on that way it works out the signature of each function that is called in the context of the entry function. Very nice and clever. But, from the other side, it seems, the Matlab requires from user to duplicate that information for each single function through the command line, or the Coder GUI, just for sake of respecting the Matlab function prototypes in process of the code generation.

Only a single input flag is required for Matlab Coder to do the job instead of that massive admin job. Even that should be the default behaviour unless some optimisation is enabled by the user. I cannot see the logic why Matlab Coder complicated the code generation process for itself - do not mention the user. Surely, it would have been easier to simply respect the user design, rather than have a number of options. Even if Matlab Code tries to optimise the code and as consequence it makes the unstable signatures, that does not seem doing well. Instead of passing the pointer to a structure it passes number of elements of the structure by value, which make the code slower definitely.

Is there any plan to resolve all of this? it looks not so massive effort is required.

The code generation has massive potential to speed up the development of DSP code. But the decision makers would accept that only if the original design is retained in the generated code as well. People look into the generated code - if it looks very different to the Matlab code and unreadable they do not want to use it. Making the signatures stables would be a massive step to change the culture in DSP code development process - but it is up to Matlab to make that step.

Sorry, if I did still did not understand this....

Thanks a lot for your time,

Dusko

[Ezra Stein]

Hi Dusko,

Thank you very much for this feedback. We have made an internal note of this use case and will consider supporting stable non-entry point signatures in the future.

I agree that the current workflow requires tedious data entry when specify many entry point functions. One possible way to speed up this work is to use the 'coder.getArgTypes' function described below: https://www.mathworks.com/help/coder/ref/coder.getargtypes.html

This function uses the same technology behind the Coder App's "auto-define" feature to discover argument types for entry points invoked by a test script. For instance, suppose you have a set of entry points defined in a cell string:

>> myEntryPoints = {'fcn1', 'fcn2', 'fcn3', 'fcn4'};

You can then use 'coder.getArgTypes' to get a corresponding structure which represents the types of for each entry point signatures as discovered via a test bench:

>> typeStruct = coder.getArgTypes('myTestBench', myEntryPoints)

Next, you can construct the entry point arguments to the codegen command as follows:

>> args = cellfun(@(field) {field, '-args', typeStruct.(field)}, myEntryPoints, 'UniformOutput', false); args = [args{:}]

Finally, you can pass this directly to the codegen command:

>> codegen(args{:}, '-config', myConfig, '-report')

This should help you automate some of the work of specifying entry points by leveraging the entry-point arguments auto-define feature. Now, if you would like to make a function with a stable signature, you can simply add it to the myEntryPoints cell array.

I agree that it would be helpful if this workflow were simpler and we will consider improving it in the future.

-Ezra