ISO/DIS 17987-5

Road vehicles -- Local Interconnect Network (LIN)

Véhicules routiers -- Réseau Internet local (LIN)

Standards Content (sample)

DRAFT INTERNATIONAL STANDARD
ISO/DIS 17987-5
ISO/TC 22/SC 3 Secretariat: DIN
Voting begins on: Voting terminates on:
2014-01-10 2014-04-10
Road vehicles — Local Interconnect Network (LIN) —
Part 5:
Application Programmers Interface (API)
Véhicules routiers — Réseau Internet local (LIN) —
Partie 5: Interface du programmeur d’application (API)
ICS: 43.020
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENT AND APPROVAL. IT IS
THEREFORE SUBJECT TO CHANGE AND MAY
NOT BE REFERRED TO AS AN INTERNATIONAL
STANDARD UNTIL PUBLISHED AS SUCH.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
Reference number
NATIONAL REGULATIONS.
ISO/DIS 17987-5:2013(E)
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION. ISO 2013
---------------------- Page: 1 ----------------------
ISO/DIS 17987-5:2013(E)
Copyright notice

This ISO document is a Draft International Standard and is copyright-protected by ISO. Except as

permitted under the applicable laws of the user’s country, neither this ISO draft nor any extract

from it may be reproduced, stored in a retrieval system or transmitted in any form or by any means,

electronic, photocopying, recording or otherwise, without prior written permission being secured.

Requests for permission to reproduce should be addressed to either ISO at the address below or ISO’s

member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail [e-mail]
Web www.iso.org
Reproduction may be subject to royalty payments or a licensing agreement.
Violators may be prosecuted.
ii © ISO 2013 – All rights reserved
---------------------- Page: 2 ----------------------
ISO/DIS 17987-5
Contents Page

Foreword ............................................................................................................................................................ iv

Introduction ......................................................................................................................................................... v

1 Scope ...................................................................................................................................................... 1

2 Normative references ............................................................................................................................ 1

3 Terms, definitions, symbols and abbreviated terms ......................................................................... 1

3.1 Terms and definitions ........................................................................................................................... 1

3.2 Symbols .................................................................................................................................................. 2

3.3 Abbreviated terms ................................................................................................................................. 2

4 Conventions ........................................................................................................................................... 2

5 Document overview ............................................................................................................................... 3

6 Specification release version information .......................................................................................... 4

7 Requirements ......................................................................................................................................... 4

7.1 LIN cluster generation ........................................................................................................................... 4

7.2 Concept of operations .......................................................................................................................... 4

7.3 API conventions .................................................................................................................................... 5

7.4 Node configuration and identification ............................................................................................... 19

7.5 Transport layer .................................................................................................................................... 26

7.6 Examples .............................................................................................................................................. 32

Bibliography ...................................................................................................................................................... 36

© ISO 2013 – All rights reserved iii
---------------------- Page: 3 ----------------------
ISO/DIS 17987-5
Foreword

ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies

(ISO member bodies). The work of preparing International Standards is normally carried out through ISO

technical committees. Each member body interested in a subject for which a technical committee has been

established has the right to be represented on that committee. International organizations, governmental and

non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the

International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.

International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.

The main task of technical committees is to prepare International Standards. Draft International Standards

adopted by the technical committees are circulated to the member bodies for voting. Publication as an

International Standard requires approval by at least 75 % of the member bodies casting a vote.

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent

rights. ISO shall not be held responsible for identifying any or all such patent rights.

ISO 17987-5 was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 3,

Electrical and electronic equipment.

ISO 17987 consists of the following parts, under the general title Road vehicles — Local interconnect network

(LIN):
 Part 1: General information and use case definition
 Part 2: Transport protocol and network layer services
 Part 3: Protocol specification
 Part 4: Electrical Physical Layer (EPL) specification 12 V/24 V
 Part 5: Application Programmers Interface (API)
 Part 6: Protocol conformance test specification
 Part 7: Electrical Physical Layer (EPL) conformance test specification
iv © ISO 2013 – All rights reserved
---------------------- Page: 4 ----------------------
ISO/DIS 17987-5
Introduction

This document set specifies the use cases, the communication protocol and physical layer requirements of an

in-vehicle communication network called "Local Interconnect Network (LIN)".

