用FreeRTOS,使用队列怎么发送一个结构体
一个使用结构体例子:
struct AMessage
portCHAR ucMessageID;
portCHAR ucData[ 20 ];
}xMessage;
unsigned portLONG ulVar = 10UL;
void vATask( voidvoid *pvParameters )
xQueueHandle xQueue1, xQueue2;
struct AMessage *pxMessage;
/*创建一个队列,队列能包含10个unsigned long类型的值。*/
xQueue1 = xQueueCreate( 10, sizeof( unsigned portLONG ) );
/* 创建一个队列,队列能包含10个 Amessage结构体指针类型的值。
这样可以通过传递指针变量来包含大量数据。*/
xQueue2 = xQueueCreate( 10, sizeof( struct AMessage * ) );
if( xQueue1 != 0 )
/*1个unsigned long型数据入队.如果需要等待队列空间变的有效,
会最多等待10个系统节拍周期*/
if( xQueueSend( xQueue1, ( voidvoid * ) ulVar, ( portTickType ) 10 ) !=pdPASS )
/*消息入队失败*/
if( xQueue2 != 0 )
/* 发送一个指向结构体Amessage的对象,如果队列满也不等待 */
pxMessage = xMessage;
xQueueSend( xQueue2, ( voidvoid * ) pxMessage, ( portTickType ) 0 );
//... 任务其余代码.
什么是RTOS系统
实时多任务操作系统(RTOS)1.实时多任务操作系统(RTOS)
(1)更加面向硬件系统,而不是操作者
嵌入式系统处理器一般都是独立工作的,没有人的直接参与;即使参与,也没有大量的文字信息输出,这是和桌面计算机有所不同的。因此RTOS着重面向的是硬件,而不是具有完整的人机界面。
(2)实时性
单片机系统的监测、控制、通信等工作都要求实时性,一旦出现有关情况,CPU能够及时响应,刻不容缓。为此,一个实用的RTOS都应具有完善的中断响应机制,保证中断响应潜伏时间足够短。
(3)多任务
半导体技术的发展和应用复杂性的增长促使CPU的处理能力越来越高,当今的一片16位或32位单片机,在运算速度、寻址能力等方面可以相当于8位单片机的几十片之和。在这样强大的处理器上运行应用程序,必然不是整块,而是根据所要实现的若干方面功能,划分为数个任务,这样有利于软件的开发和维护。
因此单片机系统中采用的RTOS必然是支持多任务的,并能够根据各个任务的轻重缓急,合理地在它们之间分配CPU和各种资源的占用时间。
(4)不同的典型外设驱动支持
单片机的典型片内外设为定时器、A/D、PWM、D/A、串行口、LCD/LED接口,CAN-bus、IC-bus等。根据处理器类型的不同,RTOS在出厂时一般附带若干上面硬件接口的驱动程度,而网卡等片外设备的驱动程序,以及其它一些高级驱动函数,如兼容DOS的文件系统、TCP/IP协议等,则需要另行选购。以RTOS为基础和接口标准,可以设计出大量的库函数驱动模块,并根据实际需要选择或裁剪。
(5)高可靠性
一般计算机的操作系统出现问题,例如死机,除数据丢失等外,不会有太大的问题;而单片机系统一般都是和工业控制、交通工具、医用器械等机电系统密切相关,不适当的输出甚至不及时的输出都可能会带来财产损失和安全问题。因此嵌入式系统中的RTOS要求高可靠性,发行之前必须经过严格的测试。这是一个耗费时间和精力的过程,也是RTOS价格普遍高于一般操作系统的原因之一。
2.RTOS是一个内核
典型的单片机程序在程序指针复位后,首先进行堆栈、中断、中断向量、定时器、串行口等接口设置、初始化数据存储区和显示内容,然后就来到了一个监测、等待或空循环,在这个循环中,CPU可以监视外设、响应中断或用户输入。
这段主程序可以看作是一个内核,内核负责系统的初始化和开放、调度其它任务,相当于C语言中的主函数。
RTOS就是这样的一个标准内核,包括了各种片上外设初始化和数据结构的格式化,不必、也不推荐用户再对硬件设备和资源进行直接操作,所有的硬件设置和资源访问都要通过RTOS核心。硬件这样屏蔽起来以后,用户不必清楚硬件系统的每一个细节就可以进行开发,这样就减少了开发前的学习量。
一般来说,对硬件的直接访问越少,系统的可靠性越高。RTOS是一个经过测试的内核,与一般用户自行编写的主程序内核相比,更规范,效率和可靠性更高。对于一个精通单片机硬件系统和编程的“老手”而言,通过RTOS对系统进行管理可能不如直接访问更直观、自由度大,但是通过RTOS管理能够排除人为疏忽因素,提高软件可靠性。
另外,高效率地进行多任务支持是RTOS设计从始至终的一条主线,采用RTOS管理系统可以统一协调各个任务,优化CPU时间和系统资源的分配,使之不空闲、不拥塞。针对某种具体应用,精细推敲的应用程序不采用RTOS可能比采用RTOS能达到更高的效率;但是对于大多数一般用户和新手而言,采用RTOS是可以提高资源利用率的,尤其是在片上资源不断增长、产品可靠性和进入市场时间更重要的今天。
3.RTOS是一个平台
RTOS建立在单片机硬件系统之上,用户的一切开发工作都进行于其上,因此它可以称作是一个平台。采用RTOS的用户不必花大量时间学习硬件,和直接开发相比起点更高。
RTOS还是一个标准化的平台,它定义了每个应用任务和内核的接口,也促进了应用程序的标准化。应用程序标准化后便于软件的存档、交流、修改和扩展,为嵌入式软件开发的工程化创造了条件、减少开发管理工作量。嵌入式软件标准化推广到社会后,可以促进软件开发的分工,减少重复劳动,近来出现的建立于RTOS上的文件和通信协议库函数产品等就是实例。
RTOS对于开发单位和开发者个人来说也是一种提高。引入RTOS的开发单位,相当于引入了一套行业中广泛采用的嵌入式系统应用程序开发标准,使开发管理更简易、有效。基于RTOS和C语言的开发,具有良好的可继承性,在应用程序、处理器升级以及更换处理器类型时,现存的软件大部分可以不经修改地移植过来。
对于开发人员来说,则相当于在程序设计中采用一种标准化的思维方式,提高知识创造的效率;同时因为具有类似的思路,可以更快地理解同行其它人员的创造成果。
4.RTOS产生并得到迅速发展的原因
单片机处理器能力的提高和应用程序功能的复杂化、精确化,迫使应用程序划分为多个重要性不同的任务,在各任务间优化地分配CPU时间和系统资源,同时还要保证实时性。靠用户自己编写一个实现上述功能的内核一般是不现实的,而这种需求又是普遍的。在这种形势之下,由专业人员编写的、满足大多数用户需要的高性能RTOS内核就是一种必然结果了。
对程序实时性和可靠性要求的提高也是RTOS发展的一个原因。此外,单片机系统软件开发日趋工程化,产品进入市场时间不断缩短,也迫使管理人员寻找一种有利于程序继承性、标准化、多人并行开发的管理方式。从长远的意义上来讲,RTOS的推广能够带来嵌入式软件工业更有效、更专业化的分工,减少社会重复劳动、提高劳动生产率。
5.RTOS的基本特征
(1)任务
任务(Task)是RTOS中最重要的操作对象,每个任务在RTOS的调用下由CPU分时执行。激活的或当前任务是CPU正在执行的任务,休眠的任务是在存储器中保留其执行的上下文背景、一旦切换为当前任务即可从上次执行的末尾继续执行的任务。任务的调度目前主要有时间分片式(TimeSlicing)、轮流查询式(Round-Robin)和优先抢占式(Preemptive)三种,不同的RTOS可能支持其中的一种或几种,其中优先抢占式对实时性的支持最好。
(2)任务切换
RTOS管理下的系统CPU和系统资源的时间是同时分配给不同任务的,这样看起来就象许多任务在同时执行,但实际上每个时刻只有一个任务在执行,也就是当前任务。任务的切换有两种原因。当一个任务正常地结束操作时,它就把CPU控制权交给RTOS,RTOS则检查任务队列中的所有任务,判断下面那个任务的优先级最高,需要先执行。另一种情况是在一个任务执行时,一个优先级更高的任务发生了中断,这时RTOS就将当前任务的上下文保存起来,切换到中断任务。RTOS经常性地整理任务队列,删除结束的任务,增加新的要执行任务,并将其按照优先级从大到小的顺序排列起来,这样可以合理地在各个任务之间分配系统资源。
(3)消息和邮箱
消息(Message)和邮箱(Mailbox)是RTOS中任务之间数据传递的载体和渠道,一个任务可以有多个邮箱。通过邮箱,各个任务之间可以异步地传递信息,没有占用CPU时间的查询和等待。当RTOS包含片上总线接口驱动功能时,各个单片机之间的通信也通过邮箱的方式来进行,用户并不需要了解更深的关于硬件的内容。
(4)旗语
旗语(Semaphore)相当于一种标志(Flag),通过预置,一个事件的发生可以改变旗语。一个任务可以通过监测旗语的变化来决定其行动,在监测旗语变化的时候不消耗CPU时间,旗语对任务的触发是由RTOS来完成的。通过使用旗语,一个任务在等待事件变化的时候就可以不必不断查询,而把CPU时间出让给其它任务。
(5)存储区分配
RTOS对系统存储区进行统一分配,分配的方式可以是动态的或静态的,每个任务在需要存储区时都要向RTOS内核申请。RTOS通过使用存储分配类核心对象管理数据存储器,在动态分配时能够防止存储区的零碎化。
(6)中断和资源管理
RTOS提供了一种通用的设计用于中断管理,有效率而灵活,这样可以实现最小的中断潜伏时间和最大的中断响应度。RTOS内核中的资源对象类则实现了对系统实体资源或虚拟资源的独占式访问,一个任务可以取得对资源的唯一访问权,其它任务在资源释放以前无法访问,这样可以避免资源冲突。设计完善的RTOS具有检查可能导致系统死锁的资源调用设计。
上面是RTOS的基本特征。根据产品的不同,它可能还包含许多其它功能。
6.你的处理器是不是需要一套实时多任务操作系统?
RTOS是目前嵌入式系统领域的热点之一,是流行的开发平台,但它毕竟对于许多用户来说还是昂贵的,还会大量改变用户习惯的开发方式,因此在引入RTOS以前对必要性进行考察还是明智的。你可以思考下面的几个问题:
(1)你的处理器控制的时间和方式和你预想的一样吗?
(2)你是否发现自己花费很多时间盘算怎样使一段代码在该执行的时候执行?
(3)你是否花费太多时间在中断子程序上,知道主程序不可能顺序地处理中断事件,便试图编出所有代码来处理中断事件?
(4)你是否发现自己在不断地测试标志或调用测试标志的子程序,来判断是否应当执行一段子程序?
如果你对上面问题的回答有一个以上是肯定的话,那么就是到了需要一套实时多任务操作系统将你从编程的琐碎中解脱出来的时候了。
8.目前有什么样的RTOS?
当你在电子杂志上寻找RTOS的时候,可能会发现世界上研制RTOS产品的公司多得令你无所适从;但是仔细阅读后会发现,它们的产品可能只覆盖几种处理器,而且是你所不熟悉的。目前产品比较全面的公司主要有美国的CMXCompany和EmbeddedSystemProducts(ESP),Inc.,它们对中国单片机工业流行的单片机,如8051,251,196/296,P51XA,68xxx等都有RTOS及其相关的接口库函数产品,提供源程序代码,没有每个产品的二进制版税。其中CMX公司的产品价格略低,较适合中国市场;而ESP公司的产品则有较丰富的库函数支持
stm32使用freertos的时候能不能使用定时器
在进入中断函数后,清除标志位。不会在函数没执行完就进入下次中断响应 如果想改变定时时间,可以先失能定时器,配置完后再使能
在学习freertos之前,应学习哪些东西
学习FreeRTOS前的准备工作这里只要做好两点就可以了。1, 从官网下载最新的程序包2, 官网有FreeRTOS每个函数的API说明,已经相应API的例子,其实源码的.h文件里面也有大部分函数的使用例子 教程计划1 先把自己做的这几个例子讲解一下,关键是分析一下源码,源码必须得分析,要不知其然不知其所以然。2 然后把官方的这几个例子讲解一下,说这几个例子的主要目的是充分学习官方是如何使用这个RTOS的,非常有参考价值。3 针对我们板子自己的外设,做一套完整的,基于FreeRTOS的底层驱动,让这些驱动能够更加有效的在FreeRTOS下面工作。在学习freertos之前,应学习哪些东西
介绍几种主流嵌入式操作系统的特点,并分析比较 哥们,我现在纠结这个问题,可以给点指点吗
如果你是学习阶段的话,那LINUX和UCOS-II是比较合适的
uc/os和uclinux操作系统是两种性能优良源码公开且被广泛应用的的免费嵌入式操作系统,可以作为研究实时操作系统和非实时操作系统的典范。本文通过对 uc/os和uclinux的对比,分析和总结了嵌入式操作系统应用中的若干重要问题,归纳了嵌入式系统开发中操作系统的选型依据。
两种开源嵌入式操作系统介绍
uc/os和uclinux操作系统,是当前得到广泛应用的两种免费且公开源码的嵌入式操作系统。uc/os适合小型控制系统,具有执行效率高、占用空间小、实时性能优良和可扩展性强等特点,最小内核可编译至2k。uclinux则是继承标准linux 的优良特性,针对嵌入式处理器的特点设计的一种操作系统,具有内嵌网络协议、支持多种文件系统,开发者可利用标准linux先验知识等优势。其编译后目标文件可控制在几百k量级。
uc/os是一种免费公开源代码、结构小巧、具有可剥夺实时内核的实时操作系统。其内核提供任务调度与管理、时间管理、任务间同步与通信、内存管理和中断服务等功能。
uclinux是一种优秀的嵌入式linux版本。uclinux是micro-conrol-linux的缩写。同标准linux相比,它集成了标准linux操作系统的稳定性、强大网络功能和出色的文件系统等主要优点。但是由于没有mmu(内存管理单元),其多任务的实现需要一定技巧。
两种嵌入式操作系统主要性能比较
嵌入式操作系统是嵌入式系统软硬件资源的控制中心,它以尽量合理的有效方法组织多个用户共享嵌入式系统的各种资源。其中用户指的是系统程序之上的所有软件。所谓合理有效的方法,指的就是操作系统如何协调并充分利用硬件资源来实现多任务。复杂的操作系统都支持文件系统,方便组织文件并易于对其规范化操作。
嵌入式操作系统还有一个特点就是针对不同的平台,系统不是直接可用的,一般需要经过针对专门平台的移植操作系统才能正常工作。进程调度、文件系统支持和系统移植是在嵌入式操作系统实际应用中最常见的问题,下文就从这几个角度入手对uc/os和uclinux进行分析比较。
进程调度
任务调度主要是协调任务对计算机系统内资源(如内存、i/o设备、cpu)的争夺使用。进程调度又称为cpu调度,其根本任务是按照某种原则为处于就绪状态的进程分配cpu。由于嵌入式系统中内存和i/o设备一般都和cpu同时归属于某进程,所以任务调度和进程调度概念相近,很多场合不加区分,下文中提到的任务其实就是进程的概念。
进程调度可分为"剥夺型调度"和"非剥夺型调度"两种基本方式。所谓"非剥夺型调度"是指:一旦某个进程被调度执行,则该进程一直执行下去直至该进程结束,或由于某种原因自行放弃cpu进入等待状态,才将cpu重新分配给其他进程。所谓"剥夺型调度"是指:一旦就绪状态中出现优先权更高的进程,或者运行的进程已用满了规定的时间片时,便立即剥夺当前进程的运行(将其放回就绪状态),把cpu分配给其他进程
作为实时操作系统,uc/os是采用的可剥夺型实时多任务内核。可剥夺型的实时内核在任何时候都运行就绪了的最高优先级的任务。uc/os中最多可以支持64 个任务,分别对应优先级0~63,
其中0为最高优先级。调度工作的内容可以分为两部分:最高优先级任务的寻找和任务切换。
其最高优先级任务的寻找是通过建立就绪任务表来实现的。uc/os中的每一个任务都有独立的堆栈空间,并有一个称为任务控制块tcb(task control block)数据结构,其中第一个成员变量就是保存的任务堆栈指针。任务调度模块首先用变量 ostcbhighrdy记录当前最高级就绪任务的tcb地址,然后调用os_task_sw() 函数来进行任务切换。
uclinux的进程调度沿用了linux的传统,系统每隔一定时间挂起进程,同时系统产生快速和周期性的时钟计时中断,并通过调度函数(定时器处理函数)决定进程什么时候拥有它的时间片。然后进行相关进程切换,这是通过父进程调用fork 函数生成子进程来实现的。
uclinux系统fork调用完成后,要么子进程代替父进程执行(此时父进程已经 sleep),直到子进程调用exit退出;要么调用exec执行一个新的进程,这个时候产生可执行文件的加载,即使这个进程只是父进程的拷贝,这个过程也不可避免。当子进程执行exit或exec后,子进程使用wakeup把父进程唤醒,使父进程继续往下执行。
uclinux由于没有mmu管理存储器,其对内存的访问是直接的,所有程序中访问的地址都是实际的物理地址。操作系统队内存空间没有保护,各个进程实际上共享一个运行空间。这就需要实现多进程时进行数据保护,也导致了用户程序使用的空间可能占用到系统内核空间,这些问题在编程时都需要多加注意,否则容易导致系统崩溃。
由上述分析可以得知,uc/os内核是针对实时系统的要求设计实现的,相对简单,可以满足较高的实时性要求。而uclinux则在结构上继承了标准linux的多任务实现方式,仅针对嵌入式处理器特点进行改良。其要实现实时性效果则需要使系统在实时内核的控制下运行,rt-linux就是可以实现这一个功能的一种实时内核。
文件系统
所谓文件系统是指负责存取和管理文件信息的机构,也可以说是负责文件的建立、撤销、组织、读写、修改、复制及对文件管理所需要的资源(如目录表、存储介质等)实施管理的软件部分。
uc/os是面向中小型嵌入式系统的,如果包含全部功能(信号量、消息邮箱、消息队列及相关函数),编译后的uc/os内核仅有6~10kb,所以系统本身并没有对文件系统的支持。但是uc/os具有良好的扩展性能,如果需要的话也可自行加入文件系统的内容。
uclinux则是继承了linux完善的文件系统性能。其采用的是romfs文件系统,这种文件系统相对于一般的ext2文件系统要求更少的空间。空间的节约来自于两个方面,首先内核支持romfs文件系统比支持ext2文件系统需要更少的代码,其次romfs文件系统相对简单,在建立文件系统超级块(superblock)需要更少的存储空间。romfs文件系统不支持动态擦写保存,对于系统需要动态保存的数据采用虚拟ram盘的方法进行处理(ram盘将采用ext2文件系统)。
uclinux还继承了linux网络操作系统的优势,可以很方便的支持网络文件系统且内嵌tcp/ip协议,这为uclinux开发网络接入设备提供了便利。
由两种操作系统对文件系统的支持可知,在复杂的需要较多文件处理的嵌入式系统中uclinux是一个不错的选择。而uc/os则主要适合一些控制系统。
操作系统的移植
嵌入式操作系统移植的目的是指使操作系统能在某个微处理器或微控制器上运行。uc/os和uclinux都是源码公开的操作系统,且其结构化设计便于把与处理器相关的部分分离出来,所以被移植到新的处理器上是可能的。
以下对两种系统的移植分别予以说明。
(1)uc/os的移植
要移植uc/os,目标处理器必须满足以下要求;
·处理器的c编译器能产生可重入代码,且用c语言就可以打开和关闭中断;
·处理器支持中断,并能产生定时中断;
·处理器支持足够的ram(几k字节),作为多任务环境下的任务堆栈;
·处理器有将堆栈指针和其他cpu寄存器读出和存储到堆栈或内存中的指令。
在理解了处理器和c编译器的技术细节后,uc/os的移植只需要修改与处理器相关的代码就可以了。
具体有如下内容:
·os_cpu.h中需要设置一个常量来标识堆栈增长方向;
·os_cpu.h中需要声明几个用于开关中断和任务切换的宏;
·os_cpu.h中需要针对具体处理器的字长重新定义一系列数据类型;
·os_cpu_a.asm需要改写4个汇编语言的函数;
·os_cpu_c.c需要用c语言编写6个简单函数;
·修改主头文件include.h,将上面的三个文件和其他自己的头文件加入。
(2)uclinux的移植
由于uclinux其实是linux针对嵌入式系统的一种改良,其结构比较复杂,相对 uc/os,uclinux的移植也复杂得多。一般而言要移植uclinux,目标处理器除了应满足上述uc/os应满足的条件外,还需要具有足够容量(几百k字节以上)外部rom和ram。
uclinux的移植大致可以分为3个层次:
·结构层次的移植,如果待移植处理器的结构不同于任何已经支持的处理器结构,则需要修改linux/arch目录下相关处理器结构的文件。虽然uclinux内核代码的大部分是独立于处理器和其体系结构的,但是其最低级的代码也是特定于各个系统的。这主要表现在它们的中断处理上下文、内存映射的维护、任务上下文和初始化过程都是独特的。这些例行程序位于linux/arch/目录下。由于linux所支持体系结构的种类繁多,所以对一个新型的体系,其低级例程可以模仿与其相似的体系例程编写。
·平台层次的移植,如果待移植处理器是某种uclinux已支持体系的分支处理器,则需要在相关体系结构目录下建立相应目录并编写相应代码。如mc68ez328就是基于无mmu的m68k内核的。此时的移植需要创建 linux/arch/m68knommu/platform/ mc68ez328目录并在其下编写跟踪程序(实现用户程序到内核函数的接口等功能)、中断控制调度程序和向量初始化程序等。
·板级移植,如果你所用处理器已被uclinux支持的话,就只需要板级移植了。板级移植需要在linux/arch/?platform/中建立一个相应板的目录,再在其中建立相应的启动代码crt0_rom.s或crt0_ram.s和链接描述文档rom.ld或ram.ld就可以了。板级移植还包括驱动程序的编写和环境变量设置等内容。
结语
通过对uc/os和uclinux的比较,可以看出这两种操作系统在应用方面各有优劣。 uc/os占用空间少,执行效率高,实时性能优良,且针对新处理器的移植相对简单。uclinux则占用空间相对较大,实时性能一般,针对新处理器的移植相对复杂。但是,uclinux具有对多种文件系统的支持能力、内嵌了tcp/ip协议,可以借鉴linux丰富的资源,对一些复杂的应用,uclinux具有相当优势。例如cisco 公司的 2500/3000/4000 路由器就是基于uclinux操作系统开发的。总之,操作系统的选择是由嵌入式系统的需求决定的。简单的说就是,小型控制系统可充分利用uc/os小巧且实时性强的优势,如果开发pda和互联网连接终端等较为复杂的系统则uclinux是不错的选择。
还有就是如果从开发的工具方便好用,易用的角度来看,那些收费的系统用起来更爽一些
FreeRTOS 移栽要点怎么解决
FreeRTOS 的移植主要需要改写如下三个文件。
1. portmacro.h
2. port.c
3. port.asm
如果采用的C编译器允许在C 代码中插入汇编,并且支持用C语言写中断处理函数。则port.asm 文件的内容是可以合并到port.c 中的。
下面以将 FreeRTOS 移植到FreeScale 68HCS12 内核的单片机为例,开发环境采用:CodeWarriorDevelopment Studio V5.9.0
之所以采用FreeScale 68HCS12 作为示例 CPU,是因为我以前写过一篇将uC/OS-II移植到FreeScale 68HCS12 核单片机的笔记。采用同样的CPU,同样的开发环境,可以方便我们比较两种不同实时操作系统的移植代码的异同。另外,FreeScale 68HCS12 相对ARM、MIPS 等构架要简单的多。移植代码量相对来说也要小一些,因此也更容易入门。
portmacro.h
portmacro.h 主要包括两部分内容,第一部分定义了一系列内核代码中用到的数据类型。FreeRTOS 与 uC/OS-II 一样,并不直接使用char、int 等这些原生类型,而是将其重新定义为一系列以port开头的新类型。在uC/OS-II的移植代码中,通常采用 typedef 来定义新的类型,而FreeRTOS的作者似乎更喜欢用宏定义。下面是相应的代码片段。
portTickType 既可以定义为16位的无符号整数,也可以定义为32位的无符号整数。具体用那种定义,要看 FreeRTOSConfig.h 文件中如何设置configUSE_16_BIT_TICKS。
然后是一些硬件相关的定义。包括数据对其方式,堆栈增长方向,Tick Rate,还有任务切换的宏。
portBYTE_ALIGNMENT 在uC/OS-II 是不需要的,FreeRTOS的代码中在分配任务堆栈空间时用到这个宏定义。
portSTACK_GROWTH 定义为1 表示堆栈是正向生长的,-1为逆向生长的。一般来说堆栈都是倒生的,68HCS12 也不例外,因此这里定义为 (-1)。
多说一句在 uC/OS-II 中,对应的宏是OS_STK_GROWTH, 1 表示逆向生长,0表示正向生长。
portTICK_RATE_MS 只在应用代码中可能会用到,表示的是Tick 间间隔多少 ms。
portYIELD() 实现的是任务切换,相当于 uC/OS-II中的 OS_TASK_SW()。
portNOP() 顾名思义就是对空操作定义了个宏。具体在FreeRTOS 代码中哪里用到了这个宏没注意过,但是想必是有地方用到了。
然后是有关临界区的处理代码:
这部分的代码挺长的,不过其实是对 Small Memery Model 和Banked Memery Model 分别提供了如下两个宏定义:
portRESTORE_CONTEXT()
portSAVE_CONTEXT()
使用哪一套宏定义是通过BANKED_MODEL 这个宏是否被定义来确定的。其实,CodeWarrior Development Studio V5.9.0 中提供的官方代码中给出了一种更正规的判断方法:
FreeRTOS中保存和恢复任务上下文环境的代码与uC/OS-II中的大同小异,唯一有点区别的就是要保存uxCriticalNesting 的值。原因上面已经介绍过了。
之所以要搞这两个宏,是为了利用某些C编译器的扩展功能对任务函数进行更好的优化。CodeWarrior 并不提供相关的功能,所以在这里任务就是普通的函数。
实用的RTOS都应具有完善的中断响应机制,保证中断响应潜伏时间足够短。(3)多任务半导体技术的发展和应用复杂性的增长促使CPU的处理能力越来越高,当今的一片16位或32位单片机,在运算速度、寻址能力等方面可以相当于8位单片机的几十片之和。在这样强大的处理器上运行应用程序,