Kinetis系列——KSDK V1.3系统架构

NXP管管

Kinetis系列——KSDK V1.3系统架构

1. GettingStarted with Kinetis SDK (KSDK) v.1.3
在大概了解了KSDK下的文件夹和文件，接下来就Getting Started吧。


步骤：


l   阅读文档Getting Started with Kinetis SDK；
l   建立SI工程SI_Prj_platform，暂时只包含platform下的hal和drivers。有五六百个文件；
l   阅读SI_Prj_platform下代码。
1.2     KSDK概述
KSDK是一个为Freescale的Kinetis系列MCU提供全面软件技术支持的软件开发工具包。KSDK包括每个外设的硬件抽象层（HAL）和建立在HAL层之上的驱动层（Driver）。


1.2.1  KSDK demo and exampleapplications
KSDK提供两类软件例程


Demos Applications：全功能的范例旨在突出MCU的主要功能，着重特定用例。


Driver Examples：简单的范例旨在简明的阐述如何使用KSDK外设驱动。


<install_dir>/examples/<board_name>在每个板文件夹的顶层是一些演示和驱动都将用到的公共文件集，当改变复用器配置时这些文件可以被修改。
board.c / h：头文件包含特定于电路板的配置宏，例如调试终端配置，按钮，LED和其他特定于电路板的项目。 C文件包含时钟和振荡器初始化功能。


gpio_pins.c / h：KSDK GPIO驱动程序用于平台的GPIO引脚的定义。这些包括按钮和LED，但可以包括其他项，例如用于外部传感器的中断针。

pin_mux.c / h：包含外设特定的引脚复用器配置。这些函数可以由hardware_init（）函数调用，也可以由演示应用程序单独调用。

进入demo_apps，一个典型的示例如下：

1.3定位示例源文件


有两大主要区域提供每个例程的全部源文件：

<install_dir> / platform：包含共享的，特定于SoC的链接器文件，KSDK HAL的启动代码和源，外围设备驱动程序以及系统服务。

<install_dir> / lib：包含KSDK平台组件的编译库文件，例如HAL，外围设备驱动程序，启动代码和系统服务。


1.4     KSDK platform folder
platform是KSDK最重要的文件夹，它是KSDK的根基，并且包含主要的(primary)组件的源码，如CMSIS头文件、外设驱动（peripheral drivers）、硬件层（HAL）、操作系统抽象（OS abstraction）、启动文件（startup）、系统服务（system services）和链接文件，成功编译例程需要其大量组件。


当编译一个利用KSDK组件的例程时，有两种方法：


l  包含每一块需要的源文件；


l  链接一个库，这个库包含platform所有或相关的组件。


所有KSDK示例采用后一种方法。


1.5 KSDK lib文件夹


lib文件夹中的每个库配置都包含每个受支持工具链的文件夹。 每个工具链都包含一个用于受支持的SoC系列的文件夹。 必须为演示中使用的特定SoC构建ksdk_platform_lib。 在随后的特定于工具链的部分中将对此进行详细讨论。


1.6使用Keil运行演示


l安装CMSIS设备包


l建立平台库


l构建演示应用程序


2. Kinetis SDKv.1.3 API参考手册
通过上面，对KSDK已经有了大致的了解，现在初步看看它的API吧， 《Kinetis SDK v.1.3 API Reference Manual》+SI工程。


2.1     Introduction
Kinetis软件开发套件是一个扩展套件，它具有可靠地硬件接口和硬件抽象层、外设驱动、RTOS抽象、协议栈和中间件，以简化和加速Freescale Kinetis系列MCU的应用开发。额外添加的处理器专家技术（Expert technology）对于软甲开发和板级配置提供了无与伦比的易用性和灵活性。


KSDK包含以下用C编写的实时软件组件：


ARM® CMSIS Core and DSPstandard libraries and CMSIS-compliant device头文件提供直接访问（access）外设寄存器和位；


开源的硬件抽象层（HAL）提供一个简单、无状态驱动的封装了低层次寄存器功能的API；


系统服务（System services）为一些最关心资源，如时钟管理、中断管理、低功耗管理和硬件定时器；


建立在HAL之上的高层次外设驱动（peripheraldrivers），或许（may）会利用一个或多个系统服务（System services），可以使用驱动程序（drivers）按原样或作为参考创建自定义驱动程序；