The Local interconnect network (LIN) protocol as proposed is an automotive focused low speed UART-based

network (Universal Asynchronous Receiver Transmitter). Some of the key characteristics of the LIN protocol

are signal based communication, schedule table based frame transfer, master/slave communication with error

detection, node configuration and diagnostic service transportation.

The LIN protocol is for low cost automotive control applications, for example door module and air condition

systems. It serves as a communication infrastructure for low-speed control applications in vehicles by

providing:

 Signal based communication to exchange information between applications in different nodes;

 Bitrate support from 1 kbps to 20 kbps;
 Deterministic schedule table based frame communication;

 Network management that wakes up and puts the LIN cluster into sleep mode in a controlled manner;

 Status management that provides error handling and error signalling;

 Transport layer that allows large amount of data to be transported (such as diagnostic services);

 Specification of how to handle diagnostic services;
 Electrical physical layer specifications;
 Node description language describing properties of slave nodes;
 Network description file describing behaviour of communication;
 Application programmer's interface;

To achieve this, it is based on the Open Systems Interconnection (OSI) Basic Reference Model specified in

ISO/IEC 7498-1 and ISO/IEC 10731, which structures communication systems into seven layers. When

mapped on this model, the protocol and physical layer requirements specified by ISO 17987 are structured

according to Table°1.
© ISO 2013 – All rights reserved v
---------------------- Page: 5 ----------------------
ISO/DIS 17987-5
Table°1°—°LIN specifications applicable to the OSI layers
Vehicle manufacturer
Applicability OSI seven layer LIN
enhanced diagnostics
Application (layer 7) ISO 17987-1, ISO 17987-5 ISO°14229-1, ISO°14229-7
Presentation (layer 6) ISO 17987-5 vehicle manufacturer specific
Session (layer 5) ISO 17987-3 ISO°14229-2
Seven layer according to
ISO°7498-1
Transport (layer 4)
and
ISO 17987-2
ISO/IEC 10731
Network (layer 3)
Data link (layer 2) ISO 17987-3, ISO 17987-6
Physical (layer 1) ISO 17987-4, ISO 17987-7

Table°1 shows ISO 17987 Parts 2, 3, 4, 6 and 7 being the common standards for the OSI layers 1 through 3

for LIN and the vehicle manufacturer enhanced diagnostics.

The vehicle manufacturer enhanced diagnostics column shows application layer services covered by

ISO 14229-7 which have been defined in compliance with diagnostic services established in ISO 14229-1, but

are not limited to use only with them. ISO 14229-7 is also compatible with most diagnostic services defined in

national standards or vehicle manufacturer's specifications. The presentation layer is defined vehicle

manufacturer specific. The session layer services are covered by ISO 14229-2. The transport protocol and

network layer services are specified in ISO 17987-2.
vi © ISO 2013 – All rights reserved
---------------------- Page: 6 ----------------------
DRAFT INTERNATIONAL STANDARD ISO/DIS 17987-5
Road vehicles — Local interconnect network (LIN) — Part 5:
Application Programmers Interface (API)
1 Scope

This part of ISO 17987 has been established in order to define the LIN Application Programmers Interface

(API). The LIN API is a network software layer that hides the details of a LIN network configuration (e.g. how

signals are mapped into certain frames) for a user making an application program for an arbitrary ECU. The

user will be provided an API, which is focused on the signals transported on the LIN network. A tool takes care

of the step from network configuration to program code. This will provide the user with configuration flexibility.

This document defines a mandatory interface to a software LIN device driver implemented in the 'C'

programming language. Thus, hardware implementations are not standardized nor are implementations in

other programming languages.
2 Normative references

The following referenced documents are indispensable for the application of this document. For dated

references, only the edition cited applies. For undated references, the latest edition of the referenced

document (including any amendments) applies.

ISO 17987-1, Road vehicles – Local interconnect network (LIN) – Part 1: General information and use case

definition

ISO 17987-2, Road vehicles – Local interconnect network (LIN) – Part 2: Transport protocol and network layer

services

ISO 17987-3, Road vehicles – Local interconnect network (LIN) – Part 3: Protocol specification

ISO 17987-4, Road vehicles – Local interconnect network (LIN) – Part 4: Electrical Physical Layer (EPL)

