The format of the message frames is to be found in detail in the Bosch specifications or in less detail in the omega.co.uk, stuff and the Kvaser website. The standard CAN (2.0A) frame has an 11 bit identifier, while an extended CAN (2.0B) frame has a 29 bit identifier, for compatibility with other protocols used in the US vehicle industry.
The standard identifier format allows for 2032 nodes on the network (2 to 11 =- 2 to 7) and the extended identifier allows more, but as the extra 18 identifier bits are needed for compatibility with other protocols, their use is restricted. The SAE J2284-500 standard [4] allows for any number of nodes between 2 and 16, inclusive, which doesn’t seem many.
A 2.0A compliant device will flag an error if presented with a 2.0B message, unless it is “2.0B passive”, when it will tolerate, but ignore, messages in 2.0B format. 2.0B devices are backward compatible, and can transmit and receive messages in either format. The RTR field (set to 1 if the message is a request for information) follows the identifier. As such a “remote request” frame uses the identifier of the source of the required data, this means that data takes precedence over a request for that data, but a request for high priority data takes precedence over lower priority data. These remote request frames are apparently rarely used. The identifier field and RTR field are used in collision resolution.
The data field can contain from zero to eight bytes, its length being stated by a 4 bit DLC field that immediately precedes the data field.
The data field is followed by a 15 bit cyclic redundancy check, a delimiter, acknowledgement field and end of frame and intermission fields। After these and a set idle time (which may be zero) another node can start transmission।
0 Comments:
Post a Comment