首页 > 产品 > 微控制器 (MCU) 和处理器 > 处理器SDK介绍_2016 TI 嵌入式产品研讨会实录 >

基于 Arm 的处理器

最新课程

热门课程

处理器 SDK RTOS

然后是关于 RTOS 这块的介绍 刚才也讲到就是在这个界面底下 除了有我们的 Linux 系统以外 还有 real time 的 Linux 然后就是这个 TI 自己的 RTOS 的这一块 RTOS 进来一块呢 因为 RTOS 跟 Linux 有一点区别 就是 RTOS 不止是在 可以在你的 Linux 操作系统底下去运行 同样它也可以在 window 环境下安装 因为我们对于调试的话 我们的 CCS 版本 其实是有 windows 的版本 也有 Linux 的版本 所以 RTOS 这一块既可以在 Windows 底下 去调试 也可以在 Linux 底下去调试 所以这里面有两个安装文件 根据你自己的操作系统来选择 这个其实跟刚才是一样的 就是说主要是我们 设计的 RTOS 的这一块的分层 RTOS 的分层呢 底层是一些关于 SOC 的一些驱动 其实就是根据不同的芯片 有不同的品牌的驱动 然后中间有一个中间层 它主要是说给这个 因为我们要给上层应用提供一个 叫做一个透明的一个 API 的调用 所以在这一块的话分装了很多的 API 函数 来帮助你 就等于是把应用层和底层隔开 这一层就是用来作这个 相当于一个中间的一个环节 然后其它的上面就是 操作系统提供的一些 API 函数 最上层就是用户的一些代码 对于 RTOS 来说的话呢 同样的 就是底层的驱动 CSL 也好 LLD 也好 整个驱动都是由 TI 来提供的 就是我们所有的驱动 都是 TI 在 PDK 里面 或者是 CSL 里面来支持 然后往上走的话 这种最基本的算法库 像 DSPLIB MATHLIB IMGLIB 这些也是我们软件的团队根据 这是我们不同的 DSP 芯片 来做这种代码的优化 所以这一块实际上是包含了 所以这一块实际上是包含了 我们很多已经优化过的代码在里面 这个可以供大家在做这种 常用的算法时进行调用 然后在往上走的话我们会有一些基本的框架 像这个 IPC 的就是核间通信的框架 还有网络层的框架 以及我们操作系统这一块的框架 然后在你装好 这个是一个 Windows下装好 processor SDK RTOS 的一个就是 它会把很多东西都装进去 比如说 bios 也好 dsplib edma_lld imglib 我们等于是在这个里面提供了 像 PDK 是最主要的是 就是相当于是一个驱动的目录 就是我们所有的外设 所有的加速器 都会在 PDK 里面提供它的驱动的源代码 然后 edma 这一块主要是 提供 edma 控制器的这些底层驱动 因为 edma 是一个应用的 比较广泛的一个外设吧 然后所以我们经常会把它 作为一个单独的一个 library 来拿出来给客户来做调用 然后 framework components 这个主要是说 基于我们的这些硬件或者是软件也好 把做成整个的一个框架性的东西 主要是做一些标准 这一块可能用的比较少一些 在我们一些 library 里面 可能会有一些依赖 所以这一块一般大家都不用太关注 然后跟我们应用层比较相关的 可能是这几个 library 一个是 dsplib imglib 和 mathlib 然后 dsp 主要是提供了基本的一些信号处理 像 FFT 还有 Filter 就是 Filter 还有像这种大矩阵的相乘 还有像我们现在新做的 这里面有一些算法 像那些矩阵的分析 都可以在 dsplib 里面去找 它有定点的算法 也有同样也基于浮点的算法 然后 imglib 就是其实主要提供的 是一些最基本的一些图像的操作 然后 mathlib 主要是提供的 像基本的数学库 像 cos 还有基本的这些数学函数吧 然后这个可能是我们平时在 dsp 上 会用的比较多的一些 library 这也同样是包含在 整个的 processor SDK 里面 然后是跟整个芯片相关的就是跟 整个芯片应用相关的一些就是这个组件吧 比如说像 bios 像 xdc 像 ipc 这些都是和芯片相关的 然后我们会在 bios 里面 主要是提供了操作系统的一些 就是其实它里面有一部分的源代码 同样有一部分的 bios 的 library 都含在 bios 文件夹里面 然后 Processor SDK RTOS 里面 就包含了很多的文档啊 还有相当于一些例子啊 都在这个里面 然后 cg_xml 和 xdc 工具 这个是主要用来说 我们要把所有的这些模块 集合在一起进行做编译啊做链接啊 我们其实 TI 依赖的是 xdc 的工具 这个主要是说你在 ccs 里面去调用 bios 或者是使用 bios 来进行管理的话 它肯定会去调用 xdc 的工具 然后这个的话这里不做展开的讲了 因为其实 xdc 工具相对也比较复杂 然后我们可能最主要的还是 会用 ccs 的 ide 界面 然后去配置整个的 bios 但是等你做到比较可能稍微深入一点 可能会对 xdc 工具要做一些了解 就是 因为它其实有点类似于 像是一个 make file 的工具 但是它比 make file 提供更多的就是 等于是更灵活的语法和空间 它可能会有一些地方 需要你手动的去用 xdc 工具去调 这个一般情况下可能不会遇到 但是做的比较深入的话 你可能需要去看 xdc 的一些脚本 然后 ipc 这一块呢 主要是提供刚才讲的核间通信这一块 因为我们是一个异构的核 就是 ARM 核 和 DSP 核还有 M4 的核 在这些核间要进行这种通信的话 我们需要依赖一个 library 来做一个平台来做 来做一个平台来做 来提供一个统一的一个 API 的接口 当然你也可以说我们用最简单的方式 比如说依赖芯片的 芯片的里面的 mail box 或者是芯片内部的共享内存空间 或者是用芯片内部的这种核间的中断 这样都可以 但是 IPC 给大家提供的是一个 统一的一个标准的 API 的函数 这样你可以在每个核上面 不管是 ARM 核 M4 还是在 dsp 上面 它都能够去调用 IPC 里面的 API 来做 所以能保证你的代码的一致性 当然这个 IPC 它相对起来 它有一些可能你需要 学习它的 API 怎么调用啊 然后 ARM 上怎么去用这个 IPC 啊 dsp 怎么用这个 IPC 啊 用起来的话可能是需要进行一些学习的工作 然后我们也提供了相应的文档 大家可以去参照这些文档 去看看它的有一些最基本的例子 比如说像代码的例子啊 有些数据通信的例子啊 mail 的例子啊 都可以通过这些例子和文档来进行一些学习 然后 ndk 这一块主要是提供 TCP/IP 协议栈 但是这一块 ndk 主要是跑在 dsp 上的 TCP/IP Linux 本身自带有 它本身内部就有 TCP/IP 协议栈 所以用不着 ndk 这一块 然后 ndk 这一块现在 应该说在 dsp 因为我们现在是 soc 的系统 所以在 dsp 再去跑一个 ndk 的 这种 TCP/IP 协议栈越来越少了 一般情况下 TCP/IP 这一块还是放到 ARM 里面来做 然后其它的就是我们在 processor SDK 里面 提供的一些工具 就是比如说 ctool 这是一个实时调试的一些工具 这个可以大家找一下 因为是包含了一些 关于我们可以在 bios 系统里进行 比如我进程运行的时间 我的中断响应时间 我们可以把这些东西都显示在 我们的 CCS 的 ide 界面里面 它可以作为一种调试的手段 所以 ctools 和 uia 主要是给它提供一个 可视化的一种调试的界面 当然这里面都需要是你跑的系统是 bios 因为它需要通过 bios 的一些进程 去下载一些数据 然后它才能通过这些工具来进行分析 然后对于我们 就是 RTOS 这一块来说 RTOS 因为它的这个驱动的分层 可能跟 Linux 又不太一样 它最底层的话是一个 CSL 就是 cheap support library 就是基于寄存器级别的一个编程 然后把寄存器 CSL 封装到我们的 PDK 就是 peripheral device driver 里面 封装到这个里面因为你上层可能会跑 我们的 RTOS 系统 或者是跑 或者是纯粹的你自己的一些定制的一些东西 但是为了把这一层与我们的驱动层隔开 所以在这个里面实际上 加入了一个 OSAL 以在写驱动 就是定制驱动的时候 因为如果你用 RTOS 的话 可能会牵涉到这一块定制的问题 但你如果你在写自己的一些 使用自己的一些操作系统 或者是说 不使用操作系统的情况下 你要用 PDK 的话 你可能要去定制这些 OSAL OS 适配层的一些 API 因为它这些 API 比如说最简单的一个例子就是内传输 如果在 RTOS 里面 它是有特定的函数 它是有特定的函数 来做这个 但是如果你在自己的 OS 或者是自己的这些代码里面的话 你怎么去分配这些内存 它是需要你自己对这个 API 进行提示的 所以一般做移植的话 它需要把在这个 OSAL 来 定制一下才能使用我们 PDK 这一块的东西 然后那个 当然你也可以就是最简单的方式 当然也是最直接的方式 你可以基于 CSL 来做 如果 CSL 就不牵涉到 OSAL 这一层了 如果你基于 CSL 来做的话呢 就相对比较麻烦的是 你需要去就是要非常了解底层所有寄存器的 这些能控制什么 能做什么 当然简单的接口可能没有问题 像 URT 像 I2C 这些接口寄存器的数量非常的少 可能应该问题不大 但是如果比较复杂的一些加速器 或者是比较复杂的一些接口的话 要读的 要写的寄存器会比较多 所以这个地方工作量就会稍微大一些 这个时候可能就要根据你自己的选择吧 底层你直接写寄存器肯定是效率最高的 也是你灵活性最强的 然后 PDK 这一块 给你提供的一个标准的 API 但是呢它因为封装呢有两三层在里面 所以它的就是怎么讲呢 就是有很多调试的话并不是那么的简单 就是如果比如说里面你使用的不正确的话 它里面出错了 然后具体调试到里面 这个里面还是会有点麻烦的 这个刚才也已经讲过了 我们其实 CSL 就是最底层的 基于寄存器级别的 libarary 然后再往上是封装成这个 LLD 然后整个这一套系统形成了 我们的 RTOS 里面的驱动 然后对于我们刚才讲的 PDK 就是我们外设驱动这一块 你可以到 PDK 的目录底下 你可以看到所有的不同外设 它都有自己的一些驱动 然后这些驱动就等于是 它给你提供了一些标准的 API 然后你可以直接调用这些 API 做一些 做完初始化之后调用这些 API 就可以对这些外设进行操作 但是要注意的是就是说 Linux 可能也会用到这些外设 你在 dsp 底下来对这些外设进行操作的时候 你要注意这两个会有互斥的 或者是有一些数据共享的一些问题 这个问题是没办法在软件上来规避的 你必须在系统设计的层面就要去考虑这个问题 然后这个是举了一个最简单的例子 然后就是说我们使用 UART 就是最简单的一个串口为例 然后我们怎么去做通过调用这个我们 PDK 里面的 API 来做整个 UART 的一个收发 首先是做一个建立一个 UART 的一个实体 然后对它进行 你可以把你需要初始化的参数 填到这个 struct 里面 然后它调用它的 LLD 里面初始化的函数 对它进行一个初始化的操作 然后当你 UART open 打开以后 也可以调用它标准的 UART read 或者是 UART write 这些标准的一些函数 来对 UART 进行就是读写的一些操作吧 然后如果你不使用它的话 你可以调用它的 UART 的 close 来关掉它 所以一般情况下你看到 LLD 里面 它因为把整个的就是这些驱动的操作 都封装到它的底层 它提供给上层的主要就像这种 一些很简单的一些函数 就是对于 就是应用层的这些软件编程的话是非常友好的 但是对于底层驱动的工程师来说 如果比如说你的 UART read 的时候突然出错 或者是 UART read 这底层读上来的东西有些不对 这时候你要去调的话是会比较麻烦的 所以这个需要大家来 从不同的方面来考虑这个问题 从一开始调试的时候 觉得大家可以先用最简单的 CSL 来调 保证你的 UART 是一个 能够工作在一个稳定的状态 然后你了解那些 UART 的一些寄存器的状态 或者是其它的一些外设的寄存器 你能够读懂它寄存器的状态到底是什么意思 然后你再把这些接口这些库都放上去 然后如果某一天真的出现了问题 你还是需要通过读那些底层的寄存器 来看你的接口是不是工作在一个正常的状态下 然后 OSAL 这一块就是我们的这个 就是刚才讲的适配层 因为 driver 的 API 它里面 不可避免的还是要牵扯到 比如说分配内存啊 还有分配中断啊 这些类似的一些操作 所以这些操作都是要通过 OSAL 所以这些操作都是要通过 OSAL 提供的一些标准的 API 来做 这一块就封装了所有的关于可操作系统 比如调度器啊 内存分配啊 这些相关的一些操作 当然如果是你自己定义的操作系统 当然如果是你自己定义的操作系统 或者是自己的一些 就是没有操作系统的环境的话 因为 dsp 上面有可能很多客户 就写了一个 while 循环就来做了 然后你需要去定制这个 OSAL 自己写里面的 API 才能够调用这些驱动 才能够调用这些驱动 这个是我们刚才讲的就是 我们不管是 processor SDK Linux 的版本也好 RTOS 的版本也好 还是整个 processor training 也好 这个在我们 TI 的官网上你搜这个 processor SDK 都可以进到 我们的 wiki 的一些支持的页面里面 然后你可以去找到这些指南 或者是找到一些相关的培训的资料和视频 可以先去看一下 然后 processor 的 SDK 介绍就到这 然后看看大家还有没有相关的一些问题