specification 12 V/24 V

ISO 17987-6, Road vehicles – Local interconnect network (LIN) – Part 6: Protocol conformance test

specification

ISO 17987-7, Road vehicles – Local interconnect network (LIN) – Part 7: Electrical Physical Layer (EPL)

conformance test specification
3 Terms, definitions, symbols and abbreviated terms
3.1 Terms and definitions

For the purposes of this document, the terms and definitions in ISO 17987-2, ISO 17987-3 and ISO 17987-4

apply.
© ISO 2013 – All rights reserved 1
---------------------- Page: 7 ----------------------
ISO/DIS 17987-5
3.2 Symbols
|| logical OR binary operation
3.3 Abbreviated terms
AC alternate current
API application programmers interface
ms millisecond
OSI open systems interconnection
PDU protocol data unit
RX Rx pin of the transceiver
UART universal asynchronous receiver transmitter
4 Conventions

ISO 17987 and ISO 14229-7 [5] are based on the conventions specified in the OSI Service Conventions

(ISO/IEC°10731) [2] as they apply for physical layer, protocol, network & transport protocol and diagnostic

services.
2 © ISO 2013 – All rights reserved
---------------------- Page: 8 ----------------------
ISO/DIS 17987-5
5 Document overview
Figure°1 illustrates the document reference according to OSI model.
ISO 17987-1
LIN - General
information and
use case definition
Enhanced Diagnostics
LIN
ISO 17987-5
ISO 14229-1 UDS
LIN – Application
ISO 14229-7
Specification and
subset
OSI Layer 7 Programmers
UDSonLIN
requirements
Application
Interface (API)
ISO 17987-5
Vehicle
LIN – Application
manufacturer
OSI Layer 6
Programmers
specific
Presentation
Interface (API)
ISO 17987-3
ISO 14229-2 UDS ISO 14229-2 UDS
1 : 1 LIN – Protocol
Session layer Session layer
OSI Layer 5
services services specification
Session
Standardized Service Primitive Interface
Local interconnect network (LIN)
OSI Layer 4
Transport
ISO 17987-2
LIN –
Transport protocol and network layer services
OSI Layer 3
Network
ISO 17987-6
ISO 17987-3
LIN – Protocol
LIN – Protocol
OSI Layer 2
conformance test
specification
Data Link
specification
ISO 17987-4 ISO 17987-7
LIN – Electrical LIN – Electrical
Physical Layer (EPL) Physical Layer (EPL)
OSI Layer 1
specification conformance test
Physical
12V/24V specification
Figure°1°— LIN document reference according to OSI model
© ISO 2013 – All rights reserved 3
---------------------- Page: 9 ----------------------
ISO/DIS 17987-5
6 Specification release version information
The specification release version of this part of ISO 17987 is: 2.2.
7 Requirements
7.1 LIN cluster generation

The LIN Description file (LDF) (see ISO 17987-2) is parsed by a tool and generates a configuration for the LIN

device driver. The Node Capability Language specification (NCF) is normally not used in this process since its

intention is to describe a hardware slave node, and therefore, does not need the API. See ISO 17987-2 for a

description of the workflow and the roles of the LDF and NCF.
7.2 Concept of operations
7.2.1 General
The API is split in three areas:
 LIN core API,
 LIN node configuration and identification API,
 LIN transport layer API (optional).
7.2.2 LIN core API

The LIN core API handles initialization, processing and a signal based interaction between the application and

the LIN core. This implies that the application does not have to bother with frames and transmission of frames.

Notification exists to detect transfer of a specific frame if this is necessary, see 7.3.5. API calls to control the

LIN core also exist.
Two versions exist of most of the API calls

 Static calls embed the name of the signal or interface in the name of the call, and

 Dynamic calls provide the signal or interface as a parameter.

NOTE The named objects (signals, schedules) are defined in the LDF may extend their names with the channel

postfix name (see channel postfix name definition in ISO 17987-2).
7.2.3 LIN node configuration and identification API

The LIN node configuration and identification API is service-based (request/response), i.e., the application in

the master node calls an API routine that transmits a request to the specified slave node and awaits a

response. The slave node device driver automatically handles the service.

