CAN报文发送有优先级吗？
qa1：can报文发送，有优先级吗？答 ：有。以英飞凌tc3xx系列为例，mcmcan模块有多个硬件发送缓冲区，也就是说同一时刻可以缓存多个待发送的报文，这些报文放入待发送的缓冲区以后，会置位发送pending标志，等待发送，谁先发送呢？在回答这个问题之前，我们先说待发送的报文在硬件缓存区中的存储方式：dedicated tx buffers 、tx fifo、 tx queue。
对于dedicated tx buffers与 tx queue两种存储方式，根据lowest message id原则发送，即：发送的canid数值越小，优先级越高。具体发送顺序示例如下：
对于tx fifo存储方式，报文的发送顺序由进入fifo缓存区的先后顺序决定，即：先进先出，具体发送顺序如下：
如果使用dedicated tx buffers与 tx queue两种存储方式，优先级低的报文(比如：网络管理报文、诊断报文、标定报文等，优先级比应用报文低），是不是永远得不到发送了？不是，我们要清楚：发送的硬件缓存区不止一个，而是多个（比如：tc397有32个发送缓冲区），足以在某一时刻缓存多个待发送的报文。是否存在某一时刻（如下t1），发送报文的个数超过硬件缓存区个数？这种可能性是存在的，这也是为什么会有发送报文丢帧的原因。
为了避免发送丢帧或者周期性报文抖动问题，我们可以将相同周期性报文的发送做一个offset处理， 避免周期性相同的报文以同一个基准时间计时 。
比如：通信启动后，周期性报文msg01(周期10ms)在t0时刻开始周期性发送；而周期性报文msg02(周期10ms)在t1时刻开始周期性发送，这样即可避免两者在某一时刻的发送重叠，如下所示：
qa2：tx fifo发送方式可能引发的问题有什么？答： 对于can报文，使用fifo方式发送，我能想到的场景：诊断中，发送诊断指令使用fifo缓存，保证诊断指令请求的顺序。不知道大家在何种情况下使用过tx fifo，还请大家给普及。
这里思考到了一种工况，可能会因使用fifo发送方式，导致报文的发送延迟，具体如下所示：
假设：can bus上有两个节点：ecu1::can1和ecu2::can1，ecu1::can1使用tx fifo缓存待发送数据，ecu2::can1使用dedicated tx buffers方式缓存待发送数据。
在某一时刻，ecu1::can1的buffer index0待发送报文的can id = 0x30，ecu2::can1待发送的6个报文的can id ＜0x30，所以，每次总线仲裁，都会优先发送ecu2::can1缓存的报文，而ecu1::can1因为总线仲裁失败，导致ecu1::can1 fifo中的高优先级报文无法及时发送出去，如下所示：
所以，在使用tx fifo方式时，需要注意此工况。
qa3：程序应先处理发送报文还是应该先处理接收报文？答 ：tbd。为什么是未定义呢？在实际的项目开发中，先处理rx报文还是先处理tx报文确实没有明确规定，在项目不出问题之前，没有人会留意两者的处理顺序。
这里我们讨论一下先处理rx msg，再处理tx msg的情况，实质就是讨论task中，com_mainfunctionrx()/com_mainfunctiontx()的处理顺序。
假设：com_mainfunctionrx()/com_mainfunctiontx()均在5ms的task中，且先处理com_mainfunctionrx()，再处理com_mainfunctiontx()，如果此节点收/发的报文数量不多，任务在规定的时间内处理完（t1时刻之前），不会引发问题，如下所示：
如果当前节点接收的报文数量较多，com_mainfunctionrx()消耗了任务处理的大部分时间，导致com_mainfunctiontx()处理被delay，可能会导致本节点发送报文的周期抖动问题，比如：本来10ms的tx msg，由于延迟导致tx msg＞10ms + 容差值，假设容差值±10%(1ms)，比如：实际tx msg周期13ms，导致通信出问题。
对于一个节点，接收报文数量存在不确定性，比如：接收的报文类型如果有事件性应用报文、高周期应用报文（如：1ms周期性应用报文）等。
那么com_mainfunctionrx()的处理时间就会存在一定的不确定性。相对于接收报文，节点发送报文的数量相对比较确定，发送所消耗的时间也比较确定，所以，从处理顺序上来说， 先处理确定的发送再处理不确定的发送比较合理 ，这样可以确保发送报文的时间。
而对于接收，即使超一点时间，如果task没有超过deadline time，对程序的运行也不会造成太大影响。
再者，对于can报文，发送报文还需要进行总线仲裁，仲裁失败也会存在一定的延时（参考qa2）。
注意 ：上述假设os所使用的基准计数器是可信的，即：基础计数器准确，一般由gpt或者stm驱动。
qa4:周期型报文offset的作用是啥？答： 降低同一时刻，多个发送报文的burst send问题。这个问题属于qa1的延申。
一个节点，发送的报文类型可以有多种（qa1提到）。其中，节点外发的应用报文从几个到几十个不等。应用报文又分为事件型、周期型、混合型。以周期型应用报文为例，可能有5ms、10ms、20ms、50ms等周期。
如果本节点外发的报文数量较大，在某一时刻会存在大量并发请求。比如：msga cycle =5ms，msgb cycle = 10ms，msgc cycle = 10ms，如果msga的发送时刻为5ms、10ms、15ms、20ms、25ms、30ms.....msgb、msgc的发送时刻为10ms、20ms、30ms.....，在time ＝ 10ms、time ＝ 30ms......等时刻，msga 、msgb、msgc会同时请求发送，节点要发送的报文数量越多，某一时刻（如下图time = 10ms 时刻），请求发送的报文数量可能就越多。
在某一时刻，发送报文数量过多会带来什么问题呢？这就是qa3中的问题，会使得某个发送报文发送延迟，使得其发送周期出现抖动，即：超过该周期报文的允许误差值，一般来说，≤100ms的周期性应用报文允许的偏差为3％，＞100ms的周期性应用报文允许的偏差为1％(看oem要求)。
既然应用报文会burst send，如何降低这种并发请求行为呢？ 偏移相同周期报文的发送时机 ，比如：msgb offset 5 ms，msgc offset 10ms，这样两者的发送就不会重叠，如下所示：
那偏移不同周期的应用报文有用吗？因为周期性报文发送取决于com_mainfunctiontx()所在任务周期，offset value = n * cycle（n为非负整数，cycle指com_mainfunctiontx()的任务周期），所以，offset value是com_mainfunctiontx()任务周期的整数倍。
这样，即使设置msga、msgb的offset value不同，也不能避免某一时刻（如：time = 10ms时刻），两者的并发请求，如下所示：
随机硬件故障的分类和安全要求
200G IDC长距离互连方案—200G QSFP56 ER4光模块
I2C总线驱动的C语言源程序详细说明
赛思晶振来袭！一文带你了解电路板上的“心跳”
电池管理系统的低功耗、多路温度测量
CAN报文发送有优先级吗？
华为发布了50W超快速垂直无线充电器
普洛帝PSC-3A清洁度检测仪在铝制品行业的应用案例
友达光电将推出12.1英寸Micro LED显示技术 可实现最佳的高动态范围和低功耗
嵌入式新闻：司机不负责自动驾驶功能
石油化工定位系统助力化企落实风险管控
传闻中的小米Mi 10T Pro和Mi 10T规格
教你如何选择合适的大电流功率电感器
华为海外市场份额的大幅下滑，小米OV抢到了多少份额
成熟电池管理系统应具备的十大功能
图书馆AI机器人给我们带来了什么便利
全球第一批无钴电池长什么样
光纤振动传感技术用于南京大胜关长江大桥，几秒内实现实时预警
那些化工自动控制的仪表图形符号你认识吗?
京东物流达沃斯放信号：中国无人机海外布局提速 首站印尼
对于dedicated tx buffers与 tx queue两种存储方式，根据lowest message id原则发送，即：发送的canid数值越小，优先级越高。具体发送顺序示例如下：
对于tx fifo存储方式，报文的发送顺序由进入fifo缓存区的先后顺序决定，即：先进先出，具体发送顺序如下：
如果使用dedicated tx buffers与 tx queue两种存储方式，优先级低的报文(比如：网络管理报文、诊断报文、标定报文等，优先级比应用报文低），是不是永远得不到发送了？不是，我们要清楚：发送的硬件缓存区不止一个，而是多个（比如：tc397有32个发送缓冲区），足以在某一时刻缓存多个待发送的报文。是否存在某一时刻（如下t1），发送报文的个数超过硬件缓存区个数？这种可能性是存在的，这也是为什么会有发送报文丢帧的原因。
为了避免发送丢帧或者周期性报文抖动问题，我们可以将相同周期性报文的发送做一个offset处理， 避免周期性相同的报文以同一个基准时间计时 。
比如：通信启动后，周期性报文msg01(周期10ms)在t0时刻开始周期性发送；而周期性报文msg02(周期10ms)在t1时刻开始周期性发送，这样即可避免两者在某一时刻的发送重叠，如下所示：
qa2：tx fifo发送方式可能引发的问题有什么？答： 对于can报文，使用fifo方式发送，我能想到的场景：诊断中，发送诊断指令使用fifo缓存，保证诊断指令请求的顺序。不知道大家在何种情况下使用过tx fifo，还请大家给普及。
这里思考到了一种工况，可能会因使用fifo发送方式，导致报文的发送延迟，具体如下所示：
假设：can bus上有两个节点：ecu1::can1和ecu2::can1，ecu1::can1使用tx fifo缓存待发送数据，ecu2::can1使用dedicated tx buffers方式缓存待发送数据。
在某一时刻，ecu1::can1的buffer index0待发送报文的can id = 0x30，ecu2::can1待发送的6个报文的can id ＜0x30，所以，每次总线仲裁，都会优先发送ecu2::can1缓存的报文，而ecu1::can1因为总线仲裁失败，导致ecu1::can1 fifo中的高优先级报文无法及时发送出去，如下所示：
所以，在使用tx fifo方式时，需要注意此工况。
qa3：程序应先处理发送报文还是应该先处理接收报文？答 ：tbd。为什么是未定义呢？在实际的项目开发中，先处理rx报文还是先处理tx报文确实没有明确规定，在项目不出问题之前，没有人会留意两者的处理顺序。
这里我们讨论一下先处理rx msg，再处理tx msg的情况，实质就是讨论task中，com_mainfunctionrx()/com_mainfunctiontx()的处理顺序。
假设：com_mainfunctionrx()/com_mainfunctiontx()均在5ms的task中，且先处理com_mainfunctionrx()，再处理com_mainfunctiontx()，如果此节点收/发的报文数量不多，任务在规定的时间内处理完（t1时刻之前），不会引发问题，如下所示：
如果当前节点接收的报文数量较多，com_mainfunctionrx()消耗了任务处理的大部分时间，导致com_mainfunctiontx()处理被delay，可能会导致本节点发送报文的周期抖动问题，比如：本来10ms的tx msg，由于延迟导致tx msg＞10ms + 容差值，假设容差值±10%(1ms)，比如：实际tx msg周期13ms，导致通信出问题。
对于一个节点，接收报文数量存在不确定性，比如：接收的报文类型如果有事件性应用报文、高周期应用报文（如：1ms周期性应用报文）等。
那么com_mainfunctionrx()的处理时间就会存在一定的不确定性。相对于接收报文，节点发送报文的数量相对比较确定，发送所消耗的时间也比较确定，所以，从处理顺序上来说， 先处理确定的发送再处理不确定的发送比较合理 ，这样可以确保发送报文的时间。
而对于接收，即使超一点时间，如果task没有超过deadline time，对程序的运行也不会造成太大影响。
再者，对于can报文，发送报文还需要进行总线仲裁，仲裁失败也会存在一定的延时（参考qa2）。
注意 ：上述假设os所使用的基准计数器是可信的，即：基础计数器准确，一般由gpt或者stm驱动。
qa4:周期型报文offset的作用是啥？答： 降低同一时刻，多个发送报文的burst send问题。这个问题属于qa1的延申。
一个节点，发送的报文类型可以有多种（qa1提到）。其中，节点外发的应用报文从几个到几十个不等。应用报文又分为事件型、周期型、混合型。以周期型应用报文为例，可能有5ms、10ms、20ms、50ms等周期。
如果本节点外发的报文数量较大，在某一时刻会存在大量并发请求。比如：msga cycle =5ms，msgb cycle = 10ms，msgc cycle = 10ms，如果msga的发送时刻为5ms、10ms、15ms、20ms、25ms、30ms.....msgb、msgc的发送时刻为10ms、20ms、30ms.....，在time ＝ 10ms、time ＝ 30ms......等时刻，msga 、msgb、msgc会同时请求发送，节点要发送的报文数量越多，某一时刻（如下图time = 10ms 时刻），请求发送的报文数量可能就越多。
在某一时刻，发送报文数量过多会带来什么问题呢？这就是qa3中的问题，会使得某个发送报文发送延迟，使得其发送周期出现抖动，即：超过该周期报文的允许误差值，一般来说，≤100ms的周期性应用报文允许的偏差为3％，＞100ms的周期性应用报文允许的偏差为1％(看oem要求)。
既然应用报文会burst send，如何降低这种并发请求行为呢？ 偏移相同周期报文的发送时机 ，比如：msgb offset 5 ms，msgc offset 10ms，这样两者的发送就不会重叠，如下所示：
那偏移不同周期的应用报文有用吗？因为周期性报文发送取决于com_mainfunctiontx()所在任务周期，offset value = n * cycle（n为非负整数，cycle指com_mainfunctiontx()的任务周期），所以，offset value是com_mainfunctiontx()任务周期的整数倍。
这样，即使设置msga、msgb的offset value不同，也不能避免某一时刻（如：time = 10ms时刻），两者的并发请求，如下所示：
随机硬件故障的分类和安全要求
200G IDC长距离互连方案—200G QSFP56 ER4光模块
I2C总线驱动的C语言源程序详细说明
赛思晶振来袭！一文带你了解电路板上的“心跳”
电池管理系统的低功耗、多路温度测量
CAN报文发送有优先级吗？
华为发布了50W超快速垂直无线充电器
普洛帝PSC-3A清洁度检测仪在铝制品行业的应用案例
友达光电将推出12.1英寸Micro LED显示技术 可实现最佳的高动态范围和低功耗
嵌入式新闻：司机不负责自动驾驶功能
石油化工定位系统助力化企落实风险管控
传闻中的小米Mi 10T Pro和Mi 10T规格
教你如何选择合适的大电流功率电感器
华为海外市场份额的大幅下滑，小米OV抢到了多少份额
成熟电池管理系统应具备的十大功能
图书馆AI机器人给我们带来了什么便利
全球第一批无钴电池长什么样
光纤振动传感技术用于南京大胜关长江大桥，几秒内实现实时预警
那些化工自动控制的仪表图形符号你认识吗?
京东物流达沃斯放信号：中国无人机海外布局提速 首站印尼