3. CDD项目创建与配置：新建CDD模块、配置容器(Container)、配置端口(Port)、配置数据类型
好，咱们进入实战环节。上一章我们把CDD的"骨架"——也就是它的架构和原理——讲清楚了。这一章，咱们要亲手把这个骨架搭起来。
说白了，就是打开你的开发工具，从零开始创建一个CDD模块。我会带着你一步步走完：新建模块、配置容器、配置端口、配置数据类型。这些都是最基础的操作，但也是后面所有工作的根基。
我个人习惯，在开始任何配置之前，先想清楚一件事：这个CDD模块到底要跟谁通信？通信的内容是什么？想清楚了再动手，能省掉后面很多返工的麻烦。
核心要点：CDD项目创建的本质，是在AUTOSAR的框架下，为你的"特殊硬件"搭建一个专属的"通信小屋"。容器是房间，端口是门，数据类型是门里传递的东西。
3.1 新建CDD模块：从零开始
嗯，这里要注意。不同的工具链（比如Vector的DaVinci、EB的tresos、ETAS的ISOLAR）界面虽然不同，但底层逻辑是一样的。我以最常见的DaVinci Developer为例来讲，你理解了这套逻辑，换其他工具也能很快上手。
新建CDD模块，通常就这几步：
- 创建SWC原型：在项目树里找到"Application SWC"或者"Complex Driver"的类别，右键新建。选择类型为"ComplexDriver"。
- 命名规范：我建议用
Cdd_开头，后面跟模块功能名。比如Cdd_CanTrcv、Cdd_SpiFlash。这样一看就知道是CDD模块。 - 关联实现文件：工具会让你选择或创建对应的
.c和.h文件。这里我踩过坑——一定要让工具自动生成文件框架，不要自己手动建空文件再关联，否则RTE生成时会报一些莫名其妙的错。
我的经验：新建模块时，工具会生成一个模板。别急着删里面的注释和占位符。那些#ifndef、#define的宏定义结构，是AUTOSAR规范要求的。我曾经手欠删了一个，结果编译链报了几十个重复定义的错，排查了半天。
3.2 配置容器(Container)：给数据安个家
容器是什么？你可以把它理解成一个"数据盒子"。你的CDD模块需要跟其他SWC或者BSW模块交换数据，这些数据不能散落在外面，得有个容器装着。
配置容器时，有几点要特别注意：
- 容器类型：AUTOSAR里容器分两种——
NvBlockDescriptor（非易失性数据）和普通的ParameterDataPrototype。如果你要存的是掉电不丢失的数据（比如校准参数），用前者；如果是运行时临时数据，用后者。 - 容器命名：我习惯用
Cdd_模块名_容器名。比如Cdd_SpiFlash_Config。这样在RTE配置界面里，一眼就能找到属于这个模块的容器。 - 容器大小：这个要提前算好。我见过一个项目，工程师把容器大小设成了1KB，结果实际数据只有10个字节。浪费资源不说，还导致内存对齐出了问题。建议先画个数据结构图，算清楚每个字段的字节数。
避坑指南：我曾经在一个项目中，把两个不同用途的数据放在同一个容器里。结果后来需求变更，一个数据需要增加长度，另一个不变。改起来非常痛苦，因为容器长度变了，所有引用这个容器的模块都得重新验证。所以，一个容器只放一类数据，这是铁律。
3.3 配置端口(Port)：打通通信的"门"
容器有了，数据怎么进出？靠端口。端口就是CDD模块跟外界通信的"门"。
AUTOSAR里端口分两种：
| 端口类型 | 方向 | 典型用途 |
|---|---|---|
SenderReceiverPort |
发送/接收 | 周期性数据、事件触发数据 |
ClientServerPort |
请求/响应 | 函数调用、同步操作 |
配置端口时，我一般遵循这个原则：
- 数据流简单（比如传感器读数），用
SenderReceiverPort。CDD只管发，接收方自己决定什么时候读。 - 需要双向交互（比如"发一条指令，等一个应答"），用
ClientServerPort。CDD作为Server，提供接口给其他模块调用。
举个例子。我之前做的一个Cdd_SpiFlash模块，对外提供了两个端口：
- 一个
SenderReceiverPort叫Cdd_SpiFlash_DataOut，用来把从Flash读到的数据广播出去。 - 一个
ClientServerPort叫Cdd_SpiFlash_Write，其他模块调用这个接口来写入数据。
这样设计，读写分离，逻辑清晰。你想想看，如果读写混在一个端口里，RTE配置的时候得多乱？
3.4 配置数据类型：定义"门"里传的东西
端口配好了，但门里传的东西长什么样？这就是数据类型要干的事。
AUTOSAR里数据类型分三个层次：
- Application Data Type (ADT)：应用层的数据类型，比如"车速"、"发动机温度"。它不关心底层怎么存。
- Implementation Data Type (IDT)：实现层的数据类型，比如
uint8、sint16。它决定了数据在内存里占几个字节。 - Base Type：最底层，比如
boolean、uint8、float32。
配置的时候，我建议你：
- 先定义ADT：从业务角度想，这个端口要传什么？比如"温度值"、"状态码"。
- 再映射到IDT：这个温度值用
uint16还是sint16？精度够不够？范围够不够？ - 最后绑定到端口：把ADT挂到端口上，工具会自动帮你完成类型映射。
一个常见的坑：很多人图省事，直接跳过ADT，把IDT挂到端口上。短期内没问题，但一旦项目需要做跨平台移植（比如从16位MCU换到32位），uint16和uint32的差异会让你改到崩溃。多花5分钟定义ADT，能省后面5小时的麻烦。
下面是我画的一张图，把整个配置流程串起来：
这张图把整个流程串起来了。你按照这个顺序走，基本不会出错。
3.5 实战小贴士：配置完别忘了验证
配置完成后，工具一般会提供一个"验证"或"检查"功能。我强烈建议你跑一遍。它会检查：
- 端口有没有绑定数据类型
- 容器大小是否合理
- 模块间的连接是否完整
我记得有一次，我配置完一个CDD模块，验证时报了十几个Warning。排查下来，原来是有一个端口的数据类型忘记映射了。如果直接生成代码，那个端口就会变成一个"黑洞"——数据发出去没人收，或者收了数据不知道是什么格式。
所以，配置完一定要验证。这个习惯能帮你省掉至少一半的调试时间。
我的习惯：每次配置完一个模块，我都会手动检查三样东西：
- 容器的起始地址和长度对不对
- 端口的方向（In/Out）有没有搞反
- 数据类型的字节序（大端/小端）是否匹配
这三样对了，后面基本不会出大问题。
好了，CDD项目创建与配置的核心内容就这些。你按照这个流程走一遍，就能搭出一个结构清晰、可维护性强的CDD模块框架。下一节，我们会在这个框架里填充真正的代码逻辑——也就是CDD的初始化和主函数实现。
可可精品资料库