The behaviour of the LIN node configuration and identification API is covered in the node configuration and

identification (see ISO 17987-3).
7.2.4 LIN transport layer API

The LIN transport layer is message based. Its intended use is to work as a transport layer for messages to a

diagnostic message parser outside of the LIN device driver. Two exclusively alternative APIs exist one raw

that allows the application to control the contents of every frame sent and one messaged-based that performs

the full transport layer function.
4 © ISO 2013 – All rights reserved
---------------------- Page: 10 ----------------------
ISO/DIS 17987-5
The behaviour of the LIN transport layer API is defined in ISO 17987-2.
7.3 API conventions
7.3.1 General

The LIN core API has a set of functions all based on the idea to give the API a separate name space, in order

to minimize the risk of conflicts with existing software. All functions and types will have the prefix "l_"

(lowercase "L" followed by an "underscore").
Table°2°—°API functions overview
Function Description
DRIVER AND CLUSTER MANAGEMENT
l_sys_init l_sys_init performs the initialization of the LIN core.
SIGNAL INTERACTION
scalar signal read Reads and returns the current value of the signal.
scalar signal write Reads and returns the current value of the signal.

byte array read Reads and returns the current values of the selected bytes in the signal.

byte array write Sets the current value of the selected bytes in the signal specified by the name sss to

the value specified.
NOTIFICATION

l_flg_tst Returns a C boolean indicating the current state of the flag specified by the name of the

static API call, i.e. returns zero if the flag is cleared, non-zero otherwise.

l_flg_clr Sets the current value of the flag specified by the name of the static API call to zero.

SCHEDULE MANAGEMENT
l_sch_tick The l_sch_tick function follows a schedule.

l_sch_set Sets up the next schedule to be followed by the l_sch_tick function for a certain

interface.
INTERFACE MANAGEMENT

l_ifc_init l_ifc_init initializes the controller specified by the name, i.e. sets up internal functions

such as the baud rate.

l_ifc_goto_sleep This call requests slave nodes on the cluster connected to the interface to enter bus

sleep mode by issuing one go to sleep command.
l_ifc_wake_up The function will transmit one wake up signal.

l_ifc_ioctl This function controls functionality that is not covered by the other API calls.

l_ifc_rx The application program is responsible for binding the interrupt and for setting the

correct interface handle (if interrupt is used).

l_ifc_tx The application program is responsible for binding the interrupt and for setting the

correct interface handle (if interrupt is used).

l_ifc_aux This function may be used in the slave nodes to synchronize to the break/sync field

sequence transmitted by the master node on the interface specified by iii.

l_ifc_read_status This function will return the status of the previous communication.

© ISO 2013 – All rights reserved 5
---------------------- Page: 11 ----------------------
ISO/DIS 17987-5
Table°2°—°(continued)
Function Description
USER PROVIDED CALL-OUTS

l_sys_irq_disable The user implementation of this function shall achieve a state in which no interrupts

from the LIN communication can occur.

l_sys_irq_restore The user implementation of this function shall restore the interrupt level identified by the

provided l_irqmask previous.
NODE CONFIGURATION

ld_is_ready This call returns the status of the last requested configuration service.

ld_check_response This call returns the result of the last node configuration service.

ld_assign_frame_id_range This call assigns the protected identifier of up to four frames in the slave node with the

addressed NAD.

ld_assign_NAD This call assigns the NAD (node diagnostic address) of all slave nodes that matches the

initial_NAD, the supplier ID and the function ID.

ld_save_configuration This call will make a save configuration request to a specific slave node with the given

NAD, or to all slave nodes if NAD is set to broadcast.

ld_read_configuration This call will serialize the current configuration and copy it to the area (data pointer)

provided by the application.

ld_set_configuration The function will configure the NAD and the PRIDs according to the configuration given

by data.

ld_conditional_change_NAD This call changes the NAD if the node properties fulfil the test specified by id, byte,

mask and invert.
IDENTIFICATION

ld_read_by_id The call requests the slave node selected with the NAD to return the property

associated with the id parameter.

ld_read_by_id_callout This callout is used when the master node transmits a read by identifier request with an

identifier in the user defined area.
INITIALIZATION

ld_init This call will (re)initialize the raw and the messaged-based layers on the interface.

RAW API