然后是关于 RTOS 这块的介绍

刚才也讲到就是在这个界面底下

除了有我们的 Linux 系统以外

还有 real time 的 Linux

然后就是这个 TI 自己的 RTOS 的这一块

RTOS 进来一块呢

因为 RTOS 跟 Linux 有一点区别

就是 RTOS 不止是在

可以在你的 Linux 操作系统底下去运行

同样它也可以在 window 环境下安装

因为我们对于调试的话

我们的 CCS 版本

其实是有 windows 的版本

也有 Linux 的版本

所以 RTOS 这一块既可以在 Windows 底下

去调试

也可以在 Linux 底下去调试

所以这里面有两个安装文件

根据你自己的操作系统来选择

这个其实跟刚才是一样的

就是说主要是我们

设计的 RTOS 的这一块的分层

RTOS 的分层呢

底层是一些关于 SOC 的一些驱动

其实就是根据不同的芯片

有不同的品牌的驱动

然后中间有一个中间层

它主要是说给这个

因为我们要给上层应用提供一个

叫做一个透明的一个 API 的调用

所以在这一块的话分装了很多的 API 函数

来帮助你

就等于是把应用层和底层隔开

这一层就是用来作这个

相当于一个中间的一个环节

然后其它的上面就是

操作系统提供的一些 API 函数

