LIN Middleware 2.0.0.1261
 
Loading...
Searching...
No Matches
LIN Middleware

Overview

LIN middleware implements LIN 2.2 Slave node for PSOC 4 devices. Options for ISO 17987 compliance are also available. The LIN Configurator and Device Configurator facilitate configuring the middleware.

Features:

  • Full LIN 2.2 Slave Node implementation
  • Compliance with ISO 17987 specification
  • Full transport layer support
  • Automatic baud rate synchronization
  • Automatic detection of bus inactivity
  • Automatic configuration services
  • Fully implements a Diagnostic Class I Slave Node
  • Supports implementation of Diagnostic Class II and III Slave Node
  • Full error detection
  • LIN Configurator

General Description

Include mtb_lin.h to get access to all the functions and other declarations in this middleware.
The middleware uses the SCB UART hardware with built-in LIN support to implement the physical layer.

See the Quick Start Guide to start using the middleware.

The Configuration Considerations section provides guidance on configuration and initialization of the middleware.

Refer to the Specification Conformance section for the API deviation from the specification.

Quick Start Guide

The below steps describe the simplest way of enabling the LIN Slave.

STEP 1: Enable the LIN middleware.

Launch ModusToolbox Library Manager and enable the LIN middleware. This step is required only if the ModusToolbox IDE is used. Otherwise, ensure the LIN Middleware is included in your project.

