uCOS-Ⅱ源码分析之uC-CPU文件夹

此文共连载分析三个uCOS-Ⅱ的三个源码文件夹:uC-CPU 、uC-LIB 、uCOS-Ⅱ

uC-LIB文件夹目录:ARM-Cortex-M3 / cpu_a.asm

                                                          cpu_c.c
                                                          cpu.h
                             cpu_def.h  

cpu_def.h

  • 这个文件中定义了一些 CPU 有关的宏定义,分为三类:

1、CPU 字节长度的定义,理想情况下 CPU 的字长应该是由 sizeof() 函数计算出来的,但是 sizeof() 函数必须在 CPU 运行中才能进行计算,所以在 uCOS 中直接用宏定义定义了出来

#define  CPU_WORD_SIZE_32           4       // 定义 CPU 字节长度为 4 字节

2、CPU 字节顺序的定义,也就是 CPU 的大/小端模式的定义。

#define  CPU_ENDIAN_TYPE_NONE       0       // 不知道是大端模式还是小端模式

#define  CPU_ENDIAN_TYPE_BIG        1       // 大端模式

#define  CPU_ENDIAN_TYPE_LITTLE     2        // 小端模式   

3、临界区的定义和配置,临界区是指一个共用资源的程序片段,但共用资源程序片段一次只能被一个线程占用,当有一个线程正在访问临界区时,其他线程或进程就必须等待,以临界区共用资源的互斥使用(举例:打印机的使用,一个用户正在使用打印机,在未使用完成时,其他用户只能等待前一用户使用完成后才能使用)。

#define  CPU_CRITICAL_METHOD_NONE                  0    // 发生临界区问题是不解决
// 在有线程进入临界区前,暂时禁止中断响应,防止高优先级中断打断正在临界区的线程,在退出临界区时再使能中断
#define  CPU_CRITICAL_METHOD_INT_DIS_EN            1    // 用禁止/使能中断的方法解决临界区问题

#define  CPU_CRITICAL_METHOD_STATUS_STK            2    // 将临界区状态保存在栈中

#define  CPU_CRITICAL_METHOD_STATUS_LOCAL          3    // 将临界区状态保存在局部变量中

cpu.h

  • 核心的就是进入临界区和退出临界区的两个宏
  • 其他的都是一些数据类型重定义和 cpu_c.c 文件中函数的声明
//设置了临界区解决办法,将临界区状态保存在局部变量中
# define  CPU_CFG_CRITICAL_METHOD        CPU_CRITICAL_METHOD_STATUS_LOCAL
//进入临界区前调用这个宏,实现将 CPSR 寄存器备份,然后关闭中断响应
# define  CPU_CRITICAL_ENTER()           { cpu_sr = CPU_SR_Save(); }
//退出临界区后调用这个宏,实现将 CPSR 寄存器还原,中断响应开启
# define  CPU_CRITICAL_EXIT()            { CPU_SR_Restore(cpu_sr); }

cpu_c.c

  • 首先是关于对位带操作的宏定义,定义了 SRAM 内存的位带访问地址范围和外设寄存器的位带访问地址范围。
  • 然后是函数的定义,包括位带清零和置位、使能和禁止 CPU 内部中断源、设置和读取中断源的优先级的函数,这些函数的实现都用到了 NVIC 模块的设置寄存器的位定义和进入/退出临界区时的两个设置宏。
  • uCOS-Ⅱ 中的临界区解决办法用的全部都是 #define CPU_CRITICAL_METHOD_STATUS_LOCAL 这一种办法,其他两个办法没有使用。
  • 其中存储 CPSR 寄存器的局部变量是 CPU_SR 类型的 cpu_sr,这个局部变量是配合进入/退出临界区的两个配置宏进行使用的,看到这个变量定义,后面一定就用到了临界区的操作。

cpu_a.asm

文件中用 EXPORT 导出了多个函数,定义了一些汇编语言书写的函数:

    EXPORT  CPU_IntDis      // 全局中断的禁止
    EXPORT  CPU_IntEn       // 全局中断的使能

    EXPORT  CPU_SR_Save     // 将 CPSR 寄存器内容保存到 R0 寄存器中,然后禁止全局中断
    EXPORT  CPU_SR_Restore  // 将 R0 寄存器内容恢复到 CPSR 寄存器中

    EXPORT  CPU_CntLeadZeros    // 前导零计数
    EXPORT  CPU_RevBits         // 二进制层面取反,  1010 ---> 0101

    EXPORT  CPU_WaitForInt      // CPU 立即进入睡眠模式,等待中断唤醒
    EXPORT  CPU_WaitForExcept   // CPU 进入睡眠模式,等待异常唤醒

原文地址:http://blog.51cto.com/ypb39155/2097523

时间: 2024-10-18 03:19:20

uCOS-Ⅱ源码分析之uC-CPU文件夹的相关文章

Linux内核源码分析方法

  一.内核源码之我见 Linux内核代码的庞大令不少人“望而生畏”,也正因为如此,使得人们对Linux的了解仅处于泛泛的层次.如果想透析Linux,深入操作系统的本质,阅读内核源码是最有效的途径.我们都知道,想成为优秀的程序员,需要大量的实践和代码的编写.编程固然重要,但是往往只编程的人很容易把自己局限在自己的知识领域内.如果要扩展自己知识的广度,我们需要多接触其他人编写的代码,尤其是水平比我们更高的人编写的代码.通过这种途径,我们可以跳出自己知识圈的束缚,进入他人的知识圈,了解更多甚至我们一