最上层就是用户的一些代码

对于 RTOS 来说的话呢

同样的

就是底层的驱动

CSL 也好 LLD 也好

整个驱动都是由 TI 来提供的

就是我们所有的驱动

都是 TI 在 PDK 里面

或者是 CSL 里面来支持

然后往上走的话

这种最基本的算法库

像 DSPLIB MATHLIB IMGLIB

这些也是我们软件的团队根据

这是我们不同的 DSP 芯片

来做这种代码的优化

所以这一块实际上是包含了

所以这一块实际上是包含了

我们很多已经优化过的代码在里面

这个可以供大家在做这种

常用的算法时进行调用

然后在往上走的话我们会有一些基本的框架

像这个 IPC 的就是核间通信的框架

还有网络层的框架

以及我们操作系统这一块的框架

然后在你装好

这个是一个 Windows下装好

processor SDK RTOS 的一个就是

它会把很多东西都装进去

比如说 bios 也好

dsplib edma_lld imglib

我们等于是在这个里面提供了

像 PDK 是最主要的是

就是相当于是一个驱动的目录

就是我们所有的外设

所有的加速器

都会在 PDK 里面提供它的驱动的源代码

然后 edma 这一块主要是

提供 edma 控制器的这些底层驱动

因为 edma 是一个应用的

