User manual
 

Logical Device Drivers

Introduction

Logical Device Drivers were developed to offer users the Hardware Abstraction Layer (HAL) for bare-metal applications as well as RTOS applications. The components provide tested, optimized C code tuned to the application needs. The code may be tuned to the specific RTOS when the RTOS component is in the project.

Differences between LDD and High Level Components

  • Each component provides Init() method to initialize appropriate peripheral and driver. Init() method returns a pointer to driver’s device structure.
  • Each component provides Deinit() method to de-initialize appropriate peripheral and driver.
  • The first parameter of each component’s method is a pointer to a device structure returned from Init() method. It is up to the user to pass a valid device structure pointer to component’s methods (null check is highly recommended).
  • The Init() method has one parameter UserDataPtr. A user can pass a pointer to its own data and this pointer is then returned back as a parameter in component’s events. The pointer or date pointed by this pointer is not modified by driver itself. A bare-board application typically passes a null pointer to Init() method.
  • LDD components are not automatically initialized in CPU component by default. If 'Auto initialization' property is not enabled, a user must call appropriate Init() method during runtime. Othervise the Init method is automatically called in CPU component and device structure is automatically defined.
  • LDD components have RTOS adapter support allowing to generate variable code for different RTOSes.
  • Runtime enable/disable of component events.
  • Low Power Modes support.

Logical Device Drivers in Bare-metal Applications

Logical Device Drivers can be used in applications where the RTOS is not required.

Logical Device Drivers in bare-metal environment have following specific features:

  • Init() method of each component uses a static memory allocation of its device structure.
  • Interrupt Service Routines are statically allocated in generated interrupt vector table (IVT).
  • The Linker Command File (LCF) is generated from CPU component.
  • The main module (ProcessorExpert.c) is generated.

Logical Device Drivers in RTOS environment

Logical Device Drivers in RTOS environment have following specific features:

  • Init() method of each component uses a dynamic allocation of its device structure through the RTOS API.
  • Deinit() method of each component uses a dynamic de-allocation of its device structure through the RTOS API.
  • Interrupt Service Routines are allocated through the RTOS API in Init() method and de-allocated in Deinit() method of each component.
  • The Interrupt table is not generated from CPU component in case whether RTOS provides runtime allocation of interrupt service routines.
  • The Linker Command File (LCF) is not generated from CPU component in case that RTOS provides its own LCF for applications.
  • The main module (ProcessorExpert.c) is not generated if specified in RTOS adapter.

For information and hints on LDD components usage, please see the section Typical LDD Components Usage.

RTOS adapter

The RTOS adapter component is a way how to utilize generated code to the specific RTOS. The RTOS adapter provides necessary information to the driver which API should be used to allocate memory, create a critical section, allocate interrupt vector, etc.


Figure 1 - Example of HAL integration into existing RTOS

Shared Drivers

Logical device drivers support the shared mode that means that more components can be put together to provide one instance of API. The user can access each component instance through the API of the shared component. A driver device data structure is used for resolution which peripheral instance shall be accessed. Currently there are three components that support shared mode: Serial_LDD, CAN_LDD and Ethernet_LDD.

Low Power Features

Logical device drivers in conjunction with CPU component implement low power features of a target MCU. Each LDD component define two methods related to the low power capability – SetOperationMode() and GetDriverState(). For more details see documentation of components.


Figure 2 - Usage of low power API in Logical Device Drivers

In the example above, DPM (Dynamic Power Manager) task may opt to care for a selected number of peripherals for graceful power mode change (eg. FEC, CAN) and rest of the peripheral drivers need not know the power mode change. When opted for informing a peripheral device driver, the DPM can build a semaphore object for low power acknowledgement from the device drivers. When all such acknowledgements arrive (ie. Semaphore count equals zero) the CPU can be placed into a wait/sleep power mode. In the future, with silicon design modifications, these semaphores can be implemented in the hardware and as a result a much faster power mode change can be expected. In There is no DPM in typical bare-metal applications the DPM task is implemented. In this case DPM is substituted by a user application code.