tag 标签: can

相关帖子
相关博文
  • 热度 3
    2020-12-25 17:38
    812 次阅读|
    1 个评论
    ​By Toradex胡珊逢 CAN总线在工业、汽车行业具有非常广泛的应用,为网络中设备之间点对点通信提供一种可靠、稳定、经济的方案。伴随网络中设备节点的增加,由于1Mbps速率和最长数据8字节的限制,通信效率和总线占用问题变得愈发突出。而CAN FD正是为了应对这种挑战而出现。文章接下来将介绍CAN FD的一些新特点以及使用注意事项,最后将使用Toradex Apalis iMX8QM和Verdin iMX8M Mini计算机模块简单演示CAN FD使用。 相比于传统CAN协议,CAN FD最大的两个特点是采用可变速率和单帧最长64字节数据,另外包括控制位和CRC校验的变化。 ​ 图1:传统CAN和CAN FD帧 控制位的首位由传统CAN的RTR变为CAN FD的RRS,该位始终是显性(0)。第三个控制位在传统CAN中属于保留功能,在CAN FD位FDF,位隐性(1)。FDF位1时表示该帧是CAN FD格式。在CAN FD中紧随FDF还是一个保留功能,用于将来的扩展。BRS(Bit Rate Switch)位允许CAN FD帧以不同的速率进行传输。如果BRS为显性(0)则该帧采用和仲裁阶段(Arbitration Phase)同样的速率进行传输,既速率不发生变化。当BRS为隐性(1),该帧接下来的部分将以较高的速率传输。这里需要注意,并不是整个CAN FD帧都用高速率传输,如下图,Data Phase从BRS后的ESI位开始到CRC Delimiter位结束,该阶段的数据会以较高的速率传输。 ​ 图2:CAN FD帧结构 ESI(Error Status Indicator)通常为显性(0)。当发送方遇到通讯异常后会将其置为隐性(1)。DLC表示该帧中实际数据长度,为了于传统CAN兼容,DLC仍然采用4bit。当数据长度小于8字节时,DLC位的数值可以直接表示数据长度,但超过8字节时,由于4个位最高只能表示15,为了支持CAN FD最长64字节数据,这里采用了折中的表示方法。当数据不超过8个字节时,DLC仍直接表示数据长度。当超过8个字节,只支持12到64中部分长度的数据包,而非全部的9到64任一长度。如下表所示,当DLC为9时,CAN FD数据长度为12字节,DLC为12时,数据长度是24字节。 DLC和数据长度对应关系 DLC 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 数据长度 0 1 2 3 4 5 6 7 8 12 16 20 24 32 48 64 在实际应用中最好选择上面的其中一种长度,避免通讯效率降低。如果小于某一种长度,则需要对数据进行填充,可以用0xCC和0x55作为填充字节,这样能够在总线上产生足够的波形翻转从而使CAN节点保持同步。 在CAN FD中根据数据长度会采用不同的CRC校验方案,当小于等于16字节是为CRC-17,当数据大于16字节后则采用CRC-21。CRC Delimiter之后的格式CAN FD和传统CAN仍保持一致。 CAN FD虽然具有更长的数据包以及更快的传输速度,但是由于引入了更多的位到帧中,帧的开销也会增加。以同样发送1字节数据包为例,传统CAN 2.0标准帧和CAN FD标准帧具体组成如上方图1所示。传统CAN 2.0标准帧总共位54 bit,CAN FD为70 bit。CAN FD需要多消耗16 bit来传送同样的数据。如果CAN FD不采用更高的可变速率这就意味着同样的帧,CAN FD反而会要更长的传输时间。当CAN FD采用可变速率,那么情况将会变得不一样。假设CAN FD的仲裁速率是500 Kbps,和传统CAN的速率一致,而可变的数据传输速率提高8倍到4 Mbps。传统CAN耗时为54 bit/ 500 Kbps = 108 us。CAN FD中4 Mbps的速率只用于传输从ESI位开始到CRC Delimiter位之间的数据,所以CAN FD耗时为29 bit/500 Kbps + 41 bit/4 Mbps = 68 us。这里我们看到,在提高数据传输速率情况下,CAN FD即使有更多的帧开销,帧传输时间还是减少了40 us。更高的传输速度有利于发送节点更快得完成帧发送,减少CAN总线占用时间,这对越长数据的帧会更加明显,对CAN网络的实时性来讲是一个优势。 然而提高传输速率不仅仅是在使用的时候设置一个参数,更重要的是保障CAN总线物理链路层的质量。可以使用示波器观察总线上信号的质量。如果信号陡峭且清晰,可以尝试将数据传输速率提高到仲裁速率的2到4倍。测量点需要遍布总线上多个位置,信号在不同位置会有所差异。线路阻抗的一致性对信号质量至关重要。通常在总线交叉点的线缆没有发生物理尺寸变化,并采用具有相同介电常数的隔离器,阻抗会保持不变。这可以参考以太网和USB中使用的专门的连接器。当CAN FD采用较高的传输速率时,每处线路分叉,每个连接器都可能会影响阻抗,从而引起信号反射。这些反射信号的能量最终可以影响CAN帧每个比特位边缘的抖动。 CAN FD最长64字节的数据包使用在实际应用中也需要注意。更长的帧不可避免在传输的时候会占用总线更多的时间,而这期间其他CAN节点则无法发送数据。对于实时性需求不高的场合,如通过CAN总线升级固件,长帧能够以更小的开销完成传输。而对实时性有要求的场合,对长帧的使用需要有一定的限制。对于8字节以下的帧,CAN FD更高的数据传输速率可以有效降低总线占用时间,前提是物理链路层能够满足高速传输的要求。 对于应用开发CAN FD的使用是非常简单的。CAN FD是可以兼容传统CAN,这意味着原先基于传统CAN通信的代码可以直接运行在支持CAN FD的设备上,但不使用任何CAN FD的新功能。如果需要使用CAN FD的可变数据速率或者超过8字节数据的帧,那么代码也只需做简单的修改。我们以Linux中SocketCAN为例,使用can-utils代码进行说明。在cansend.c和candump.c中采用canfd_frame结构体来存放需要发送和接收的CAN数据。CANFD_MAX_DLEN为64,对应CAN FD最长的64字节。 ​ 然后将can socket设置CAN FD格式,使用setsockopt()函数,设置CAN_RAW_FD_FRAMES参数即可。 ​ 在发送时将struct canfd_frame frame结构体中len长度参数设置CAN FD定义几种长度。 ​ 剩余代码中的操作可以沿用传统CAN模式下的方法。最后用下面命令配置CAN设备。这里仲裁速率为500Kbps,CAN FD可变数据速率为1Mbps,在结尾添加fd on参数启用CAN FD。 ​ 接下来我们将在Apalis iMX8QM和Verdin iMX8M Mini计算机模块上演示CAN FD通信。Apalis iMX8QM 采用NXP i.MX8 QuadMax处理器,可以提供3路CAN接口。Verdin iMX8M Mini上的i.MX8 M Mini处理器本身并不支持CAN接口,我们在模块上添加了一块MCP2518实现CAN接口。 ​ Apalis iMX8QM和Verdin iMX8M Mini分别通过Ixora和Dahlia载板进行CAN接口互联。这两个底板上均引出了CAN接口,方便用户测试。 ​ Verdin iMX8M Mini作为发送端,依次运行下面命令,并发送4字节和10字节长度的帧。 ​ Apalis iMX8QM作为接收端。 ​ 上面测试可以看到Verdin iMX8M Mini发送一帧10字节长度的数据,但是Apalis iMX8QM在收到了12字节的数据。这是CAN FD定义没有10字节的帧长,适合发送10字节的是12字节长度的帧。所以看到实际收到的是“11 22 33 44 55 66 77 88 99 00 00 00”这12个字节,最后两个“00 00”是填充的数据。这部分填充数据来自lib.c代码 memset(cf, 0, sizeof(*cf)); /* init CAN FD frame, e.g. LEN = 0 */ 总结 CAN FD的新功能为满足了应用对更加高效的传输、更好实时性需求,但充分发挥这些功能还需要从应用开发到链路设计方面的优化。上面我们讨论简单地讨论一些注意事项,以及使用方法,具体的应用还要结合实际工况做调整。 参考: https://www.microcontrol.net/en/know-how/bus-systems/can-fd/ https://www.picoauto.com/library/picoscope/can-bus-serial-protocol-decoding https://www.can-cia.org/can-knowledge/can/can-fd/#:~:text=CAN%20FD%20data%20frames%20with,support%20remotely%20requested%20data%20frames.&text=The%20control%20field%20comprises%20additional,the%20Classical%20CAN%20data%20frames. https://www.eecs.umich.edu/courses/eecs461/doc/CAN_notes.pdf https://en.wikipedia.org/wiki/CAN_FD https://www.kvaser.com/wp-content/uploads/2016/04/can-fd-considerations-for-different-stakeholders.pdf https://www.kvaser.com/wp-content/uploads/2016/10/comparing-can-fd-with-classical-can.pdf
  • 热度 2
    2019-9-11 14:21
    4105 次阅读|
    1 个评论
    TJA1043简介
    一:基本信息 · TJA1043 是一个 CAN 收发器,位于 CAN 控制器和 BUS 之间。 · 支持 CAN FD 。在 CAN FD 模式下,速率可达 5Mbit/s 。 · 支持 12V 和 24V 系统。 · 两种封装。 SO14 和 HVSON14 。 二: Pin定义 · VCC: 给 Transimt 供电。电压范围 4.5~5.5V 。 · VIO: 给 I/O 口供电。电压 2.8~5.5V 。此 Pin 需要和 MCU 共用电源。这样 TXD,RXD,STB_N,EN,ERR_N 会和 MCU 有同样的逻辑电平。 · Vbat :直接连接在电池上。当整个系统都处于休眠状态,只有 CAN 内部一小部分活着。为了下一次的 wake up 。 Vbat 就是在此种状态下, CAN 中仍旧活着的那一小部分供电。 · GND · TXD: 这是一根信号输入 pin 。 · RXD: 这是一根信号输出 pin 。 · CANH/L: BUS 信号 · EN :使能输入 pin · INH :输出 pin 。控制 DUT 上电源模块使能 。 · ERR_N :输出 pin 。作为 Error 或者 power on 指示 pin , active 电压是 L 。 · WAKE :本地唤醒输入 pin 。 此 pin 是输入 pin 。它即可以侦测信号从 H 到 L 的变化,也可以侦测信号从 L 到 H 的变化。当侦测到有电平转换,即意味着 CAN 要被唤醒。 为了更好的 EMI 性能,建议此 pin 连接到 VBAT 或者 GND 。 · STB_N : Standby 输入 pin , active 电压是 L 。 · SPLIT :共模稳定输出 pin。 此 pin 连接到分离电阻终端网络,可以稳定 BUS 上的隐性电压。通过一个 DC 泄漏到 GND ,可以降低 EME (电磁辐射)。 在 Normal 和 Listen only mode ,此 pin 输出一个 0.5VCC 的直流电压。在其他三种模式下,它是 floating 的 。 三:电源相关 1. 操作电压 VCC=4.5~5. 5V VIO=2.8~5.5V 2. 耗电 (1) 针对 VCC 正常工作时,耗电最大值是 65mA 处于 Listen only 时,耗电最大 9mA 。 Standby 或者 sleep 状态时,耗电最大 2uA 。 (2) 针对 VIO 工作时,耗电最大 500uA Standby 或者休眠模式时,耗电最大 4uA 。 四:工作模式 1043 有 5 种工作模式。通过 STB_N 和 EN 去设置这些工作模式。 1. Normal mode 在此模式下, 1043 通过 CANH 和 CANL 接收或者发送数据。接收到的模拟差分信号,会被转换成数字信号通过 RXD 输出。 BUS pin 上有偏置电压,其值是 0.5VCC ,即 2.5V 。原因是 1043 的 Ri 造成。 Ri 是 1043 的输入阻抗。 1043 的单端输入阻抗是 9Kohm , 15Kohm , 28Kohm 。其差分阻抗是 19Kohm , 30Kohm , 52Kohm 。 INH 一直是 H 。即相关的电源都是打开的。 2. Listen only mode 在此模式下, 1043 的输出功能是 disable 的。仅仅只有接收功能。仍旧会将 CAN BUS 上的数据通过 RXD 输出到 MCU 。 仍旧还有 0.5VCC 的偏置, INH 也还是 H 。 3.Standby mode 这是一种省电模式。 1043 既不输出数据,也不接收数据。 1043 的 low power receiver 被激活去监控 bus 。 BUS 的偏置位于 GND level 。 INH 仍旧为 H ,即有其控制的相关电源仍旧打开着。 RXD 和 ERR_N 将映射出任何的 wake up 需求。需要提供 VIO 和 VBAT 。 4. Go to sleep mode 此模式是进入 sleep mode 的一个过渡阶段。在此模式下, 1043 的行为像 standby 模式,同时有 go to sleep 命令被传输到 1043. 在进入完全 sleep mode 之前, 1043 将处于 go to sleep mode 若干时间,此时间称为 Th ( min ),即 the Minimum hold time 。 在此时间之前,如果 STB_N 或者 EN 改变,或者 wake flag 被设置,则 1043 不会进入 go to sleep mode 。 5. Sleep mode 需要通过 go to sleep mode 进入 sleep mode ,并且在相关电压( VCC 活 VIO )恢复之前,侦测到 VCC or VIO 处于欠压已经一段时间了。 在此模式下, 1043 行为和 standby 一致,只是 INH 被设置为 floating 。所有 INH 控制的电源都处于 off 状态。进入 Vbat 的电流将被减低到最小。 通过 STB_N , EN 和 wake flag 可以将 node 唤醒从 sleep mode 。 五:2种wake up方式 1. Local wakeup 当 wake pin 有电平变化,并且新的电平持续时间大于 Twake 时,local wakeup被侦测到。 2. Remove wake up * 1043 在 standby or sleep 模式下,可以通过侦测 CAN BUS 上一组特殊的 wake up pattern ,唤醒自己。 * 这个测试 pattern 在 ISO11898-5:2007 中有定义。 * 有 滤波器 可以帮忙滤除假的 wake up pattern 。这些假的 pattern 是由于 BUS 上的噪声和毛刺引起的。 * 测试 Pattern 有三部分组成: · 一份显性信号,至少持续 Twake ( busdom ) · 一份隐性信号,至少持续 Twake ( busrec ) · 一份显性信号,至少持续 Twake ( busdom ) · 无论显性信号,还是隐性信号,只要时间短于上面的时间需求,都会被忽略。 * 完整的三段信号必须在 Tto ( wake ) bus 时间之内被接收并且识别。否则内部的 wake up 逻辑会被复位。接收到的完整的 wake up pattern 将会触发 wake up 事件。注意: RXD pin 一直保持高,直到 wake up 事件被触发,才会变 L 。 六:Local failures 1043 能侦测到 4 中 local failure 情况,同时会设置 local failures flag 。而且大多数情况下, 1043 的输出会被 disable 。 1. TXD dominant 超时 由于 HW 或者 SW 应用出错,导致在 TXD pin 上出现永久的 L level ,这将驱动 CAN BUS 进入永久的显性阶段,锁住整个网络通信。 TXD dominant time out 功能就是:当 TXD 保持 L 电平超过 Tto(dom)TXD 时,去 disable 发射机 ,阻止网络被锁。发射机会持续 disable ,直到 local failure flag 被清除。 2. TXD to RXD 短路侦测 当 RXD pin 和 TXD pin 之间短路时,一旦 bus 被驱动为显性,整个 bus 都会被锁在永久的显性状态。 原因是 RXD 的低边驱动能力一般都强于 TXD 的高边驱动能力。 当出现此种短路时,发射机会被 disable 。直到 local failure flag 被清除。 3.Bus 显性超时 当 CAN BUS 短路到 VBAT 、 VCC 或者 GND ,或者网络上其他节点出现 fail ,都会导致一个差分电压出现在 BUS 上,进而导致 BUS 处于显性状态。 当 BUS 处于显性状态,会导致任何一个 node 不能开始传输。一般的 BUS failure detection 不能侦测到这种失败,但是 bus dominant clamping (固定住) detection 可以侦测到此种失败。 当 BUS 处于显性状态超过 Tto ( dom ) bus , local failure flag 会被设置。通过检测此 flag ,控制器可以确定是否有一个钳位 bus 将网络通信锁住。不需要去 disable 发射机。 注意: local failure flag 不能保持此种 bus 显性 clamping failure ,同时会尽快让 BUS 回到隐性阶段。 4. 过温测试 当结温变的很大, 1043 将 shut down 去保护 输出设备 。 1043 将一直处于 disable 状态,直到此 local failure flag 被清除。 ------------------------------------------------------------------------------ 转载请说明出处。
  • 热度 5
    2016-4-18 20:10
    1710 次阅读|
    4 个评论
    一、 常见 CAN 收发器 TJA1042 的数据手册 TJA1042 datasheet中Block框图描述了收发器的内部结构:          Datasheet中还有关于split管脚的内部模型:          Datasheet的描述很简陋,但是可以用来构建简单的CAN收发器电路模型。 二、 CAN 收发器电路模型(仅用于简单的 DC 分析) 估计把下面的模型放出来,能把IC工程师气得吐血,乃至生活不能自理。 在此,向节假日依然奋战在IC工业的广大工程师指战员们表示慰问!下面的内容,如 此简单粗暴地简化你们复杂而伟大的工作,仅仅是为了DC分析某项小问题,不代表CAN收发器内部结构可以这样简单,     简单的内部结构如下:       使用Cadence公司PSpice仿真软件,可以得到CANH/CANL波形的仿真结果:          有了以上工作的基础,可以进行其它诸如总线CANH断线时波形分析等等问题的分析,免去计算等,可以直观地观察波形。   参考资料: TJA1042,Product data sheet,Rev. 7 — 8 May 2012 PSpice V16-5-13c
  • 热度 5
    2013-10-3 18:30
    812 次阅读|
    0 个评论
    Do we now need a solution better than JTAG? Hard real-time control software is increasingly common in terms of the number of different items in everyday life that use it. Many items that offer better safety, with equivalent or better energy efficiency, are now possible. But most of the people I know who have recently purchased a new piece of electronics, or a vehicle, or some other device have found at least one bug! It is becoming increasingly clear that, without help, JTAG-based ICE (in-circuit emulation) is not up to par on many of today's CPUs. Furthermore, JTAG testing and debugging does not allow one to test all the "at speed problems" one encounters in research and development or in production. This is forcing JTAG test escapes to be found by other means. The CAN bus (for controller area network) came out around the same time as JTAG, and both took time to gain momentum. This was when embedded Flash memory sizes were only a few hundred kilobytes in size. By comparison, modern automobiles and control systems use real-time stacks on 100mbp/sec Ethernet, and 1GHz (or higher) processors with many gigabytes of Flash memory, but they often still use only JTAG for debugging, Flash Loading (often only the boot loader), and partial production test. It is left for each chip maker and OS/OEM to come up with a full Flash load/debug solution on its own. Be it an MCU, an FPGA, or some other device, many are limited in one way or another by limitations in JTAG technology. Isn't it time we come up with a readily affordable, industry-wide solution? The thing is that bad debug and test capability can have a very real human cost. Allow me to relate a story that will illustrate my point... Back in the 90s I worked for an aerospace company designing police, fire, medevac, and special mission radios for helicopters and aircraft. We had one Intel ICE for the 8051. The ICE used the old "Bond Out" chip ICE technology. I was not there when the original code was developed and they first attempted to use this ICE. It was bad enough that we were out in a lab in the middle of the desert with a bad ICE. When we were not dealing with scorpions, poisonous centipedes, black widows, or the occasional side-winder that would craw into our lab (or up through the shower drain in the middle of getting ready for work) we had to find other, less venomous, but equally vexing, "bugs" by the time- honoured tradition of "Burn and Learn." What this meant was that we would "burn" a UV erasable version of the processor and then "learn" whether or not it would then burn out the transmitter. Dealing with ever-so-great equipment and angry customers that could fly in at any minute to lodge a complaint was never dull. It was also interesting having to handle walking, crawling poisonous bugs while we were frantically wrestling our own black widow's nest of a C compiler riddled with bugs coupled with a bad ICE. The ICE was so complicated to set up and get working—and the power in the lab went out so often—that it was damn near impossible to get it all running right before we lost power along with the working configuration. It was a race against time reminiscent of a "Dr. Who" episode. This was in the days of DOS, and there was no such thing as an uninterruptable power supply (UPS) for a PC and ICE, let alone a Flash memory in which to save the ICE configuration. This system had actually been designed to use a VT-100 terminal as the interface! Sadly, it had been made for a large corporation that could have easily afforded a plant-wide UPS. Furthermore, the company executives had all been fined for billing all kinds of executive perks to the government, so there was no money for a better ICE when one finally came out. William Murray Electrical Engineer
  • 热度 5
    2013-10-3 18:27
    752 次阅读|
    0 个评论
    Is a solution better than JTAG now necessary? Hard real-time control software is increasingly common in terms of the number of different items in everyday life that use it. Many items that offer better safety, with equivalent or better energy efficiency, are now possible. But most of the people I know who have recently purchased a new piece of electronics, or a vehicle, or some other device have found at least one bug! It is becoming increasingly clear that, without help, JTAG-based ICE (in-circuit emulation) is not up to par on many of today's CPUs. Furthermore, JTAG testing and debugging does not allow one to test all the "at speed problems" one encounters in research and development or in production. This is forcing JTAG test escapes to be found by other means. The CAN bus (for controller area network) came out around the same time as JTAG, and both took time to gain momentum. This was when embedded Flash memory sizes were only a few hundred kilobytes in size. By comparison, modern automobiles and control systems use real-time stacks on 100mbp/sec Ethernet, and 1GHz (or higher) processors with many gigabytes of Flash memory, but they often still use only JTAG for debugging, Flash Loading (often only the boot loader), and partial production test. It is left for each chip maker and OS/OEM to come up with a full Flash load/debug solution on its own. Be it an MCU, an FPGA, or some other device, many are limited in one way or another by limitations in JTAG technology. Isn't it time we come up with a readily affordable, industry-wide solution? The thing is that bad debug and test capability can have a very real human cost. Allow me to relate a story that will illustrate my point... Back in the 90s I worked for an aerospace company designing police, fire, medevac, and special mission radios for helicopters and aircraft. We had one Intel ICE for the 8051. The ICE used the old "Bond Out" chip ICE technology. I was not there when the original code was developed and they first attempted to use this ICE. It was bad enough that we were out in a lab in the middle of the desert with a bad ICE. When we were not dealing with scorpions, poisonous centipedes, black widows, or the occasional side-winder that would craw into our lab (or up through the shower drain in the middle of getting ready for work) we had to find other, less venomous, but equally vexing, "bugs" by the time- honoured tradition of "Burn and Learn." What this meant was that we would "burn" a UV erasable version of the processor and then "learn" whether or not it would then burn out the transmitter. Dealing with ever-so-great equipment and angry customers that could fly in at any minute to lodge a complaint was never dull. It was also interesting having to handle walking, crawling poisonous bugs while we were frantically wrestling our own black widow's nest of a C compiler riddled with bugs coupled with a bad ICE. The ICE was so complicated to set up and get working—and the power in the lab went out so often—that it was damn near impossible to get it all running right before we lost power along with the working configuration. It was a race against time reminiscent of a "Dr. Who" episode. This was in the days of DOS, and there was no such thing as an uninterruptable power supply (UPS) for a PC and ICE, let alone a Flash memory in which to save the ICE configuration. This system had actually been designed to use a VT-100 terminal as the interface! Sadly, it had been made for a large corporation that could have easily afforded a plant-wide UPS. Furthermore, the company executives had all been fined for billing all kinds of executive perks to the government, so there was no money for a better ICE when one finally came out. William Murray Electrical Engineer  
相关资源
广告