比较广泛的一个外设吧

然后所以我们经常会把它

作为一个单独的一个 library

来拿出来给客户来做调用

然后 framework components 这个主要是说

基于我们的这些硬件或者是软件也好

把做成整个的一个框架性的东西

主要是做一些标准

这一块可能用的比较少一些

在我们一些 library 里面

可能会有一些依赖

所以这一块一般大家都不用太关注

然后跟我们应用层比较相关的

可能是这几个 library

一个是 dsplib imglib 和 mathlib

然后 dsp 主要是提供了基本的一些信号处理

像 FFT 还有 Filter

就是 Filter

还有像这种大矩阵的相乘

还有像我们现在新做的

这里面有一些算法

像那些矩阵的分析

都可以在 dsplib 里面去找

它有定点的算法

也有同样也基于浮点的算法

然后 imglib 就是其实主要提供的

是一些最基本的一些图像的操作

然后 mathlib 主要是提供的

像基本的数学库

像 cos 还有基本的这些数学函数吧

然后这个可能是我们平时在 dsp 上

会用的比较多的一些 library

这也同样是包含在

整个的 processor SDK 里面

然后是跟整个芯片相关的就是跟

整个芯片应用相关的一些就是这个组件吧

比如说像 bios 像 xdc 像 ipc

这些都是和芯片相关的