操作系统抽象层（operating system abstraction (OSA) layer）以适应使用RTOS裸机编程的应用程序。提供了用于以下OS的OSA：


– Freescale MQX™ RTOS


– FreeRTOS


– Micrium uC/OS-II


– Micrium uC/OS-III


– bare-metal (no RTOS)


协议栈和中间件（Stacks and middleware）：


– a USB device, host, and OTG stack with comprehensive USB classsupport


– CMSIS-DSP, a suite of common signal processing functions


– FatFs, a FAT file system for small embedded systems


– Encryption software utilizing the mmCAU hardware acceleration unit


可选地，整个驱动程序集可以预先编译入一个库。


2.2 KSDK体系结构


KSDK体系结构由下面列出的八个关键组件组成。

1. ARM CortexMicrocontroller软件接口标准（CMSIS）CORE兼容设备

特定的头文件，SOCHeader，IP扩展头文件和CMSIS DSP库。

2.系统服务

3.硬件抽象层

4.外围驱动器层

5.实时操作系统（RTOS）抽象层

6.特定于主板的配置

7.与KSDK集成的堆栈和中间件

8.基于KSDK架构的应用程序

2.2.1 Kinetis MCU头文件
l   CMSIS-compliant device-specific header files
KDSK包含兼容CMSIS器件说明头文件，它提供直接访问Kinetis MCU外设的寄存器。每个KSDK支持的Kinetis芯片有总体的片上系统存储映射头文件，它包含每个外设和IRQ向量的存储器映射和寄存器地址，它通过指针和预先定义的掩码访问外设寄存器。


除此头文件之外，KSDK还包含为每个KinetisMCU外设提供的扩展头文件，它利用位绑定特点当读写一个寄存器中一位时。宏在Soc存储器映射头文件中提供以访问寄存器位域。当访问在拓展头文件中定义的寄存器宏时，用户必须传递一个<IP>_Type 结构类型指针（目标寄存器的基地址）。


KSDK HAL Drive API 函数采用这种基地址并将其传入到扩展头文件宏中以访问外设寄存器。


除了SoC头文件和外设拓展头文件KSDK还包含通用的用于Cortex-M core and DSPlibrary 的CMSIS头文件。CMSIS DSP库源文件也被包含以作参考。这些头文件可以在KSDKplatform/CMSIS目录下找到。

2.2.2  System Services
KSDK系统服务包含了一组可以由外设驱动使用的软件实体。它们可以和硬件层驱动（HALDrivers）一起构建外设驱动，也可以直接被应用程序使用。它们位于KSDKplatform/system目录下。


l   Interrupt Manager
“中断管理”提供函数使能和失能NVIC中独立的中断，它也提供函数去失能和使能ARM核全局中断为裸机关键代码段。除了失能和使能中断，“中断管理”


也提供ISR的注册，这允许应用软件去注册或者替换指定IRQ向量上的中断事务。


KSDK驱动不设置中断优先级，中断优先级方案是由具体的应用逻辑完全决定，用用户应用程序设定处理。用户应用通过ARM Cortex-M core CMSIS头文件（core_cm4.h）中提供的NVIC函数去管理中断优先级。


l   Clock Manager
“时钟管理”提供集中对于整个系统的时钟相关的函数。可以动态的设置系统时钟（system clock），也可以执行指定外设的时钟门控。


“时钟管理”也包含每个外设时钟园需求信息，提供函数获得时钟支持外设的时钟频率。


“时钟管理”提供通知框架的KSDK的软件组件，例如驱动程序，使用登记回调函数并执行时钟模式转换期间的预定义的代码流。


l   Power Manager
“功耗管理”提供集中整个系统的功耗相关函数。它可以动态的设置电源模式和配置LLWU唤醒设置。


l   Unified Hardware (HW) Timer
“统一的硬件定时器”提供一个通用定时器接口给能连接MCU定时器的外设，或者像SysTick一样用作基本定时器。


它能够用作裸机编程应用的毫秒级共享定时器，如时间守护忙循环。它也可以与RTOS接口，以提供操作系统的时基。统一硬件定时器的未来实现将利用低功耗定时器外设，它允许当系统处于各种低功耗模式让OS时基继续运行。


2.3     Hardware Abstraction Layer(HAL)
KSDK硬件抽象层由Kinetis MCU产品家族片上外设的低层次驱动组成。


主要的目标是为了提取 硬件外设寄存器读取 成为一套stateless基本函数操作，HAL本身就可以和“系统服务”一起去构建特定应用逻辑，或者作为使用高层次外设驱动程序的构建块。它首要地聚焦于功能控制、配置和实现基本外设操作，HAL隐藏寄存器读取的细节和各种单片机外围实例化的差异。因此，这样，无论是应用程序或高层外设，可以从低级别的硬件的细节被抽象。因此，硬件外设必须通过HAL进行访问。


HAL还可以支持一定的逻辑一些高级功能，提供这些高级功能不依赖于其他外设的功能，也没有施加任何行动应采取的中断服务程序。例如，UART HAL提供一个阻塞字节发送函数，它只依赖于在UART外设本身可用的特征。这些高层次的功能增强HAL的可用性，但仍然无状态的，独立于其他外设。从本质上讲，HAL功能边界由外设本身限制。每个外设都有一个硬件抽象层HAL驱动，硬件抽象层也只能访问外设可用的功能。


此外，HAL没有定义ISR的入口或支持的中断处理。这些任务必须由高级别外设驱动连同中断管理器来处理。


硬件抽象层位于 platform/hal 目录下。


2.3.1  Feature Header Files
HAL被设计成可重复使用的，无论从一个Kinetis MCU设备到另一个的外设结构的差异。全面的外设功能头文件提供了KSDK支持每个Kinetis的子系列器件的功能或配置差异。


2.3.2  Design Guidelines
本节概述用于开发硬件抽象层驱动的设计指南。它的目的是提供信息，并且提供了HAL驱动程序组成的更多细节。如前所述，HAL的主要目标是抽象硬件细节，并提供了一套易于使用的低级别的驱动。


HAL的本身可以直接由用户应用程序使用，在这种情况下，建立在HAL之上的高级别外设驱动被视为一个参考参考实现去展示了HAL使用。


硬件抽象层主要地集中在个别功能基元和不做任何的使用情况假设。它也实现了一定的逻辑一些高级功能，而无需从其他外围设备的依赖，不会强加任何中断处理。HAL的API遵循命名约定即从一个外设到下一个相一致。这是开发HAL驱动程序时所使用的设计指导原则的总结：


每个独立的外设有一个专用的硬件抽象层驱动。通过一个功能头文件处理差异使不同版本或配置的外设都被视同样的外设。 HAL应隐藏外设、MCU细节和高层应用程序和驱动的差异。


每个硬件抽象层驱动都有一个初始化函数，使外设处于某种已知的默认状态，这里没有相应的去初始化函数。


每个外设都有使能和失能函数去使能或失能外设模块。


硬件抽象层驱动不具有内部操作语境并且不应动态分配存储器。


硬件抽象层为支持数据传输相关操作的外设提供阻塞和非阻塞函数。


硬件抽象层可以实现基于函数原语的高级函数，提供该实现不依赖于功能外设之外，不涉及中断处理。硬件抽象层必须保持stateless。


硬件抽象层驱动不依赖于任何其他软件实体或调用其他外设任何功能。


2.4     Peripheral Drivers
KSDK外设驱动是基于一个或多个HAL驱动或其它外设驱动或/和系统服务，用作高层次驱动去实现高级逻辑事务。考虑，例如，UARTHAL和UART外设驱动的差异，UART HAL主要集中在字节级的基本功能的原语，而UART外设驱动（Peripheral Driver）在中断驱动级使用数据缓冲区传输字节流，并能够与DMA外设驱动（Peripheral Driver）交互，在数据缓冲区之间启用DMA传输。一般地，如果一个驱动，即主要是基于一个外设、接口，功能超出其本身的HAL和/或需要中断服务，这个驱动被认为是一个高层次的外设驱动。


KSDK外设驱动（Peripheral Drivers）支持Kinetis MCU每个外设所有实例，通过用一个简单的整数参数去代表第几个外设实体。每个外设驱动包含一个“common”文件，表示为fsl_<peripheral>_common.c，这个文件翻译外设实例（instance）号到外设寄存器基地址，然后传递到硬件抽象层。因此，外设驱动使用者不需要知道外设存储器映射基地址。


外设驱动（Peripheral Drivers）用在需要数据存储（用于内部上下文处理）的高层次逻辑，然后，其并不分配这个内存空间。用户宁愿通过在用于通过驱动初始化函数驱动内部操作的存储器。注意硬件抽象层用于RAM和FLASH有限制的MCU。


外设驱动（Peripheral Drivers）被设计用来处理目标用例的整个功能。一个应用程序应能仅用外设驱动（Peripheral Drivers）来完成目标。在一个应用Peripheral Driver 和HAL混合使用是可以的，但是鼓励使用清晰清洁的体系结构，并且应该避免绕过Peripheral Driver而导致的在Peripheral Driver内出现逻辑错误的情形。


外设驱动（Peripheral Drivers）位于platform/drivers目录下。


2.5     Interrupt Handling
中断驱动的外设驱动（Peripheral Drivers）被设计成服务所需功能的所有的中断。每个外设驱动（Peripheral Drivers）为每个特有的使用案列（use-case）实现了一套简单易用的API，每个外设驱动（Peripheral Drivers）也公开了中断函数（functions），在服务特定中断时执行所有操作。这些中断动作函数采用外设实例编号作为输入参数。所有外设驱动（Peripheral Drivers）的ISR入口在一个单独的命名为fsl-_<peripheral>_irq.c的C文件中实现，其位于外设驱动（Peripheral Drivers）文件夹下的顶层。ISR入口调用实现在driver中被作为driver 公共接口的一部分的相应中断功能函数，每个中断功能函数每个中断操作功能都是硬编码的外设实例号，注意IRQ文件依赖于外设驱动（PeripheralDrivers），但外设驱动（PeripheralDrivers）不依赖IRQ文件。


CMSIS启动代码包含带有被定义成弱引用的ISR入口名的中断向量表。在外设驱动（Peripheral Drivers）中新定义的ISR入口名称取代中断向量表中弱引用被视为与中断服务程序入口名相匹配（match）。 其对中断向量表无依赖。 然而，如果中断向量表被重定向（通常到RAM），这样ISR入口名称应保持一致。


每个外设驱动（Peripheral Drivers）IRQ文件定义了MCU上所有外设的所有实例的中毒服务函数入口，任何无用的ISR入口可以在用户应用程序中被安全的删除。注意，当为一个特定MCU编译驱动库（driver libraries）时，这个IRQ文件不是库的一部分。当开发一个应用程序时，包含IRQ文件到应用工程空间。


如果你想使用硬件抽象层（HAL）直接组成一个带中断的应用程序或高层次驱动时，定义ISR入口去服务需要中断的应用。ISR入口名必须和CMSIS启动代码中断向量表中的匹配。通常，在系统启动时中断向量表被重定位到RAM中，ISR入口名称保持不变。然而，要想改变平这些ISR入口名称，用户需要通过调用中断管理注册函数去注册新定义的ISR入口表名称。


带RTOS事，如果目标操作系统有自己的中断管理机制，用户ISR必须通过OS提供的服务程序去动态地注册OS内部的中断向量表。一些不带中断处理的OS，不需要特别地处理。大多数为Cortex-M core 设计的RTOS使用PendSV exceptions 来调度。PendSV exceptions 优先级很低，只有当所有中断执行完毕才执行。一个特殊情形是，ISR开始和结尾必须调用中断处理序幕和尾声，以通知OS进入和退出一个中断，以避免系统服务中断事务时OS调度器再次调度。OS Abstraction layer为所有支持的OS使用统一的API 提供prologues and epilogues。


2.6     Peripheral Driver Types
外设驱动（Peripheral Drivers）被设计在高层次逻辑情形上使用。因此，在外设驱动（Peripheral Drivers）和软件组件之间进行交互有一些限制。这是一些典型的KSDK PeripheralDriver类型来阐述这个概念：


l对特定IP和系统服务使用一个HAL的外围设备驱动程序

l使用多个HAL组件和系统服务的外围设备驱动程序。一个示例涉及一个使用DMA HAL和I2C HAL来构建支持DMA的高级I2C驱动程序的外围驱动程序。同时，DMA外设驱动程序已经存在，并提供了整体DMA通道管理。在这种情况下，专用DMA外围设备驱动程序可能会出现问题，因为它不了解直接访问DMA HAL的启用DMA的I2C驱动程序的资源使用情况。在这种情况下，KSDK外围设备驱动程序仅在为专用于该驱动程序的特定通道配置DMA传输控制描述符时才使用DMA HAL，并避免使用DMA HAL更改DMA外围设备控制寄存器。通常在外设初始化期间通过调用DMA PeripheralDriver通道请求函数来分配特定外设驱动程序的DMA通道分配。这样，DMA会维护使用的通道注册表。

l将HAL，其他外围设备驱动程序和系统服务结合使用的外围设备驱动程序，用于基于解决方案的复合高级驱动程序。


2.7     Design guidelines
这部分总结开发外设驱动的设计指导，Peripheral Driver 将被“PD”取代。


l PD不直接访问硬件寄存器，仅使用HAL与硬件接口。它间接使用其他PD访问硬件功能。

l PD不会动态分配内存，并且在编译时不会采取任何静态配置。它通过在初始化功能中从应用程序获取配置数据结构来支持运行时配置。此初始化功能还占用为内部操作上下文存储需求分配的内存。 PD仅从配置数据结构中读取。配置数据结构定义为“ const”。

l PD支持初始化功能，并具有相应的去初始化功能。

l PD支持数据交易的阻塞和非阻塞功能。

l PD不依赖于与Kinetis平台上可用的任何外围设备都不相关的任何软件或硬件实体。例如，即使ENET PD在没有关联的外部PHY的情况下也无法运行，以太网（ENET）PD也不依赖于外部的ENET PHY。

l如果PD建立在HAL之上，则PD可以通过将实例编号作为参数来与任何外围设备实例一起使用。在多个实例之间共享全局数据时，使用RTOS时必须保护全局数据访问。这可以使用作为RTOSabstraction的一部分实现的关键部分功能来完成。当不使用RTOS时，可以通过裸机OSabstraction实现解决此数据访问保护问题。

l当驱动程序中的ISR和其他公共API函数访问PD内部操作上下文时，必须将该数据定义为易失性，以便编译器不会无意中优化代码，从而导致不良功能。

l PD提供了足够的功能来允许PD提供的API满足目标用例实现。用户应用程序不应同时使用PD和HAL。

l PD没有配置引脚混合或为相关中断设置中断优先级。这些项目由特定于电路板的配置和特定于应用程序的逻辑处理。


2.8演示应用


KSDK包括两种演示应用程序：

l演示应用程序，演示PeripheralDrivers的用法。

l演示应用程序，基于目标Kinetis MCU和评估板上的可用功能提供参考设计。这种类型的演示旨在凸显SOC预期用途的某些功能，和/或使用KSDK驱动程序库以及其他集成软件组件（如USB堆栈）提供交钥匙参考。


2.9     Board Configuration
KSDK不假设特定板级配置，驱动也不配置管脚复用，管脚复用是板级配置的一部分。KSDK提供的板级配置文件，其不门控相关I/O端口时钟，其配置整个板子的管脚复用，函数可以在驱动初始化前被调用。这些板级配置文件能在KSDK top-level board目录下找到。

2.10  OS Abstraction layer
KSDK驱动（drivers）被设计用来带或不带RTOS工作，操作系统抽象层被设计和实现用以支持RTOS，其为drivers、集成软件解决方案和上层应用程序提供一套通用服务程序，这样一些通用代码就可以使用而不管是什么目标OS。


OSA提供的服务被驱动需求、中间件和应用驱使。OSA被尽可能的设计的小巧（thin），


OSA映射需要的服务到目标OS提供的服务，也实现目标OS不支持的服务。


OSA本书不为OS组件动态地分配内存，相反，OS组件需要的内存被调用者分配，并传递到OSA去服务。OSA drivers在KSDK platform/osa目录。

2.11软件堆栈和其他中间件集成


Kinetis SDK的核心是为所有Kinetis MCU产品系列外围设备构建的一组通用驱动程序库.Kinetis SDK还为软件堆栈和其他中间件奠定了基础。 KSDK集成了其他飞思卡尔或第三方支持软件堆栈，例如USB堆栈和TCP / IP堆栈以及其他中间件，从而为Kinetis MCU用户提供了完整的，易于使用的软件开发工具包。 适用于theKinetis产品系列的所有Kinetis MCU软件解决方案。

阅读全文