ld_put_raw The call queues the transmission of 8 bytes of data in one frame. The data is sent in the

next suitable frame.

ld_get_raw The call copies the oldest received diagnostic frame data to the memory specified by

data.

ld_raw_tx_status The call returns the status of the raw frame transmission function.

ld_raw_rx_status The call returns the status of the raw frame receive function.
MESSAGE-BASED API

ld_send_message The call packs the information specified by data and DataLength into one or multiple

diagnostic frames.

ld_receive_message The call prepares the LIN diagnostic module to receive one message and store it in the

buffer pointed to by data.

ld_tx_status The call returns the status of the last made call to ld_send_message.

ld_rx_status The call returns the status of the last made call to ld_receive_message.

6 © ISO 2013 – All rights reserved
---------------------- Page: 12 ----------------------
ISO/DIS 17987-5
7.3.2 Data types
The LIN core shall define the following types:
 l_bool 0 is false, and non-zero (> 0) is true,
 l_ioctl_op implementation dependent,
 l_irqmask implementation dependent,
 l_u8 unsigned 8 bit integer,
 l_u16 unsigned 16 bit integer.

In order to gain efficiency, the majority of the functions will be static functions (no parameters are needed,

since one function exist per signal, per interface, etc.).
7.3.3 Driver and cluster management
7.3.3.1 l_sys_init
Table 3 defines the l_sys_init.
Table 3 — l_sys_init
Prototype l_bool l_sys_init (void)
Applicability Master and slave nodes.

Description l_sys_init performs the initialization of the LIN core. The scope of the initialization is the

physical node i.e., the complete node (see node composition definition in ISO 17987-2).

The call to the l_sys_init is the first call a user shall use in the LIN core before using any other

API functions.
Return value Zero if the initialization succeeded.
Non-zero if the initialization failed.
7.3.4 Signal interaction

In all signal API calls below the sss is the name of the signal, e.g. l_u8_rd_engine speed ().

7.3.4.1 Signal types
The signals will be of three different types:
 l_bool for one bit signals; zero if false, non-zero otherwise,
 l_u8 for signals of the size 2 – 8 bits,
 l_u16 for signals of the size 9 – 16 bits.
© ISO 2013 – All rights reserved 7
---------------------- Page: 13 ----------------------
ISO/DIS 17987-5
7.3.4.2 Scalar signal read
Table 4 defines the scalar signal read.
Table 4 — Scalar signal read
Dynamic prototype
l_bool l_bool_rd (l_signal_handle sss);
l_u8 l_u8_rd (l_signal_handle sss);
l_u16 l_u16_rd (l_signal_handle sss);
Static prototype
l_bool l_bool_rd_sss (void);
l_u8 l_u8_rd_sss (void);
l_u16 l_u16_rd_sss (void);
Applicability Master and slave nodes.
Description Reads and returns the current value of the signal.
Reference
See signal types in ISO 17987-3.
7.3.4.3 Scalar signal write
Table 5 defines the scalar signal write.
Table 5 — Scalar signal write
Dynamic prototype void l_bool_wr (l_signal_handle sss, l_bool v);
void l_u8_wr (l_signal_handle sss, l_u8 v);
void l_u16_wr (l_signal_handle sss, l_u16 v);
Static prototype void l_bool_wr_sss (l_bool v);
void l_u8_wr_sss (l_u8 v);
void l_u16_wr_sss (l_u16 v);
Applicability
Master and slave nodes.
Description
Sets the current value of the signal to v.
Reference See signal types in ISO 17987-3.
7.3.4.4 Byte array read
Table 6 defines the byte array read.
8 © ISO 2013 – All rights reserved
---------------------- Page: 14 ----------------------
ISO/DIS 17987-5
Table 6 — Byte array read
Dynamic prototype
void l_bytes_rd (l_signal_handle sss,
l_u8 start, /* first byte to read from */
l_u8 count, /* number of bytes to read */
l_u8* const data); /* where data will be written */
Static prototype void l_bytes_rd_sss (l_u8 start,
l_u8 count,
l_u8* const data);
Applicability Master and slave nodes.
Description

Reads and returns the current values of the selected bytes in the signal. The sum of start and

count shall never be greater than the length of the byte array.