然后我们会在 bios 里面

主要是提供了操作系统的一些

就是其实它里面有一部分的源代码

同样有一部分的 bios 的 library

都含在 bios 文件夹里面

然后 Processor SDK RTOS 里面

就包含了很多的文档啊

还有相当于一些例子啊

都在这个里面

然后 cg_xml 和 xdc 工具

这个是主要用来说

我们要把所有的这些模块

集合在一起进行做编译啊做链接啊

我们其实 TI 依赖的是 xdc 的工具

这个主要是说你在 ccs 里面去调用 bios

或者是使用 bios 来进行管理的话

它肯定会去调用 xdc 的工具

然后这个的话这里不做展开的讲了

因为其实 xdc 工具相对也比较复杂

然后我们可能最主要的还是

会用 ccs 的 ide 界面

然后去配置整个的 bios

但是等你做到比较可能稍微深入一点

可能会对 xdc 工具要做一些了解

就是

因为它其实有点类似于

像是一个 make file 的工具

但是它比 make file 提供更多的就是

等于是更灵活的语法和空间

它可能会有一些地方

需要你手动的去用 xdc 工具去调

这个一般情况下可能不会遇到

但是做的比较深入的话

你可能需要去看 xdc 的一些脚本

然后 ipc 这一块呢

主要是提供刚才讲的核间通信这一块

因为我们是一个异构的核

就是 ARM 核 和 DSP 核还有 M4 的核

在这些核间要进行这种通信的话

我们需要依赖一个 library

来做一个平台来做

来做一个平台来做

来提供一个统一的一个 API 的接口

当然你也可以说我们用最简单的方式

比如说依赖芯片的

芯片的里面的 mail box

或者是芯片内部的共享内存空间

或者是用芯片内部的这种核间的中断

这样都可以

但是 IPC 给大家提供的是一个

统一的一个标准的 API 的函数

这样你可以在每个核上面

不管是 ARM 核 M4 还是在 dsp 上面

它都能够去调用 IPC 里面的 API 来做

所以能保证你的代码的一致性

当然这个 IPC 它相对起来

它有一些可能你需要

学习它的 API 怎么调用啊

然后 ARM 上怎么去用这个 IPC 啊

dsp 怎么用这个 IPC 啊

用起来的话可能是需要进行一些学习的工作

然后我们也提供了相应的文档

大家可以去参照这些文档

去看看它的有一些最基本的例子

比如说像代码的例子啊

有些数据通信的例子啊 mail 的例子啊

都可以通过这些例子和文档来进行一些学习

然后 ndk 这一块主要是提供 TCP/IP 协议栈

但是这一块 ndk 主要是跑在 dsp 上的 TCP/IP

Linux 本身自带有 它本身内部就有 TCP/IP 协议栈

所以用不着 ndk 这一块

然后 ndk 这一块现在

应该说在 dsp

因为我们现在是 soc 的系统

所以在 dsp 再去跑一个 ndk 的

这种 TCP/IP 协议栈越来越少了

一般情况下

TCP/IP 这一块还是放到 ARM 里面来做

然后其它的就是我们在 processor SDK 里面

提供的一些工具

就是比如说 ctool

这是一个实时调试的一些工具

这个可以大家找一下

因为是包含了一些

关于我们可以在 bios 系统里进行

比如我进程运行的时间

我的中断响应时间

我们可以把这些东西都显示在

我们的 CCS 的 ide 界面里面

它可以作为一种调试的手段

所以 ctools 和 uia 主要是给它提供一个

可视化的一种调试的界面

当然这里面都需要是你跑的系统是 bios

因为它需要通过 bios 的一些进程

去下载一些数据

然后它才能通过这些工具来进行分析

然后对于我们

就是 RTOS 这一块来说

RTOS 因为它的这个驱动的分层

可能跟 Linux 又不太一样

它最底层的话是一个 CSL

就是 cheap support library

就是基于寄存器级别的一个编程

然后把寄存器 CSL 封装到我们的 PDK

就是 peripheral device driver 里面

封装到这个里面因为你上层可能会跑

我们的 RTOS 系统

或者是跑

或者是纯粹的你自己的一些定制的一些东西

但是为了把这一层与我们的驱动层隔开

所以在这个里面实际上

加入了一个 OSAL 以在写驱动

就是定制驱动的时候

因为如果你用 RTOS 的话

可能会牵涉到这一块定制的问题

但你如果你在写自己的一些

使用自己的一些操作系统

或者是说

不使用操作系统的情况下

你要用 PDK 的话

你可能要去定制这些 OSAL

OS 适配层的一些 API

因为它这些 API

比如说最简单的一个例子就是内传输

如果在 RTOS 里面

它是有特定的函数

它是有特定的函数

来做这个

但是如果你在自己的 OS

或者是自己的这些代码里面的话

你怎么去分配这些内存

它是需要你自己对这个 API 进行提示的

所以一般做移植的话

它需要把在这个 OSAL 来

定制一下才能使用我们 PDK 这一块的东西

然后那个

当然你也可以就是最简单的方式

当然也是最直接的方式

你可以基于 CSL 来做

如果 CSL 就不牵涉到 OSAL 这一层了

如果你基于 CSL 来做的话呢

就相对比较麻烦的是

你需要去就是要非常了解底层所有寄存器的

这些能控制什么 能做什么

当然简单的接口可能没有问题

像 URT 像 I2C

这些接口寄存器的数量非常的少

可能应该问题不大

但是如果比较复杂的一些加速器

或者是比较复杂的一些接口的话

要读的 要写的寄存器会比较多

所以这个地方工作量就会稍微大一些

这个时候可能就要根据你自己的选择吧

底层你直接写寄存器肯定是效率最高的

也是你灵活性最强的

然后 PDK 这一块

给你提供的一个标准的 API

但是呢它因为封装呢有两三层在里面

所以它的就是怎么讲呢

就是有很多调试的话并不是那么的简单

就是如果比如说里面你使用的不正确的话

它里面出错了

然后具体调试到里面

这个里面还是会有点麻烦的

这个刚才也已经讲过了

我们其实 CSL 就是最底层的

基于寄存器级别的 libarary

然后再往上是封装成这个 LLD

