本文讨论了CAN Pack模块的用法以及该模块生成的代码。 查看和编辑一些dbc文件涉及的内容需要从Vector官方网站下载CANdb Editor软件。
文章1在1 Simulink上的CAN Pack模块2 CAN Pack模块建模和模拟2.1模块中配置DBC文件2.2 CAN Pack模块模拟2.2.1模拟1:初始配置2.2.2 ffset属性2.2.3模拟：valuetttaluetation .4模拟4:字节顺序属性- -英特尔格式2.2.5模拟53:字节顺序属性
在汽车ECU软件开发中，ASW软件将信号封装到消息中后，BSW一般实现CAN的发送功能。 要打包Signal，必须首先知道各个Signal在整个消息中的布局(Layout )，然后才能从DBC文件中获取描述信息。
在DBC文件中知道Signal和Message之间的关系后，必须在代码或模型中实现打包过程。 CAN Pack模块从Signal打包到消息中。
CAN Pack模块如下图所示，输入端连接Signal，输出端输出打包的消息。
2 CAN Pack模块建模和仿真本章介绍了使用dbc文件配置CAN Pack模块以及每个配置参数与模拟结果之间的关系。
2.1在模块中放置DBC文件1 )首先在matlab根路径下查找DBC文件demoVNT_CANdbFiles.dbc，作为后面模拟的原材料。
将此dbc文件复制到与模型相同的路径。
2 )在模型中创建新的CAN Pack模块，并选择Data is input as下拉框作为CANdb。 这意味着要用DBC文件中的参数打包Signal。 将下一个CANdb file文本框设置为上一步的dbc名称。 选中下面的输出总线。
3 )上述配置完成后，此模块会自动从DBC中识别消息列表。
4 )选择下图中的一个类似WindowControlMsg的消息，将在下面的Signal栏中切换到此消息中包含的所有Signal和Signal属性。
在CANdb中打开此dbc文件demoVNT_CANdbFiles.dbc以显示完全匹配的属性信息。 说明了CAN Pack解析了dbc文件，设定了功能。
5 )单击“确定”保存模块配置后，在型号中，模块将变为两个输入端口，分别对应于此消息中的两个信号。
的CAN Msg是总线信号，其中的Data和ID比较重要。 重点讨论消息数据和输入的关系。
2.2 CAN Pack模块模拟基于2.1节的布局，可以尝试使用该模块进行模拟。 修改dbc文件时，模块的输出结果不同。
2.2.1模拟1:初始配置1 )首先，如果不修改DBC文件，则WindowControlMsg中两个信号的布局如下。
PassengerDoorWindow信号的开头比特(startbit )为0，长度(length )为8，因此占消息的第0行。 DriverDoorWindow信号的开始位(startbit )为8，长度(length )为8，因此占消息的第一行。 他们的数值范围都在0到255之间，Factor和offset分别为1和0。 也就是说，从原始值到物理值没有放大或偏移变换，也没有横向复杂性。
2 )在模型中，输入PassengerDoorWindow为常数128，输入DriverDoorWindow为常数25。 进行模拟后，可以看到输出结果的Data[0]和Data[1]分别为128和25。 也就是说，我们将PassengerDoorWindow和DriverDoorWindow打包为消息的Data[0]和Data[1]。
此消息在DBC上的部署是简单特殊的，仿真1，因此封装过程非常简单，直接将两个信号放在消息的前两行中。 博主手动修改和模拟demoVNT_CANdbFiles.dbc中的配置信息，并讨论在属性更复杂的情况下可获得什么结果。
2.2.2模拟2:factoroffset属性在封装过程中可以用factoroffset属性进行放大和偏移，公式如下：
raw _ value=(physical _ value-offset )/Factor为什么要做这个转换呢？ 想想某个情况。 如果Signal的物理值范围为- 1010，精度为0.1，那么如何用消息表示呢？ 可以将此物理值乘以10(offset=-10 )，再乘以10 )
or=0.1)，那么-10–>10的范围就会扩大到0–>200，在Message中就可以用8个bit的长度来表示了。下面就可以验证一下这个属性。1）打开DBC文件，将PassengerDoorWindow的Factor设为0.1，Offset设为-10，Minimum设为-10，Maximum设为10，其他的属性不变，并保存。
2）在CAN Pack模块中重新选一下dbc文件。
3）在模型中，将PassengerDoorWindow输入为常量-4.5，仿真得出结果如下。打包后的Data[0]输出为55.
从-4.5的物理值到55的原始值，就是经历了一个factor&offset公式转换。首先-4.5减去offset（-10），得出5.5；然后5.5除以factor（0.1）得出55；最后根据startbit和length，将转换过后的原始值55打包进了Data[0]。
Value Type属性表示打包进Message的时候的类型选择。在仿真1中的默认项是Unsigned。博主在工作中只遇到过Unsigned和Signed两种Value Type属性，所以这一章节研究一下Value Type属性为Signed时，是怎么打包Message的。
1）在仿真1的原始DBC基础上，将PassengerDoorWindow的Length属性设为7，Value Type属性设为Signed，Minimum设为-64，Maximum设为63，其他的属性不变。这样设置表示，用7个bit来描述有符号数，可以描述从-64到63.
2）在CAN Pack模块中重新选一下dbc文件。
3）在模型中，将PassengerDoorWindow输入为常量30，仿真得出结果如下。打包后的Data[0]输出为30。
说明0~63的正整数是按照原来的数值打包进Message Data的。
4）在模型中，将PassengerDoorWindow输入为常量-30，仿真得出结果如下。打包后的Data[0]输出为98。
这个计算过程很简单，在dbc文件中把Length属性设置为7，也就是用7个bit来表示正整数和负整数，前一半用于表示正数，后一半用于表示负数。后一半的计算过程是
所以，如果输入的PassengerDoorWindow是-15，那么Data[0]会输出113。另外，本节的Value Type属性和上一节的factor&offset属性都可以用来表示正负数，但是实际工作中，博主觉得factor&offset属性比较灵活一点，在代码中有更好的统一性。
2.2.4 仿真4:Byte Order属性–Intel格式Btye Order属性表示打包Message时的字节顺序，分为Intel和Motorola两种。在仿真1，2，3中，信号在Message中的排布方式都是仅占据一行的。当一个Signal跨越多行的时候，Byte Order属性就会决定打包时候的顺序，具体区别如下：
Intel格式：Signal的低位存放在Message的低位，Signal的高位存放在Message的高位。Motorola格式：Signal的低位存放在Message的高位，Signal的高位存放在Message的低位。用文字概念表述不容易理解，但是通过Simulink的CAN Pack模块，就可以轻松理解Byte Order属性的含义。
下面就会通过仿真来理解Intel格式的Byte Order属性。
1）在仿真1的原始DBC基础上，将DriverDoorWindow的Startbit改成20，Length保持为8，Byte Order保持为Intel，然后点击应用。
2）双击WindowControlMsg，切换到Layout选项卡，可以看到DriverDoorWindow信号在Message中的布局。
DriverDoorWindow转换成2进制后，由于是Intel格式，低4位放在了Message的第20号到23号中；高4位放在了Message的24号到27号中。
3）在CAN Pack模块中重新选一下dbc文件。
4）在模型中，将DriverDoorWindow输入为常量100，仿真得出结果如下。打包后的Data[2]输出为64，Data[3]输出为6。
移位的过程可以按照如下方式推算。
首先将100转为2进制，就是0110 0100。所以DriverDoorWindow的低4位是0100，高4位是0110。
根据第2步中的关系，DriverDoorWindow的低4位要放在Message的20号到23号，也就是Data[2]的高4位，所以要将0000 0100左移4位，得到01000000，再转为10进制就是64了，也就是仿真输出的Data[2]。
同理，DriverDoorWindow的高4位要放在Message的24号到27号，也就是Data[3]的低4位，所以将01100000右移4位，得到00000110，再转为10进制就是6，所以Data[3]输出的值就是6。
下面就会通过仿真来理解Motorola格式的Byte Order属性。
1）在仿真1的原始DBC基础上，将DriverDoorWindow的Startbit改成20，Length保持为8，Byte Order保持为Motorola，然后点击应用。
2）双击WindowControlMsg，切换到Layout选项卡，可以看到DriverDoorWindow信号在Message中的布局。
这里的Layout中就可以看出和仿真4中是不同的。在Motorola格式的时候，低4位放在了Message的第20号到23号中；高4位放在了Message的8号到1号中。
3）在CAN Pack模块中重新选一下dbc文件。
4）在模型中，将DriverDoorWindow输入为常量100，仿真得出结果如下。打包后的Data[2]输出为64，Data[1]输出为6。
移位的过程也可以按照仿真4中相同的方法推算，这里再重新算一次。
首先将100转为2进制，就是0110 0100。所以DriverDoorWindow的低4位是0100，高4位是0110。
根据第2步中的关系，DriverDoorWindow的低4位要放在Message的20号到23号，也就是Data[2]的高4位，所以要将0000 0100左移4位，得到0100 0000，再转为10进制就是64了，也就是仿真输出的Data[2]。这一点和仿真4是相同的。
不同的是，DriverDoorWindow的高4位要放在Message的8号到11号，也就是Data[1]的低4位，所以将0110 0000右移4位，得到0000 0110，再转为10进制就是6，所以Data[1]输出的值就是6。
在第2章中仿真得到了正确的结果，但是在实际工作中需要通过代码来实现打包Signal的功能。如果手写过CAN打包的C代码，过程十分的繁琐也很容易出错。好在CAN Pack模块是支持生成代码的，所以本章节将这个模块生成代码。
1）在仿真模型的基础上，把输入的常数模块和输出的Disp模块替换成Inport和Outport。
2）配置好离散求解器和Embedded Coder文件，可以参照博主以前的博客。
3）Ctrl + B生成代码。
很简单的一个CAN Pack模块生成了200多行代码，只为了把两个Signal打包到一个Message中。其中所用的算法中，使用了大量的移位运算。另外，为了通用性，还出现了很多左移右移0位的代码。
所以就不建议仔细阅读这一段代码了，直接拿去编译就行。
4 总结本文研究了Simulink中的CAN Pack模块的仿真和代码生成。与之相对的还有CAN Unpack模块，可以将一个Message中的信号解析出来。其用法思路就是把CAN Pack倒过来，可以举一反三。
>>返回个人博客总目录