处理器 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 介绍就到这 然后看看大家还有没有相关的一些问题