嵌入式代码生成
原始 Flomo：https://v.flomoapp.com/mine/?memo_id=OTA0MTk0MDI
嵌入式代码生成
代码生成在嵌入式里分两条路：一条是 从模型生成代码（MBD，Model-Based Design），一条是 从配置生成代码（AUTOSAR工具链）。两条路解决同一个问题——让机器写那些”有规律但容易手写出错”的代码。
MBD：从模型生成代码
-
Simulink + Embedded Coder → 生成快速原型C代码（适合算法验证、快速迭代，但代码效率和可读性一般）
-
Simulink + TargetLink → 生成产品级C代码（dSPACE出品，代码质量接近手写，AUTOSAR项目中常用）
-
从模型到代码的路径：Simulink模型（含rate调度）→ 代码生成器 → 根据采样率拆成多个定时任务（10ms/50ms/100ms）
-
MIL/SIL/PIL/HIL四个验证阶段：MIL验证算法正确性 → SIL验证生成代码行为与模型一致 → PIL验证目标处理器上的精度（浮点行为差异）→ HIL验证硬件在环中的实时性
-
模型Inport/Outport → AUTOSAR SWC的RPort/PPort映射，ARXML系统常量与模型工作空间变量的对应
AUTOSAR：从配置生成代码
AUTOSAR代码生成跟MBD的”模型→代码”不同，它是”配置（ARXML）→ 代码”：
-
BSW代码生成：DaVinci Configurator Pro / EB tresos Studio 读ARXML配置 → 生成各BSW模块代码（Can.c、CanIf.c、Dcm.c、NvM.c……）。每次配置变更重新生成，不手动修改生成的代码
-
RTE代码生成：基于SWC配置 → 生成Rte.c / SchM.c，负责SWC之间的通信调度和跨核通信
-
SWC手写代码：应用逻辑代码（唯一手动维护的部分），通过RTE接口与BSW层通信
-
Makefile处理三种来源的文件：工具生成的BSW代码、工具生成的RTE代码、手写的SWC代码，各自路径不同
典型代码生成Pipeline
修改一个BSW配置项（如增加一个CAN报文）到可烧录hex的全流程：
-
在DaVinci/EB中修改配置（增加PDU、Signal、Frame）
-
生成ARXML → 生成BSW代码
-
集成到工程 → 编译（Makefile处理BSW + RTE + SWC）
-
烧录验证
这个流程也被称为”AUTOSAR的配置地狱”——改一个参数可能要重新生成整个BSW代码、重新集成、重新编译。
工具链核心差异
-
TargetLink → 产品级代码，适合量产AUTOSAR项目
-
Embedded Coder → 快速原型代码，适合算法验证
-
DaVinci Configurator Pro / EB tresos Studio → BSW配置与代码生成
-
DaVinci Developer → SWC架构设计
-
arxmlparser（轻量）→ Python脚本批量处理ARXML（改端口名、Excel导入DID），适合一次性任务
-
Artop（完整元模型）→ 需要验证ARXML语义正确性的场景
手写 vs 生成的取舍
-
MBD的优势不是”代码质量比手写好”，而是模型比代码更容易做”需求-设计-测试”的闭环追溯
-
BSW代码（Can/NvM/Dcm等）通常工具生成，不手动改
-
SWC应用逻辑代码通常手写，因为业务逻辑变化频繁且有领域知识嵌入
-
混合模式：模型生成SWC框架 + 手写业务逻辑回调
📎 MBD详细问题深入（Q&A形式）→ https://v.flomoapp.com/mine/?memo_id=MjQ3MjgyMzA4