How to define an Atomic subsystem(Nonreusable function) as static function in code generation in Embedded coder.
MATLAB: How to define an Atomic subsystem(Nonreusable function) as static function in code generation in Embedded coder.
Embedded Codersimulink
Related Solutions
The C-API generates code for all signals, not just test points. The reason you are seeing new signals appear is because when the subsystem is made atomic, some signals that were previously virtual become non-virtual and thus show up in the C-API. For more information on Virtual signals, please review the following documentation page: https://www.mathworks.com/help/simulink/ug/virtual-signals.html
However, these signals will not appear when generating code using Embedded Coder as it employs optimizations not available in Simulink Coder to make the generated code more efficient. Consider using Embedded Coder if the aim is to eliminate these extraneous signals.
Hi,
There are two questions here, one technical (How can I get the same behaviour as before?) and one more "philosophical" (Why did it change?)
So for the first question, I think that one way to have the desired code is to define the parameter as a model argument with a non-auto storage class to have the same behaviour as before (having the parameter as part of the data structure)
To do that, you would need to do the following
- the parameter must be in the model workspace (not in the base workspace or a data dictionary)
- the parameter must be a model argument
- the parameter must define use a storage class not equal to "auto" ("Model default" for example)
For the second question, I think without being certain that I have an explanation. So this is going to be a little bit of speculation (but I can probably ask internally to confirm this), I think that it's more "consistent" with Simulink/MATLAB semantic in this way. When you run a simulation in Simulink, if you have a parameter that comes from the base workspace, it can only have one value at a time, even if you have multiple instances of the model. Which translate in the generated code (since 2019a I think) in one unique global variable, even for reusable function interface.
What you want is to have multiple values for multiple instances of the generated code, which match Model Arguments when you think in Simulink term. (They allow each instance of the model to have separate values)
In term of documentation, this change in behaviour was documented in the release notes of R2019a, under the title "Model argument support for top models". In particular:
Compatibility Considerations
Previously, you accessed parameter data in the top model through a pointer in the real-time model. If you generated code that used the reusable code format, you could define different parameter values for each instance of a top model [your behaviour]. You defined these different values by setting the pointer to different memory with different sets of parameter values. In R2019a, for multi-instance top models and top models that use a malloc memory model, parameter data in the top model is declared as a standalone global variable. For C++ code generation, the parameter data is a static member of the model class. To define different parameter values for each instance of a top model, you must configure model arguments in the same way that you configure model arguments for referenced models. Define the parameter in the model workspace then, in the Model Data Editor, Property Inspector, or Model Explorer, select the Argument check box. [the current pattern to obtain the previous behaviour]
Best Answer