The configurations of LIN Channel 1 and LIN Channel 2 are identical.
The LIN configuration is split into the following sections:
A LIN-bus consists of a Publisher node and one or more Subscriber nodes. The Publisher controls scheduling of messages on the LIN-bus, and the Subscriber nodes react to the emitted messages.
A message on the LIN-bus can either be a PUBLISH message, in which case Publisher node transmits both the message ID and data, or a SUBSCRIBE message, where the Publisher node only emits the message ID and one of the Subscriber nodes fill the data section of the message.
The configuration of the LIN network shall ensure that each message has one producer, such that each PUBLISH message is filled with data by the Publisher, while each SUBSCRIBE message has a node connected to the network which can provide the data for the message.
An example of the bus topology with the CANedge connected as a subscriber is illustrated below:
The CANedge is primarily intended to act as a Subscriber on the LIN-bus. In lieu of a Publisher node, the CANedge can be configured to emulate a simple Publisher node. In this case, the scheduling of messages on the network has to be done through the transmit configuration for the interface. Since only static data can be entered in the configuration, the simple Publisher node emulation cannot perform dynamic operations based on the LIN-bus activity.
Unless configured otherwise, the device assumes that the length of the LIN frame data payload is always defined by the message ID (bits 5 and 6 of the identifier), as defined in the table below:
This can be overridden in the configuration of the frame table.
Supports LIN 1.3 classic checksum and LIN 2.0 enhanced checksum format. By default, all frames except ID 0x3C and 0x3D use enhanced checksum. This can be overridden on a frame by frame basis in the configuration of the frame table.
The CANedge can detect and log errors on the LIN-bus if enabled in Logging configuration. The detected errors are categorized as follows:
The amount of associated data depends on the type of error. E.g. synchronization errors cannot contain information about the message ID, as it happens before that field is transmitted, and checksum information is not embedded in other cases than the checksum error case.
Checksum errors denotes that the node has calculated a different checksum than the one embedded in the LIN message on the bus. This can be an indicator of wrong configuration for the frame ID in the CANedge frame table.
Example: In case no information is known about the LIN bus in advance, the default frame table can be used with error logging enabled to help reverse engineer the actual frame table. Any message IDs deviating from the standard table (and present on the LIN-bus) will get a logged entry. These IDs can then be reconfigured in the CANedge frame table, in an attempt to find the correct settings.
Note that it can be necessary to change both message length and checksum model in order to get a valid configuration.
Receive errors are logged when a fixed part of the LIN message is not as expected, or that the node detects a mismatch between the value being transmitted and the value sensed on the LIN-bus.
Synchronization errors indicates an invalid synchronization field in the start of the LIN message, or that there is a too large deviation between the configured bitrate for the node and the detected bitrate from the synchronization field.
Transmission errors can only occur for IDs registered as SUBSCRIBER messages. If there is no node on the LIN-bus responding to a SUBSCRIBER message, a transmission error is logged.