STEP 2: Setup the LIN-SCB block in Device Configurator.

  1. Open the Device Configurator and switch to the Peripherals tab (#1.0).
  2. Enable the SCB block under Communication group (#1.1) and select the LIN Personality (#1.2). Type the desired name for the SCB (e.g., LIN).
  3. In the "General" group (#1.3), set the interrupt priority for the bus communication handler.
  4. In the "Connections" group (#1.4), select the desired Clock for the SCB block. Also, select the desired pins for TX and RX lines — the Device Configurator will automatically configure them to the correct drive mode.
  5. In the "External Tools" group (#1.5), use the "Launch LIN Configurator" button to continue with protocol-level configuration.
  6. Select File->Save to generate initialization code.

See the Device Configurator section for details.

STEP 3: Configure LIN protocol in LIN Configurator.

Launch the LIN Configurator from the Device Configurator (see STEP 2, item 5) or as a standalone tool from the ModusToolbox Quick Panel. Configure the parameters on the General, Frames, Signals, Transport Layer and Configuration Services tabs per your application requirements. Refer to the LIN Configurator User Guide (see More Information) for detailed instructions.

See the LIN Configurator section for details.

STEP 4: Update main.c

The following code snippet shows the LIN initialization:

/* Instance number */
#define LIN_IFC_HANDLE (0U)
/* Allocate context for LIN operation */
/* LIN-SCB communication ISR */
static void LIN_Isr(void)
{
l_ifc_rx(LIN_IFC_HANDLE, &lin_context);
}
/* Bus Inactivity ISR (SysTick callback) */
static void LIN_InactivityIsr(void)
{
l_ifc_aux(LIN_IFC_HANDLE, &lin_context);
}
/* Call this function from main() */
void LIN_Init(void)
{
/* Initialize LIN core (mtb_lin_0_config generated by Lin Configurator) */
if (MTB_LIN_STATUS_SUCCESS != l_sys_init(&mtb_lin_0_config, &lin_context, &LIN_Isr, &LIN_InactivityIsr))
{
CY_ASSERT(0U);
}
/* Initialize LIN-SCB hardware (LIN_ifc_config generated by Device Configurator) */
if (l_ifc_init(LIN_IFC_HANDLE, &LIN_ifc_config, &lin_context))
{
CY_ASSERT(0U);
}
}

See the Initialization section for details.

STEP 5: Hardware Setup

Use a supported PSOC 4 development kit together with the CY8CKIT-026 CAN and LIN Shield Kit, which provides the LIN transceiver hardware.

STEP 6: Build and program the device.

Connect the device to the LIN Master. Configure LIN Master to send frames and observe updated signals in the LIN Slave application.

Configuration Considerations

The configuration workflow follows the steps described in Quick Start Guide. The subsections below provide additional details on each stage.

The list of sections under Configuration Considerations:

Device Configurator

The Device Configurator generates the hardware-level configuration for the LIN-SCB block, which includes:

  • The mtb_stc_lin_ifc_config_t structure instance, passed to l_ifc_init() (cycfg_peripherals.h/.c).
  • Peripheral clock divider assignment — currently only 16-bit integer divider type is supported (cycfg_peripherals.h/.c).
    (The middleware recalculates and sets the actual divider value at runtime based on the baud rate specified in the LIN Configurator.)
  • RX/TX pin configuration with appropriate HSIOM and drive mode settings (cycfg_pins.h/.c).

LIN Configurator

The LIN Configurator generates the mtb_stc_lin_config_t structure instance in mtbcfg_lin.h and mtbcfg_lin.c files. This structure is passed to l_sys_init().

Initialization

The initialization must follow the strict order:

  1. Call l_sys_init() — initializes the LIN core, validates the configuration, and calculates the peripheral clock divider.
  2. Call l_ifc_init() — initializes the LIN-SCB hardware, registers the interrupt handlers (NVIC and SysTick), and enables communication on the bus.

The middleware requires two user-implemented interrupt handlers, passed to l_sys_init():

  • LIN-SCB interrupt — handles bus communication. The user must implement a communication ISR that calls l_ifc_rx(). The IRQ number and priority are specified in mtb_stc_lin_ifc_config_t.
    (The LIN-SCB interrupt priority must be high enough to ensure timely response to bus events.)
  • SysTick interrupt — provides the Bus Inactivity timer with a 1 ms period. The user must implement an inactivity ISR that calls l_ifc_aux().

Specification Conformance

This section describes the deviations from the API defined by the LIN specifications.

  • The following deviations are applicable to all functions:
    • There are no static functions available. The middleware provides only the dynamic prototypes.
    • The interface of each function accepts the pointer to mtb_stc_lin_context_t as a parameter. The context holds the state of the LIN interfaces.
    • The interface handle parameter of the Interface Management functions is ignored. The context is used to differentiate between the interfaces instead.
  • The following functions have the following interface changes:
  • The deviations from the ISO 17987 specification are as follows:
    • The optional big-endian signal encoding variant is not supported.
    • The optional SID B8 is not supported.

API Changes between PSoC Creator Component and Middleware

This section describes the differences between PSOC Creator LIN component and the LIN middleware API.

# PSOC Creator LIN component LIN middleware
1 The result of the MTB_LIN_IOCTL_READ_STATUS operation of the l_ifc_ioctl() is returned by the function. The result of the MTB_LIN_IOCTL_READ_STATUS operation of the l_ifc_ioctl() is returned via the pointer specified by the pv parameter. The function returns MTB_LIN_STATUS_SUCCESS.
2 No l_sys_irq_disable() and l_sys_irq_restore() implemented. Added implementation of the l_sys_irq_disable() and l_sys_irq_restore().
3 All the interrupt service routines are initialized inside of the component - no any actions required on the application level. The communication and inactivity interrupt service routines should be implemented on the application level. Refer to the STEP 4: Update main.c section for the more details.

MISRA-C Compliance

This section describes MISRA-C:2012 compliance and deviations for the LIN.

MISRA stands for Motor Industry Software Reliability Association. The MISRA specification covers a set of 10 mandatory rules, 110 required rules and 39 advisory rules that apply to the firmware design and has been put together by the Automotive Industry to enhance the quality and robustness of the firmware code embedded in automotive devices.

The MISRA specification defines two categories of deviations (see section 5.4 of the MISRA-C:2012 specification):

  • Project Deviations - deviations applicable for a particular class of circumstances.
  • Specific Deviations - deviations applicable for a single instance in a single file.

Project Deviations are documented in the current section below.

Specific deviations are documented in the source code, close to the deviation occurrence. For each deviation, a special macro identifies the relevant rule or directive number, and reason.

Verification Environment

This section provides a MISRA compliance analysis environment description.

Component Name Version
Test Specification MISRA-C:2012 Guidelines for the use of the C language in critical systems March 2013
MISRA Checking Tool Coverity Static Analysis Tool 2022.12.0

Project Deviation

The table below provides the list of deviated required rules. Advisory rules deviation is not documented because it is not required per MISRA specification.

Rule ID Rule Description Description of Deviation(s)
Rule 3.1 The character sequences /* and // shall not be used within a comment. Usage of special comment symbols is needed for Doxygen comment support, it does not have any impact.
Rule 5.8 Identifiers that define objects or functions with external linkage shall be unique. During the code analysis, the same source files are compiled multiple times with device-specific options. All object and function identifiers are unique for each specific run.

Changelog

VersionChangesReason for Change
2.0 Removed CAT2 Hardware Abstraction Layers (mtb-hal-cat2) 2.x support.
Added support for new PSOC™ 4000T device family.
Added a new LIN personality.
Added mtb_stc_lin_ifc_config_t structure.
Updated l_ifc_init() and l_sys_init() API interfaces.
Updated mtb_stc_lin_context_t structure.
Support new device families.
1.10 Added CAT2 Hardware Abstraction Layers (mtb-hal-cat2) 2.x support.
1.0 Initial Version

More Information

For more information, refer to the following documents: