![](https://csdnimg.cn/release/download_crawler_static/10567836/bg14.jpg)
Each Peripheral Driver IRQ file defines the ISR entries for all instances of the peripheral instantiated on
the MCU. Any unused ISR entries can be safely deleted in the user application. Note that, when building
driver libraries for a particular MCU, the IRQ files are not part of the library build. When developing an
application, however, include these IRQ files into the application project space.
If you want to use the HAL to directly build an interrupt-driven application or a high-level driver, define
the ISR entries to service needed interrupts. The ISR entry names have to match the names of the ISR
entry names provided in the CMSIS startup code vector table. Normally, the vector table is relocated to
RAM during system startup and the ISR entry names remain unchanged. However, should these ISR entry
names change, the user is required to register the newly defined ISR entry table names by invoking the
Interrupt Manager registration function.
When working with an RTOS, if the target operating system has its own interrupt handling mechanism, the
user’s ISR has to dynamically register the internal vector table maintained inside the OS via the service
routine provided by the OS. Some operating systems do not have dedicated interrupt handling, and no
special handling is required. Most of the RTOSes designed for the Cortex-M core use PendSV exceptions
for scheduling. The PendSV exceptions are low priority and execute only when all other interrupts have
been serviced. There are special cases where interrupt handling prologues and epilogues have to be called
at the beginning and at the end of an ISR to inform the OS of the entry and exit of an ISR so that the
OS scheduler does not trigger a rescheduling event while the system is servicing interrupts. The OS
Abstraction layer provides prologues and epilogues in a uniform API for all supported OS.
Peripheral Driver Types
Peripheral Drivers are designed and operated on use-case driven high-level logic. For that reason, the
interaction between a Peripheral driver and other software components has a few limitations. This is a list
of typical KSDK Peripheral Driver types to demonstrate this concept:
• Peripheral Drivers that use one HAL for a particular IP and system services
• Peripheral Drivers that use multiple HAL components and System Services. An example involves
a Peripheral Driver that uses both the DMA HAL and the I2C HAL to build a DMA-enabled high-
level I2C driver. At the same time, a DMA Peripheral Driver already exists and provides the overall
DMA channel management. In this situation, issues can arise for the dedicated DMA Peripheral
Driver because it is unaware of use of resources for the DMA-enabled I2C driver that accesses the
DMA HAL directly. In this case, the KSDK Peripheral Drivers will only use the DMA HAL when
configuring the DMA Transfer Control Descriptor for a particular channel that is dedicated to the
driver and avoid using the DMA HAL to change the DMA peripheral control registers. The DMA
channel allocation for a particular Peripheral Driver is normally assigned during the initialization
of the peripheral by calling the DMA Peripheral Driver channel request function. In this way, the
DMA maintains a used channel registry.
• Peripheral Drivers that use a combination of HAL, other Peripheral Drivers, and System Services
for solution-based composite high level drivers.
Design guidelines
This section summarizes the design guidelines to develop the Peripheral Drivers. In this list, the term
Peripheral Driver is replaced with the acronym “PD”:
• The PD does not directly access hardware registers and only uses HAL to interface with hardware.
8
Kinetis SDK API Reference Manual
Freescale Semiconductor