Doubt abt Minimum cycle transmit period for a CAN message with 500kbps

[ndk]

Hello everyone,

I want to confirm a scenario about .... the minimum transmit cycle period for my CAN Tx message.

For example, if I have a board with say HCS12(X) family MCU with 8 MHz crystal supporting the High speed CAN transceiver with 500 Kbps. Then what is the possible minimum cycle period for a CAN Tx message with 8 bytes of data length?

My assumption is .. since my baud rate is 500 kbps. So, the time to transmit a single bit to the CAN bus is (1/500 kbps) i.e. 2us. So, to transmit 8 bytes of Tx message, it can be 8*8*2us = 128us. So, can I send this CAN message from my board with a cycle period of say 200usec (which is below the 128us). ???

 Thankyou

nandu

[kef · Accepted solution]

In the best case data message with standard identifier consists of 44+8N bits. Message with extended identifier - 64+8*N bits. Where N - number of data bytes. But there also are stuff bits, which are inserted when CAN controller detects 5 consecutive identical 0 or 1 bits. With 44+8N=108 bits per message you can have up to ~108/5 = ~21 extra stuff bits (very worst case). So sending standard id message with 8data bytes worst case transfer at 500bps can take up to ~260us. Of course if there are other active nodes, you should take into account how long and how often thay will occupy CAN bus...

You may look for BOSCH CAN protocol standard (BCANPSV2.0.pdf) at Freescale site. For some reason Documentation tabs are empty at the moment.

[Lundin]

I'm not following this...

1 Start of frame
11message id
1 RTR
6 control field
8*N data
15 CRC
3 ack bits etc
7 end of frame
3 intermission

= 47 + 8*N, basic identifier

47 - 11 + 29 = 65 bits, extended identifier.

I can see that the number 44 comes from not counting intermission field as part of the message (although it should be part of the bandwidth calculation), but where did the number 64 for extended come from?

(Btw, bit stuffing isn't done on the ack bits, the end of frame nor the intermission field)

[kef]

You are right, I didn't take into account interframe space. So +3 recessive bits.

44+8N and 64+8N data frame lenghts I took from this document:

http://cache.freescale.com/files/microcontrollers/doc/data_sheet/BCANPSV2.pdf

See pdf pages 96 and 98.

Extended frame is longer than standard frame not by 29-11=18 bits. Standard frame RTR bit becomes SRR in extended frame, Extended frame adds new RTR bit. That's +1. Standard CAN V2.0 data frame has single reserved bit. Extended frame has 2 reserved bits. That's another +1. So extended data frame is longer by 20 bis.

[ndk]

Kef, 

again, thank you

I am cleared now. I completely forget about considering the Identifier, CRC and other stuff bits ......

thanks

nandu