Example Assume that a byte array is 6 bytes long, numbered 0 to 5. Reading byte 2 and 3 from this

array requires the start to be 2 (skipping byte 0 and 1) and count to be 2 (reading byte 2 and

3). In this case byte 2 is written to data [0] and byte 3 is written to data [1].

Reference See signal types in ISO 17987-3.
7.3.4.5 Byte array write
Table 7 defines the byte array write.
Table 7 — Byte array write
Dynamic prototype void l_bytes_wr (l_signal_handle sss,
l_u8 start, /* first byte to write to */
l_u8 count, /* number of bytes to write */
const l_u8* const data); /* where data is read from */
Static prototype void l_bytes_wr_sss (l_u8 start,
l_u8 count,
const l_u8* const data);
where sss is the name of the signal, e.g. l_bytes_wr_EngineSpeed ().
Applicability
Master and slave nodes.

Description Sets the current value of the selected bytes in the signal specified by the name sss to the

value specified.

The sum of start and count shall never be greater than the length of the byte array, although

the device driver may choose not to enforce this in runtime.

Example Assume that a byte array is 7 bytes long, numbered 0 to 6. Writing byte 3 and 4 from this

array requires the start to be 3 (skipping byte 0, 1 and 2) and count to be 2 (writing byte 3 and

4). In this case byte 3 is read from data [0] and byte 4 is read from data [1].
Reference
See signal types in ISO 17987-3.
© ISO 2013 – All rights reserved 9
---------------------- Page: 15 ----------------------
ISO/DIS 17987-5
7.3.5 Notification

Flags are local objects in a node and they are used to synchronize the application program with the LIN core.

The flags will be automatically set by the LIN core and can only be tested or cleared by the application

program. Flags may be attached to all types of frames. A flag is set when the frame/signal is considered to be

transmitted respectively received, see reception and transmission in ISO 17987-3.

Three types of flags can be created:
 a flag that is attached to a signal,
 a flag that is attached to a frame,

 a flag that is attached to a signal in a particular frame. This is used when a signal is packed into multiple

frames.

All three listed flag types above are applicable on both transmitted and received signals/frames.

7.3.5.1 l_flg_tst
Table 8 defines the I_flg_tst.
Table 8 — I_flg_tst
Dynamic prototype l_bool l_flg_tst (l_flag_handle fff)
Static prototype
l_bool l_flg_tst_fff (void);
Where fff is the name of the flag, e.g. l_flg_tst_RxEngineSpeed ().
Applicability Master and slave nodes.

Description Returns a C boolean indicating the current state of the flag specified by the name fff, i.e.

returns zero if the flag is cleared, non-zero otherwise.
Example

A flag, named tx confirmation, is attached to a published signal valve position stored in the

IO_1 frame. The static implementation of the l_flg_tst will be:
l_bool l_flg_tst_txconfirmation (void);

The flag will be set when the IO_1 frame (containing the signal valve position) is successfully

transmitted from the node.
Reference No reference, flags are API specific and not described anywhere else.
10 © ISO 2013 – All rights reserved
---------------------- Page: 16 ----------------------
ISO/DIS 17987-5
7.3.5.2 l_flg_clr
Table 9 defines the l_flg_clr.
Table 9 — l_flg_clr
Dynamic prototype
void l_flg_clr (l_flag_handle fff);
Static prototype void l_flg_clr_fff (void);
Where fff is the name of the flag, e.g. l_flg_clr_RxEngineSpeed ().
Applicability Master and slave nodes.

Description Sets the current value of the flag specified by the name fff to zero.

Reference No reference, flags are API specific and not described anywhere else.
7.3.6 Schedule management
7.3.6.1 l_sch_tick
Table 10 defines the l_sch_tick.
Table 10 — l_sch_tick
Dynamic prototype l_u16 l_sch_tick (l_ifc_handle iii);
Static prototype l_u16 l_sch_tick_iii (void);
where iii is the name of the interface, e.g. l_sch_tick_MyLinIfc ().
Applicability Master nodes only.
Description

The l_sch_tick function follows a schedule. When a frame becomes due, its transmission is

initiated. When the end of the current schedule is reached, l_sch_tick starts again at the

beginning of the schedule.

The l_sch_tick shall be called periodically and individually for each interface wit

...