然后整个这一套系统形成了

我们的 RTOS 里面的驱动

然后对于我们刚才讲的 PDK

就是我们外设驱动这一块

你可以到 PDK 的目录底下

你可以看到所有的不同外设

它都有自己的一些驱动

然后这些驱动就等于是

它给你提供了一些标准的 API

然后你可以直接调用这些 API 做一些

做完初始化之后调用这些 API

就可以对这些外设进行操作

但是要注意的是就是说 Linux

可能也会用到这些外设

你在 dsp 底下来对这些外设进行操作的时候

你要注意这两个会有互斥的

或者是有一些数据共享的一些问题

这个问题是没办法在软件上来规避的

你必须在系统设计的层面就要去考虑这个问题

然后这个是举了一个最简单的例子

然后就是说我们使用 UART

就是最简单的一个串口为例

然后我们怎么去做通过调用这个我们

PDK 里面的 API

来做整个 UART 的一个收发

首先是做一个建立一个 UART 的一个实体

然后对它进行

你可以把你需要初始化的参数

填到这个 struct 里面

然后它调用它的 LLD 里面初始化的函数

对它进行一个初始化的操作

然后当你 UART open 打开以后

也可以调用它标准的 UART read

或者是 UART write

这些标准的一些函数

来对 UART 进行就是读写的一些操作吧

然后如果你不使用它的话

你可以调用它的 UART 的 close 来关掉它

所以一般情况下你看到 LLD 里面

它因为把整个的就是这些驱动的操作

都封装到它的底层

它提供给上层的主要就像这种

一些很简单的一些函数

就是对于

就是应用层的这些软件编程的话是非常友好的

但是对于底层驱动的工程师来说

如果比如说你的 UART read 的时候突然出错

或者是 UART read

这底层读上来的东西有些不对

这时候你要去调的话是会比较麻烦的

所以这个需要大家来

从不同的方面来考虑这个问题

从一开始调试的时候

觉得大家可以先用最简单的 CSL 来调

保证你的 UART 是一个

能够工作在一个稳定的状态

然后你了解那些 UART 的一些寄存器的状态

或者是其它的一些外设的寄存器

你能够读懂它寄存器的状态到底是什么意思

然后你再把这些接口这些库都放上去

然后如果某一天真的出现了问题

你还是需要通过读那些底层的寄存器

来看你的接口是不是工作在一个正常的状态下

然后 OSAL 这一块就是我们的这个

就是刚才讲的适配层

因为 driver 的 API 它里面

不可避免的还是要牵扯到

比如说分配内存啊 还有分配中断啊

这些类似的一些操作

所以这些操作都是要通过 OSAL

所以这些操作都是要通过 OSAL

提供的一些标准的 API 来做

这一块就封装了所有的关于可操作系统

比如调度器啊 内存分配啊

这些相关的一些操作

当然如果是你自己定义的操作系统

当然如果是你自己定义的操作系统

或者是自己的一些

就是没有操作系统的环境的话

因为 dsp 上面有可能很多客户

就写了一个 while 循环就来做了

然后你需要去定制这个 OSAL

自己写里面的 API

才能够调用这些驱动

才能够调用这些驱动

这个是我们刚才讲的就是

我们不管是 processor SDK Linux 的版本也好

RTOS 的版本也好

还是整个 processor training 也好

这个在我们 TI 的官网上你搜这个

processor SDK 都可以进到

我们的 wiki 的一些支持的页面里面

然后你可以去找到这些指南

或者是找到一些相关的培训的资料和视频

可以先去看一下

然后 processor 的 SDK 介绍就到这

然后看看大家还有没有相关的一些问题

视频报错
手机看
扫码用手机观看
收藏本课程

视频简介

处理器 SDK RTOS

所属课程:处理器SDK介绍_2016 TI 嵌入式产品研讨会实录 发布时间:2016.08.30 视频集数:3 本节视频时长:00:18:43
SDK处理器概览、SDK处理器 Linux、SDK处理器RTOS介绍。
TI培训小程序