simlescalar CPU模拟器源码分析

Sim-outorder.c Main函数 Fetch  -->  despetch-->                                issue-->              writeback        -->commit Code text-->fetch queue --> RUU/LSQ(->readyqueue)-->event queue-->删除envent-->RUU/LSQ 功能模拟快速跳过的指令,之后

zg手册 之 python2.7.7源码分析(4)-- pyc字节码文件

什么是字节码 python解释器在执行python脚本文件时,对文件中的python源代码进行编译,编译的结果就是byte code(字节码) python虚拟机执行编译好的字节码,完成程序的运行 python会为导入的模块创建字节码文件 字节码文件的创建过程 当a.py依赖b.py时,如在a.py中import b python先检查是否有b.pyc文件(字节码文件),如果有,并且修改时间比b.py晚,就直接调用b.pyc 否则编译b.py生成b.pyc,然后加载新生成的字节码文件 字节码对象

Hadoop之HDFS原理及文件上传下载源码分析(上)

HDFS原理 首先说明下,hadoop的各种搭建方式不再介绍,相信各位玩hadoop的同学随便都能搭出来. 楼主的环境: 操作系统:Ubuntu 15.10 hadoop版本:2.7.3 HA:否(随便搭了个伪分布式) 文件上传 下图描述了Client向HDFS上传一个200M大小的日志文件的大致过程: 首先,Client发起文件上传请求,即通过RPC与NameNode建立通讯. NameNode与各DataNode使用心跳机制来获取DataNode信息.NameNode收到Client请求后,

Solr4.8.0源码分析(10)之Lucene的索引文件(3)

Solr4.8.0源码分析(10)之Lucene的索引文件(3) 1. .si文件 .si文件存储了段的元数据,主要涉及SegmentInfoFormat.java和Segmentinfo.java这两个文件.由于本文介绍的Solr4.8.0,所以对应的是SegmentInfoFormat的子类Lucene46SegmentInfoFormat. 首先来看下.si文件的格式 头部(header) 版本(SegVersion) doc个数(SegSize) 是否符合文档格式(IsCompoundF

Hadoop之HDFS原理及文件上传下载源码分析(下)

上篇Hadoop之HDFS原理及文件上传下载源码分析(上)楼主主要介绍了hdfs原理及FileSystem的初始化源码解析, Client如何与NameNode建立RPC通信.本篇将继续介绍hdfs文件上传.下载源解析. 文件上传 先上文件上传的方法调用过程时序图: 其主要执行过程: FileSystem初始化,Client拿到NameNodeRpcServer代理对象,建立与NameNode的RPC通信(楼主上篇已经介绍过了) 调用FileSystem的create()方法,由于实现类为Dis

Solr4.8.0源码分析(12)之Lucene的索引文件(5)

Solr4.8.0源码分析(12)之Lucene的索引文件(5) 1. 存储域数据文件(.fdt和.fdx) Solr4.8.0里面使用的fdt和fdx的格式是lucene4.1的.为了提升压缩比,StoredFieldsFormat以16KB为单位对文档进行压缩,使用的压缩算法是LZ4,由于它更着眼于速度而不是压缩比,所以它能快速压缩以及解压. 1.1 存储域数据文件(.fdt) 真正保存存储域(stored field)信息的是fdt文件,该文件存放了压缩后的文档,按16kb或者更大的模块大

Solr4.8.0源码分析(11)之Lucene的索引文件(4)

Solr4.8.0源码分析(11)之Lucene的索引文件(4) 1. .dvd和.dvm文件 .dvm是存放了DocValue域的元数据,比如DocValue偏移量. .dvd则存放了DocValue的数据. 在Solr4.8.0中,dvd以及dvm用到的Lucene编码格式是Lucene45DocValuesFormat.跟之前的文件格式类似,它分别包含Lucene45DocValuesProducer 和Lucene45DocValuesConsumer来实现该文件的读和写. 1 @Ove

Solr4.8.0源码分析(8)之Lucene的索引文件(1)

Solr4.8.0源码分析(8)之Lucene的索引文件(1) 题记:最近有幸看到觉先大神的Lucene的博客,感觉自己之前学习的以及工作的太为肤浅,所以决定先跟随觉先大神的博客学习下Lucene的原理.由于觉先大神主要介绍的是Lucene3.X系的,那我就根据源码以及结合觉先大神的来学习下4.X系的.内容可能会有些变化,且加入下我个人的理解. http://www.cnblogs.com/forfuture1978/archive/2009/12/14/1623597.html 一. 基本类型

SpringMVC处理静态文件源码分析

SpringMVC处理静态资源,主要是两个标签,mvc:resources和mvc:default-servlet-handler.在详细说明他们的原理之前,需要先简单说明下SpringMVC中请求处理机制:HandlerMapping和HandlerAdapter. 1 HandlerMapping和HandlerAdapter的来由 用过python Django框架的都知道Django对于访问方式的配置就是,一个url路径和一个函数配对,你访问这个url,就会直接调用这个函数,简单明了 然