第四章：数据类型与接口

好，咱们进入第四章。这一章我把它叫做「搭积木的基石」。你想想看，在 DaVinci Config 里做开发，最核心的事情是什么？就是定义数据怎么存、怎么传、怎么对接。说白了，就是数据类型和接口那点事。

我个人习惯，每次开始一个新项目，第一件事不是画流程图，而是先把数据类型和接口定下来。为什么？因为后面所有的通信、所有的逻辑，都建立在这上面。你接口没定好，后面改起来，那叫一个痛苦。我曾经有个项目，就因为一个信号类型定义错了，导致整个团队加班三天改模型，嗯，从那以后我再也不敢马虎了。

4.1 基础数据类型

DaVinci Config 里的基础数据类型，其实跟 C 语言很像，但又不完全一样。它更偏向于汽车电子领域的习惯。

常见的就那么几种：

• Boolean：真或假，没啥好说的
• Integer：分有符号和无符号，长度从 8 位到 64 位都有
• Float：浮点数，单精度和双精度
• String：字符串，注意长度限制
• Enum：枚举，这个在配置里用得特别多

我举个例子，你在定义传感器状态时，用枚举就比用整数直观得多：

// 不推荐的做法
uint8 SensorStatus;  // 0=正常, 1=故障, 2=未知

// 推荐的做法
enum SensorStatusType {
    SENSOR_OK = 0,
    SENSOR_ERROR = 1,
    SENSOR_UNKNOWN = 2
};

你看，哪个更清晰？一目了然。我在项目中遇到过，有人用整数定义状态，结果后来加了一个状态，所有人都得去翻文档才知道 3 代表什么。用枚举，代码就是文档。

4.2 复合数据类型

基础类型够用吗？当然不够。真实项目里，数据往往是组合在一起的。比如一个车速信号，它不光有速度值，还有有效位、时间戳、来源信息。这时候就需要复合数据类型了。

DaVinci Config 支持两种复合类型：

• Structure（结构体）：把多个不同类型打包在一起
• Array（数组）：相同类型的多个元素

结构体用得最多。我一般这样定义：

// 定义一个车速信号结构体
struct VehicleSpeedType {
    uint16 SpeedValue;       // 车速值，单位 0.01 km/h
    boolean IsValid;         // 有效标志
    uint8 SourceID;          // 信号来源
    uint8 Checksum;          // 校验和
};

这里要注意一个坑：字节对齐。不同的编译器对结构体的对齐方式不一样。你在 DaVinci Config 里定义的结构体，如果跟实际代码里的对齐方式不一致，数据解析就会出错。我曾经排查过一个 bug，查了两天才发现是结构体对齐问题。嗯，说起来都是泪。

4.3 接口定义

接口是什么？就是组件之间通信的契约。在 DaVinci Config 里，接口定义了数据交换的格式和协议。

接口分两种：

• Client-Server 接口：一问一答的模式。客户端发请求，服务端给响应。
• Sender-Receiver 接口：发布订阅的模式。发送者只管发，接收者决定要不要收。

我个人更倾向于用 Sender-Receiver 接口来做周期性数据，比如传感器值、状态信息。而 Client-Server 接口适合做配置、诊断这类需要确认的操作。

定义接口时，我建议遵循几个原则：

1. 接口粒度要适中：别一个接口里塞几十个信号，也别一个信号一个接口
2. 命名要规范：一看名字就知道这个接口是干什么的
3. 版本要管理：接口一旦发布，就别轻易改。真要改，必须升版本号

举个例子，一个简单的传感器接口：

// Sender-Receiver 接口定义
interface ISensorData {
    // 发送者提供的数据
    sender {
        float Temperature;      // 温度值
        uint16 Pressure;        // 压力值
        boolean SensorFault;    // 故障标志
    }
    
    // 接收者可以获取的数据
    receiver {
        void GetSensorStatus(out boolean status);
    }
}

4.4 端口与连接器

有了接口，怎么把它挂到组件上？这就用到端口和连接器了。

端口是组件上的一个「插口」。一个组件可以有多个端口，每个端口关联一个接口。端口分两种：

• Provided Port（提供端口）：组件提供这个接口的服务
• Required Port（需求端口）：组件需要这个接口的服务

连接器就是把两个端口连起来的「线」。一个提供端口连一个需求端口，数据就能流通了。

我画个简单的例子：

// 组件 A：传感器
Component Sensor {
    Provided Port: pSensorData  // 提供传感器数据
}

// 组件 B：控制器
Component Controller {
    Required Port: rSensorData  // 需要传感器数据
}

// 连接器
Connector {
    Connect Sensor.pSensorData to Controller.rSensorData
}

这里有个容易犯的错：端口类型不匹配。提供端口和需求端口必须关联同一个接口，否则连接器连不上。DaVinci Config 会在编译时检查这个，但如果你用了动态连接，运行时才会报错。嗯，那调试起来就麻烦了。

4.5 数据映射

最后一步，数据映射。这是把抽象的数据类型映射到具体的通信协议上。比如，你定义了一个车速信号，它最终要放到 CAN 报文里发出去。

数据映射要做几件事：

• 信号到报文的映射：哪个信号放在报文的哪个位置
• 字节序：大端还是小端
• 缩放因子和偏移量：物理值怎么转成原始值
• 有效范围：信号的有效值区间

我举个例子，一个温度信号映射到 CAN 报文：

// 温度信号定义
Signal: EngineTemp
    Physical Range: -40 to 215 °C
    Scaling: 0.1 °C/bit
    Offset: 40
    Byte Order: Little Endian
    Start Bit: 0
    Length: 16 bits

// 映射到 CAN 报文
PDU: EngineDataPDU
    Signal: EngineTemp @ Byte 0, Bit 0, Length 16
    Signal: EngineSpeed @ Byte 2, Bit 0, Length 16
    Signal: EngineStatus @ Byte 4, Bit 0, Length 8

这里要注意的是缩放因子和偏移量的计算。我见过有人把公式搞反了，结果接收端算出来的温度差了 40 度。你想想看，要是发动机温度显示 80 度，实际是 120 度，那后果...

好了，这一章的内容就这些。数据类型是基础，接口是契约，端口和连接器是骨架，数据映射是血肉。把这四块搞明白了，你的 DaVinci Config 项目就成功了一半。

下一章，咱们聊聊运行时配置和调度。那才是真正让系统跑起来的关键。