我是一个高层的家伙，我不想也不想知道太多关于can-bus, j1939甚至特定的ecu。我只是不喜欢软件解决方案，所以我想问一下，客户的要求是否合理。
- 如果特定的ECU在上电后300 ms超时时间内没有接收到CAN帧，它将停止响应任何进一步的帧，必须进行电源循环。这是客户技术人员提供的信息，我只能相信了。
- 可以在CAN驱动线程准备好后启动ECU，但这需要终端用户进行一些额外的布线。
- 软件解决方案都很糟糕或更糟，如在重要检查之前运行FreeRTOS，将CAN驱动程序代码与其他产品的代码相同，或在引导加载程序中启动CAN外围并在没有软件控制的情况下运行，直到驱动程序启动。
- 比较敏感的是，我们在规范中没有明确要求在这么短的时间内启动CAN驱动。客户说这是J1939规范的一部分。
有人可以证实或反驳，J1939允许设备在300 ms沉默后不可恢复地停止接收，或者要求设备在通电后300 ms内开始发送?或者至少引导我到J1939标准的部分，哪些可能考虑到这一点?
谢谢
如果特定ECU在上电后300 ms超时时间内未接收到CAN帧，则停止响应任何进一步的帧，必须进行上电循环。这是客户技术人员提供的信息，我只能相信了。
这当然完全取决于它正在执行什么任务。
一般来说，ECU，如汽车/卡车等中的汽车计算机，永远不允许挂断/闩锁。正常的操作过程将是ECU重新启动/重置自己或恢复到故障安全模式。
但对于拖拉机和重型机械，正常的安全模式是"停止一切"。
可以在CAN驱动线程准备好后启动ECU，但这需要最终用户进行一些额外的连接。
我不知道这是什么意思。什么是"额外布线"?在一个节点重新启动时保持其他节点在公共模式?终端电阻吗?什么肮脏的上电延迟电路?
软件解决方案都很糟糕，甚至更糟，比如在重要检查之前运行FreeRTOS，将CAN驱动程序代码与其他产品的通用代码放在一起，或者在引导加载程序中启动CAN外围并在没有软件控制的情况下运行，直到驱动程序启动。
一般来说，人们习惯在早期初始化时钟、看门狗、预分频器、拉电阻等关键硬件。初始化硬件外设可能很重要，也可能不重要。通常在CRT被执行之后，在main()的开始处执行此操作，初始化的顺序通常很重要。
如果从开机重置到main()开始的延迟超过300ms，则程序有严重问题。
敏感的是，我们在规范中没有明确要求在这么短的时间内启动CAN驱动。客户说，这是J1939规范的一部分。
我没怎么用过J1939，我不记得它具体说了什么，但是300ms在实时系统中是永恒的!这不是"短时间"。
一般来说，在汽车/工业环境中，正确设计的任务/安全关键型CAN控制系统是这样工作的:
- 所有数据以固定的间隔重复发送，无论数据是否更改。一般每10毫秒或每100毫秒一次。
- 当前未接收到新数据的节点将使用先前接收到的数据。
- 接收节点必须停止使用旧数据并恢复到故障安全模式时，从接收到最后一个有效数据的时间点开始存在超时。这个时间通常与被控制对象的移动速度有关。在100ms的倍数之后出现超时是很常见的。
我得说你们客户的要求很合理，没有什么不寻常的。
我的同事回答说，没有这样的要求，只是模糊的300 ms的超时时间。