第四节：代码生成基础——Embedded Coder配置、系统目标文件选择与报告解读
好，咱们进入第四节。这一节很关键，说白了就是「怎么让MATLAB把你搭的模型变成能跑在硬件上的C代码」。很多工程师在dSPACE原型上跑得飞起，一到生成产品代码就卡壳。我当年也踩过不少坑，今天就把这些经验掰开揉碎讲给你听。
4.1 Embedded Coder是什么？
Embedded Coder，你可以把它理解成Simulink Coder的「专业版」。Simulink Coder能生成代码，但那是给快速原型用的，代码里一堆冗余、浮点运算、动态内存分配。Embedded Coder不一样，它生成的代码是给嵌入式MCU用的——定点运算、静态内存、效率优先。
我个人习惯，只要目标是产品级代码，直接上Embedded Coder。别想着先用Simulink Coder生成再手动优化，那工作量你扛不住。
核心区别一句话：
- Simulink Coder → 快速原型、PC仿真、dSPACE硬件
- Embedded Coder → 量产ECU、MCU、ASIC
4.2 系统目标文件选择：ert.tlc vs grt.tlc
这是新手最容易懵的地方。打开Configuration Parameters，在「Code Generation」页面，有个「System target file」选项。下拉菜单里躺着两个最常见的文件：grt.tlc 和 ert.tlc。
选哪个？我直接告诉你结论：做产品代码，选 ert.tlc。
4.2.1 grt.tlc（Generic Real-Time）
这是通用实时目标。它生成的代码依赖MATLAB运行时环境，说白了就是你的代码里会调用一堆MATLAB的库函数。好处是调试方便，坏处是——你没法把它烧到裸片MCU上跑。
我在项目中遇到过，有人用grt.tlc生成了代码，然后想移植到Infineon TC275上。结果发现代码里一堆rt_开头的函数，根本找不到实现。嗯，那叫一个头大。
grt.tlc适合的场景：
- Windows/Linux上的实时仿真
- dSPACE原型验证（配合DS1006等板卡）
- 算法功能验证阶段
4.2.2 ert.tlc（Embedded Real-Time）
这才是我们的主角。ert.tlc生成的代码是「自包含」的——不依赖任何外部运行时库。所有代码都是标准C，可以直接扔进你的IAR、Keil、Tasking工程里编译。
我曾经把一个永磁同步电机的FOC控制模型，用ert.tlc生成代码，直接集成到客户已有的AUTOSAR工程里。从生成到跑起来，只改了一个中断优先级。这就是ert.tlc的威力。
ert.tlc的核心优势：
- 代码紧凑，无冗余
- 支持定点数优化（对MCU太重要了）
- 可配置代码接口（全局变量、函数参数、指针，随你选）
- 支持多任务调度（OSEK/FreeRTOS）
注意： 选ert.tlc后，你的模型里不能有连续状态模块（比如连续积分器）。Embedded Coder要求模型是离散的。如果你从dSPACE原型移植过来，记得先把连续模块换成离散版本。
4.3 Embedded Coder关键配置项
选好目标文件只是第一步。下面这几个配置项，我建议你每次生成代码前都检查一遍。
4.3.1 代码接口配置
在「Code Generation > Interface」页面：
- Code interface packaging： 选「Nonreusable function」还是「Reusable function」？如果你只有一个任务周期调用，选Nonreusable，代码更简洁。如果同一个子系统被多个任务调用，选Reusable。
- Data exchange： 我习惯用「Global variables」。虽然有人说全局变量不好，但在嵌入式实时系统里，全局变量效率最高。你想想看，每次函数调用传参，堆栈开销不小。
4.3.2 数据类型配置
在「Hardware Implementation」页面：
- Device vendor： 选你的MCU厂商。比如Infineon、NXP、ST。
- Device type： 选具体型号。这会影响
char、int、long的位宽定义。 - Signed integer division rounds to： 选「Zero」。这是C99标准，大多数编译器都支持。
我的小技巧： 如果你不确定MCU的配置，先选「Unspecified (assume 32-bit)」。然后生成代码后，打开生成的rtwtypes.h文件，检查里面的数据类型定义是否和你的编译器一致。
4.3.3 优化配置
在「Code Generation > Optimization」页面：
- Default parameter behavior： 选「Inlined」。这样模型里的常量会直接变成代码里的立即数，不占RAM。
- Optimize for： 选「Execution efficiency」。代码体积会大一点，但跑得快。如果你的Flash紧张，可以选「Memory efficiency」。
4.4 代码生成报告解读
代码生成完，MATLAB会自动弹出一个HTML报告。很多人扫一眼就关了，其实这里面信息量很大。
4.4.1 报告结构
报告主要分这几块：
- Summary： 代码总行数、文件数、生成时间。我一般先看这个，心里有个数。
- Code Interface Report： 这个最重要。它列出了所有对外接口——输入、输出、参数、全局变量。你移植到产品代码时，就照着这个列表去对接硬件驱动。
- Traceability Report： 模型里的模块和代码行之间的对应关系。调试时特别有用。比如你发现某个输出不对，可以反向追踪到模型里的具体模块。
- Static Code Metrics： 代码复杂度、圈复杂度、嵌套深度。如果圈复杂度超过15，我建议你重构模型。太复杂的逻辑，编译器优化效果差，也容易出bug。
4.4.2 我必看的三个指标
| 指标 | 正常范围 | 警告值 | 我的经验 |
|---|---|---|---|
| 代码总行数 | 视模型复杂度而定 | 超过预期2倍 | 检查是否开启了「冗余注释」或「调试模式」 |
| 全局变量数 | 10-50个 | 超过100个 | 考虑用结构体封装，或者改用函数参数传递 |
| 最大嵌套深度 | ≤ 4层 | ≥ 8层 | MISRA-C要求不超过4层，超过的话建议用状态机重构 |
4.4.3 报告里的「坑」
我曾经遇到过一次，代码生成报告显示「0 errors, 0 warnings」，但代码烧到板子上就是跑不起来。后来发现，报告里有个「Code Interface Report」的表格，里面有个信号被标记为「Imported」，但我忘了在外部定义这个变量。
所以我的习惯是：每次生成代码后，先看Code Interface Report，确认所有输入输出都和你预期的硬件接口一致。然后再去编译。
总结一下这节的核心：
- 产品代码用
ert.tlc，别碰grt.tlc - 配置时重点检查接口、数据类型、优化选项
- 代码生成报告不是摆设，Code Interface Report是移植的「地图」
下一节，我们会真正动手——把一个dSPACE原型模型，通过Embedded Coder生成产品级代码，然后移植到STM32上跑起来。到时候我会带着你一步步操作，包括怎么处理那些「模型能仿真但生成代码报错」的奇葩问题。