Datasheet

Byte Data Link
MC9S12DP256 — Revision 1.1
Byte Data Link Controller Module
receivers for a message but the transmitter only wants to know that at
least one node received it. In this case, all receivers will begin
transmitting their node ID following the EOD. Since all nodes on an SAE
J1850 network have a unique node ID, if multiple nodes begin
transmitting their node ID simultaneously, arbitration takes place. The
node with the highest priority (lowest value) ID wins this arbitration
process, and that node’s ID makes up the IFR. No retries are attempted
by the nodes which lose arbitration during a Type 1 IFR transmission.
A Type 1 IFR can also be used as a response to a physically addressed
message, where the only intended receiver is the one which responds.
In this case, no arbitration would take place during the IFR transmission,
but the resulting IFR would still consist of a single byte.
IFR Type 2: Single
Byte from Multiple
Responders
The Type 2 IFR, as defined in SAE J1850, is a series of single bytes,
each transmitted by a different responder. This IFR type not only
acknowledges to the transmitter that the message was transmitted
successfully, but also reveals which receivers actually received the
message. As with the Type 1 IFR, no CRC byte is appended to the end
of a Type 2 IFR.
This IFR type is typically used with Function-type messages, where the
original transmitter may need to know which nodes actually received the
message. The basic difference between this type of IFR and the Type 1
IFR is that the nodes which lose arbitration while attempting to transmit
their node ID during a Type 2 IFR wait until the byte which wins
arbitration is transmitted and then again attempt to transmit their node ID
onto the bus. The result is a series of node IDs, one from each receiver
of the original message.
IFR Type 3: Multiple
Bytes from a Single
Responder
The last type of IFR defined by SAE J1850 is the Type 3 IFR. This IFR
type consists of one or more bytes from a single responder. This type of
IFR is used to return data to the original transmitter within the original
message frame. This type of IFR may or may not have a CRC byte
appended to it.
The Type 3 IFR is typically used with Function Read-type or Function
Query-type messages, where the original transmitter is requesting data
from the intended receiver. The node requesting the data transmits the
Freescale Semiconductor, I
Freescale Semiconductor, Inc.
For More Information On This Product,
Go to: www.freescale.com
nc...