CAN and CAN FD protocol

[@moliendo102]

Very clear and comprehensive explanation. Thank you for putting so much diligence, into making the course accessible and thorough enough. Such results are achieved only with genuine dedication. Thank you very much for clear & in-depth explanation !!!

[@tarekmohsen7572]

Thank you. It is the first video from alot of videos i watched before where i understand the CAN bus

[@Gattuser]

Excellent video indeed, slides and images are very helpful

[@parvathik7733]

Precise and upto the point explanation.Thank you.

[@LordPhobos6502]

This video ia excellent. Very clear explainations of what's happening within the protocol. One question, what exactly does a data request frame look like? Does it have just the address requested and the RTR bit recessive, or does it have everything, with a 0 byte data section? Thankyou again for these CANbus videos, they're really clear, and enjoyable.

[@JetNmyFuture]

off to order some parts from DigiKey now......My next system design is expected to be all CAN. Thanks for the confidence builder.

[@vrajalingam3487]

Simple and best explanation , Thanks

[@youssefbenmouhou9030]

the explanation is very good and exhaustive, I just have a question, for the error frame is it sent in the place of ACK bit

[@Avionics2]

Beautifully explained 👏👏👍👍

[@robertsimpson4412]

The arbitration relies on the nodes being synchronized but it's not clear to me whether they are synchronized at the bit level or at the frame level. Is it correct to say the synchronization works at the bit level and the start bit ensures that one node will not start transmitting after another node has started? (Obviously the arbitration is required if 2 or more nodes start transmitting at the same bit interval.)

[@thecannetwork7559]

That was excellent and such a genius technology

[@Mr8999naga]

At 11:59 I didn't complely get it For 0000011110 bit stuffing happens 00000 1 1111 0 0 twice. While destuffing how it is handled ? Because while destuffing it's already destuffed the recessive bit.

[@commandermclovin4633]

But the reciever does not compare along what he was destuffing, but what was recieved ;) Just count on the incomming bits. BTW: Great attention to such a detail!

[@chu1754]

This is very helpful. Thanks

[@eduardoflores98]

If my car doesn’t have can FD is worth to buy an a scanner that is can fd is compatible?

[@w4drone720]

No?

[@purushothamakm2812]

very very nice explanation

[@sujithan6100]

Can you share a video on CAN Network Management

[@Kartheek-pu8hm]

what is maximum interframe space can be ?

[@mahmoudismail2760]

This is really Awesome! Are there any explanation but for Ethernet

[@watermelonpuppet3963]

I've seen a lot of different sources mentioning that the IFS should be 3-bits long. However according to this video and some of the other TI documents, it is said to be 7-bits long. Is it intended?

[@rexoplans1]

Since it is not defined in the Bosch specification, it is normal for it to vary from company to company. Since there is no effective bit on the message, it can be 3 bits or 10 bits.

[@xealit]

but what serves as the address of the frame? Is it the priority id? Then, if a node requests data from another one, it puts the id of the addressee? What if the addressee is sending at the same time? Then the priority ids of the frames will be identical. Does it mean that the arbitration is solved by the request bit in this case? Also, in the request frame, can it include something like a "register address" from a node? Or 1 node is always only 1 source of data?

[@TexasInstruments]

Hi @xealit, thanks for your interest! You can search our TI E2E Support Forums for an answer to your question here: e2e.ti.com

[@shivendrayadav18]

Thanku so much

[@eccentricOrange]

Excellent

[@mahn78]

Great