Why does Simulink code generator put #includes into my .c AND into the also #included .h?

4 次查看（过去 30 天）
Simon Ahrens
Simon Ahrens 2023-12-1
评论： Simon Ahrens 2023-12-12
I generate C code from a Simulink model. Since upgrading from 2021a to 2023b, I've noticed that Simulink redundantly #includes my _sharedutils headers containing function declarations both in myModelName.c AND in myModelName.h, even though it also #includes myModelName.h in myModelName.c.
Can anybody tell me why it would do that and how to make it stop?

请先登录，再回答此问题。

回答（1 个）

Infinite_king
Infinite_king 2023-12-11
编辑：Infinite_king 2023-12-11
Hi Simon Ahrens,
I understand that after upgrading to R2023b, C code generated from Simulink model contains unnecessary header files located in ‘my_sharedutils’ folder.
In Simulink, we can create models that can be reused in other models multiple times. Starting in R2022b, the code generator handles function and file packaging of generated code differently. For reusable library subsystems, the code generator produces subsystem code in the ‘slprj/target/_sharedutils’ folder. The subsystem code is shared across models as per model reference hierarchy.
This is indeed a valuable feature that helps minimize redundancy. You have the flexibility to control the names of functions, files, and the location of the shared library code, allowing you to customize it according to your needs. For more information on customization and setting up reusable library code, please refer to the following MATLAB documentation,
https://www.mathworks.com/help/releases/R2022b/rtw/ug/generate-reusable-code-from-library-subsystems-shared-across-models.html
For more information on changes in each release, refer the following MATLAB documentation,
https://www.mathworks.com/help/relnotes/index.html
Hope this is helpful.
  1 个评论
Simon Ahrens
Simon Ahrens 2023-12-12
Hi Infinite_king,
thanks for your reply. I'm fine with how reusable library subsystems work in general. That being said, my issue is regarding function-call subsystems. In 2023b, their block parameters don't even show the checkbox for "Treat as an atomic unit" so I can't control function packaging in the Code Generation tab.
For each of these functions/subsystems, Simulink generates a .h in slprj/ert/_sharedutils (it does not give me a slprj/target subdirectory) with the function declaration like this:
extern void semSetSndSetID(uint8_T rtu_u);
Which is fine. The function is defined in the main .c file:
/* Output function */
void semSetSndSetID(uint8_T rtu_u)
{
int32_T i;
int32_T tmp;
...
Which is also fine.
What's weird to me is that the main .c file ("x.c") #includes both the main header ("x.h") AND the function subsystem header from slprj/ert/_sharedutils like this:
#include "x.h"
#include "x_types.h"
#include "semSetSndSetID.h"
while the main .h file ("x.h") ALSO #includes it:
#include "x_types.h"
#include "semSetSndSetID.h"
Here, I would expect x.c to only include x.h and x.h to include all the sharedutils headers.

请先登录，再进行评论。

类别

在 Help Center 和 File Exchange 中查找有关 Simulink Coder 的更多信息

标签

产品


版本

R2023b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by