| Electronic Components Datasheet Search |
|
AN754 Datasheet(PDF) 4 Page - Microchip Technology |
|
|
|||||||||||||||||||||||||||||
AN754 Datasheet(HTML) 4 Page - Microchip Technology |
|
4 / 13 page ![]() AN754 DS00754A-page 4 2001 Microchip Technology Inc. SYNCHRONIZING THE BIT TIME All nodes on the CAN bus must have the same nominal bit rate. Noise, phase shifts, and oscillator drift create situations where the nominal bit rate does not equal the actual bit rate in a real system. Therefore, the nodes must have a method for achieving and maintaining syn- chronization with bus messages. Oscillator Tolerance The bit timing for each node in a CAN system is derived from the reference frequency (fOSC) of its node. This creates a situation where phase shifting and oscillator drift will occur between nodes due to less than ideal oscillator tolerances between the nodes. The CAN specification indicates that the worst case oscillator tolerance is 1.58% and is only suitable for low bit rates (125 kb/s or less). This application note does not cover oscillator tolerances in detail, however, the references at the end of this application note provide more information on the subject. Propagation Delay The CAN protocol has defined a recessive (logic 1) and dominant (logic 0) state to implement a non-destructive bit-wise arbitration scheme. It is this arbitration method- ology that is affected the most by propagation delays. Each node involved with arbitration must be able to sample each bit level within the same bit time. For example, if two nodes at opposite ends of the bus start to transmit their messages at the same time, they must arbitrate for control of the bus. This arbitration is only effective if both nodes are able to sample during the same bit time. Figure 4 shows a one-way propagation delay between two nodes. Extreme propagation delays (beyond the sample point) will result in invalid arbitra- tion. This implies that bus lengths are limited at given CAN data rates. A CAN system’s propagation delay is calculated as being a signal’s round trip time on the physical bus (tbus), the output driver delay (tdrv), and the input com- parator delay (tcmp). Assuming all nodes in the system have similar component delays, the propagation delay is explained mathematically as: Synchronization All nodes on a given CAN bus must have the same NBT. The NRZ bit coding does not encode a clock into the message. The receivers must synchronize to the transmitted data stream to insure messages are prop- erly decoded. There are two methods used for achiev- ing and maintaining synchronization. HARD SYNCHRONIZATION Hard Synchronization only occurs on the first reces- sive-to-dominant (logic “1” to “0”) edge during a bus idle condition, which indicates a Start-of-Frame (SOF) con- dition. Hard synchronization causes the bit timing counter to be reset to the SyncSeg which causes the edge to lie within the SyncSeg. At this point, all of the receivers will be synchronized to the transmitter. Hard synchronization occurs only once during a mes- sage. Also, resynchronization may not occur during the same bit time (SOF) that hard synchronization occurred. tprop 2tbus tcmp tdrv ++ () ⋅ = |
|
|
Link URL |
| Does ALLDATASHEET help your business so far? [ DONATE ] |
About Alldatasheet | Advertisement | Contact us | Privacy Policy | Link to Datasheet | Link Exchange | Manufacturer List All Rights Reserved©Alldatasheet.com |
| Russian : Alldatasheetru.com | Korean : Alldatasheet.co.kr | Spanish : Alldatasheet.es | French : Alldatasheet.fr | Italian : Alldatasheetit.com Portuguese : Alldatasheetpt.com | Polish : Alldatasheet.pl | Vietnamese : Alldatasheet.vn Indian : Alldatasheet.in | Mexican : Alldatasheet.com.mx | British : Alldatasheet.co.uk | New Zealand : Alldatasheet.co.nz |
|
Family Site : ic2ic.com |
icmetro.com |