CAN transceiver interconnection to MCU (Tx, Rx and propagation delay)

candelaymicrocontrollerpropagationtransceiver

I am working on a CAN transceiver and its connection to a microcontroller (hardware perspective only.)

Referring this appnote – What is CAN?

My questions:

enter image description here

  1. In the above image, I see the CAN transceiver connections to the MCU. I have seen UART communications where Tx is connected to Rx and vice vera for proper transmission of data, but there seems to be an exception with the CAN communication protocol. Why is Tx connected to Tx and Rx connected to Rx? Can someone help me to understand why is this exception?
    Are there exceptions like this for any other protocol?

  2. In both the microcontroller and the transceiver, Tx is connected to Tx and Rx is connected to Rx. How should I understand this? From the diagram, thevRXD pin from the transceiver transmits the data to microcontroller and the TXD pin of the transceiver receives from the microcontroller. Is my understandng correct? From which perspective should we understand the transmit and receive parameters? Should the Tx and Rx parameters always be from the microcontroller point of view?

  3. I am using this transceiver IC – TLE7263E

enter image description here

I can understand the dominant and recessive states on the CAN bus, but I am not able to understand the above table of propagation delays.

I tried to correlate the table with the Fig.20 CAN dynamic characteristices timing diagram on page 56 but it is not clear to me.

Can someone help me to understand each parameter of the propagation delay table and Fig.20?

Best Answer

Why is Tx connected to Tx and Rx connected to Rx.

Luckily, CAN did not repeat the mistakes of UART.

For UART communication, you need to consider if a node is a "modem" or a "terminal", that is if it's in the middle of the bus or at the end of it. Pairing Tx from one terminal with Rx of the other terminal and so on. As everyone who have worked with UART knows, Murphy's law applies with 100% accuracy: you always get Rx and Tx wrong, no matter how much planning you do. It's like a curse - the UART signal system was simply not a good idea.

There's no such thing as "modem vs terminal" in CAN. The actual signal on CANH/CANL is semi-duplex on the same wire. Tx/Rx in CAN is just a local affair between the controller and the transceiver.

In Both MCU and Transceiver, Tx is connected to Tx and Rx is connected to Rx. So how to understand this?

There's not much to understand, your picture is great, it shows exactly how it works. Tx and Rx are just signal names, named after the CAN controller (MCU) side of things.

But I am not able to understand the above table of propagation delays

I'm not the right person to explain all the dirty details of this, but as mentioned in comments, one probably doesn't need to know. As with any data communication, you have a propagation delay along the whole bus including circuits, but is most likely negligible in most CAN applications, unless you have extreme real-time specs (nanosecond accuracy). CAN bit clocking uses a "propagation segment" with built-in tolerance for these delays.

What's far more important to consider is your CAN controller clock source. This should be a fairly high quality one with at least 1.5% accuracy. Quartz oscillators are strongly recommended, particularly for the higher baudrates.

Related Topic