|
Logical Device Drivers IntroductionLogical 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
Logical Device Drivers in Bare-metal ApplicationsLogical Device Drivers can be used in applications where the RTOS is not required. Logical Device Drivers in bare-metal environment have following specific features:
Logical Device Drivers in RTOS environmentLogical Device Drivers in RTOS environment have following specific features:
For information and hints on LDD components usage, please see the section Typical LDD Components Usage. RTOS adapterThe 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.
Shared DriversLogical 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 FeaturesLogical 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.
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. Copyright 2013 Freescale Semiconductor, Inc.
PROCESSOR EXPERT is trademark of Freescale Semiconductor, Inc. |