4、嵌入式学习之uCOS-II基础入门

互斥条件

实现任务间通讯最简便到办法是使用共享数据结构。特别是当所有到任务都在一个单一地址空间下,能使用全程变量、指针、缓冲区、链表、循环缓冲区等,使用共享数据结构通讯就更为容易。虽然共享数据区法简化了任务间的信息交换,但是必须保证每个任务在处理共享数据时的排它性,以避免竞争和数据的破坏。与共享资源打交道时,使之满足互斥条件最一般的方法有:

  • l  关中断
  • l  使用测试并置位指令
  • l  禁止做任务切换
  • l  利用信号量

关中断和开中断

处理共享数据时保证互斥,最简便快捷的办法是关中断和开中断。所示:

Disable interrupts;                                     /*关中断*/
Access the resource (read/write from/to variables);     /*读/写变量*/
Reenable interrupts;                                    /*重新允许中断*/

   μC/OS-Ⅱ在处理内部变量和数据结构时就是使用的这种手段,即使不是全部,也是绝大部分。实际上μC/OS-Ⅱ提供两个宏调用,允许用户在应用程序的C代码中关中断然后再开中断:OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()

void Function (void)
{
    OS_ENTER_CRITICAL();
    
       /*在这里处理共享数据*/
    
    OS_EXIT_CRITICAL();
}

可是,必须十分小心,关中断的时间不能太长。因为它影响整个系统的中断响应时间,即中断延迟时间。当改变或复制某几个变量的值时,应想到用这种方法来做。这也是在中断服务子程序中处理共享变量或共享数据结构的唯一方法。在任何情况下,关中断的时间都要尽量短。

如果使用某种实时内核,一般地说,关中断的最长时间不超过内核本身的关中断时间,就不会影响系统中断延迟。当然得知道内核里中断关了多久。凡好的实时内核,厂商都提供这方面的数据。总而言之,要想出售实时内核,时间特性最重要。

测试并置位

 

    如果不使用实时内核,当两个任务共享一个资源时,一定要约定好,先测试某一全程变量,如果该变量是0,允许该任务与共享资源打交道。为防止另一任务也要使用该资源,前者只要简单地将全程变量置为1,这通常称作测试并置位(Test-And-Set),或称作TASTAS操作可能是微处理器的单独一条不会被中断的指令,或者是在程序中关中断做TAS操作再开中断,如程序所示。

Disable interrupts;                             //关中断
if (‘Access Variable’ is 0)                     //如果资源不可用,标志为0
{                  
    Set variable to 1;                          //置资源不可用,标志为1
    Reenable interrupts;                        //重开中断
    Access the resource;                        //处理该资源
    Disable interrupts;                         //关中断
    Set the ‘Access Variable’ back to 0;        //清资源不可使用,标志为0
    Reenable interrupts;                        //重新开中断
} 
else                                            //否则
{                                        
    Reenable interrupts;                        //开中断
/* You don’t have access to the resource, try back later; *//* 资源不可使用,以后再试; */
}

    有的微处理器有硬件的TAS指令(如Motorola 68000系列,就有这条指令)

 

禁止,然后允许任务切换

 如果任务不与中断服务子程序共享变量或数据结构,可以使用禁止、然后允许任务切换。以μC/OS-Ⅱ的使用为例,两个或两个以上的任务可以共享数据而不发生竞争。注意,此时虽然任务切换是禁止了,但中断还是开着的。如果这时中断来了,中断服务子程序会在这一临界区内立即执行。中断服务子程序结束时,尽管有优先级高的任务已经进入就绪态,内核还是返回到原来被中断了的任务。直到执行完给任务切换开锁函数OSSchedUnlock (),内核再看有没有优先级更高的任务被中断服务子程序激活而进入就绪态,如果有,则做任务切换。虽然这种方法是可行的,但应该尽量避免禁止任务切换之类操作,因为内核最主要的功能就是做任务的调度与协调。禁止任务切换显然与内核的初衷相违。应该使用下述方法。

//程序清单4.11  用给任务切换上锁,然后开锁的方法实现数据共享.
void Function (void)
{
    OSSchedLock();
    
    /* You can access shared data in here (interrupts are recognized) */
    /*在这里处理共享数据(中断是开着的)*/
    OSSchedUnlock();
}

 

信号量(Semaphores)

 信号量实际上是一种约定机制,在多任务内核中普遍使用.信号量用于:

l  控制共享资源的使用权(满足互斥条件)

l  标志某事件的发生

l  使两个任务的行为同步

 

对信号量只能实施三种操作:初始化(INITIALIZE),也可称作建立(CREATE);等信号(WAIT)也可称作挂起(PEND);给信号(SIGNAL)或发信号(POST)。信号量初始化时要给信号量赋初值,等待信号量的任务表(Waiting list)应清为空。

l  等待信号量任务中优先级最高的,或者是

l  最早开始等待信号量的那个任务,即按先进先出的原则(First In First Out ,FIFO)

有的内核有选择项,允许用户在信号量初始化时选定上述两种方法中的一种。但μC/OS-Ⅱ只支持优先级法。如果进入就绪态的任务比当前运行的任务优先级高(假设,是当前任务释放的信号量激活了比自己优先级高的任务)。则内核做任务切换(假设,使用的是可剥夺型内核),高优先级的任务开始运行。当前任务被挂起。直到又变成就绪态中优先级最高任务。

 

//通过获得信号量处理共享数据
OS_EVENT *SharedDataSem;
void Function (void)
{
    INT8U err;
    OSSemPend(SharedDataSem, 0, &err);
    
        /* You can access shared data in here (interrupts are recognized) */
        /*共享数据的处理在此进行,(中断是开着的)*/
    OSSemPost(SharedDataSem);
}

当诸任务共享输入输出设备时,信号量特别有用。可以想象,如果允许两个任务同时给打印机送数据时会出现什么现象。打印机会打出相互交叉的两个任务的数据。例如任务1要打印“I am Task!”,而任务2要打印“I am Task2!”可能打印出来的结果是:“I Ia amm T Tasask k1!2!”

    在这种情况下,使用信号量并给信号量赋初值1(用二进制信号量)。规则很简单,要想使用打印机的任务,先要得到该资源的信号量。图4.1两个任务竞争得到排它性打印机使用权,图中信号量用一把钥匙表示,想使用打印机先要得到这把钥匙。

                            图4.1用获取信号量来得到打印机使用权

 

    上例中,每个任务都知道有个信号表示资源可不可以使用。要想使用该资源,要先得到这个信号。然而有些情况下,最好把信号量藏起来,各个任务在同某一资源打交道时,并不知道实际上是在申请得到一个信号量。例如,多任务共享一个RS-232C外设接口,各任务要送命令给接口另一端的设备并接收该设备的回应。如图4.2所示。

    调用向串行口发送命令的函数CommSendCmd(),该函数有三个形式参数:Cmd指向送出的ASCII码字符串命令。Response指向外设回应的字符串。timeout指设定的时间间隔。如果超过这段时间外设还不响应,则返回超时错误信息。函数的示意代码如程序清单4.12所示。

//程序清单 4.12   隐含的信号量。
INT8U CommSendCmd(char *cmd, char *response, INT16U timeout)
{
    Acquire port's semaphore;
    Send command to device;
    Wait for response (with timeout);
    if (timed out) 
    {
        Release semaphore;
        return (error code);
    } 
    else 
    {
        Release semaphore;
        return (no error);
    }
}

    要向外设发送命令的任务得调用上述函数。设信号量初值为1,表示允许使用。初始化是在通讯口驱动程序的初始化部分完成的。第一个调用CommSendCmd()函数的任务申请并得到了信号量,开始向外设发送命令并等待响应。而另一个任务也要送命令,此时外设正“忙”,则第二个任务被挂起,直到该信号量重新被释放。第二个任务看起来同调用了一个普通函数一样,只不过这个函数在没有完成其相应功能时不返回。当第一个任务释放了那个信号量,第二个任务得到了该信号量,第二个任务才能使用RS-232口。

                    图4.2在任务级看不到隐含的信号量

    计数式信号量用于某资源可以同时为几个任务所用例如,用信号量管理缓冲区阵列(buffer pool),如图2.12所示。缓冲区阵列中共有10个缓冲区,任务通过调用申请缓冲区函数BufReq()向缓冲区管理方申请得到缓冲区使用权。当缓冲区使用权还不再需要时,通过调用释放缓冲区函数BufRel()将缓冲区还给管方。函数示意码如程序清单4.13所示

  

//程序清单 4.13 
BUF *BufReq(void)
{
   BUF *ptr;


   Acquire a semaphore;
   Disable interrupts;
   ptr         = BufFreeList;
   BufFreeList = ptr->BufNext;
   Enable interrupts;
   return (ptr);
}




void BufRel(BUF *ptr)
{
   Disable interrupts;
   ptr->BufNext = BufFreeList;
   BufFreeList  = ptr;
   Enable interrupts;
   Release semaphore;
}

                                    图4.3 计数式信号量的用法

缓冲区阵列管理方满足前十个申请缓冲区的任务,就好像有10把钥匙可以发给诸任务。当所有的钥匙都用完了,申请缓冲区的任务被挂起,直到信号量重新变为有效。缓冲区管理程序在处理链表指针时,为满足互斥条件,中断是关掉的(这一操作非常快)。任务使用完某一缓冲区,通过调用缓冲区释放函数BufRel()将缓冲区还给系统。系统先将该缓冲区指针插入到空闲缓冲区链表中(Linked list)然后再给信号量加1或释放该信号量。这一过程隐含在缓冲区管理程序BufReq()和BufRel()之中,调用这两个函数的任务不用管函数内部的详细过程。

信号量常被用过了头。处理简单的共享变量也使用信号量则是多余的。请求和释放信号量的过程是要花相当的时间的。有时这种额外的负荷是不必要的。用户可能只需要关中断、开中断来处理简单共享变量,以提高效率。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
经典的书哦多年以前,我设计了一个基于Intel 80C188的产品,需要一个实时内核。在前一家雇主那里工作时,我一直在使用一个知名的内核(以下我称为内核 A),但该内核对我当时设计的产品来说是太贵了。我找到了一个廉价的内核(当时大约1000美元以下我称为内核 B),并且开始了我的设计工作。为了让我那几个很简单的任务运行起来,竟花了我两个月时间。我一天到晚给该厂商打电话求援。该厂商声称内核B是用C语言写的,可我还得用汇编语言给程序中每个对象除实话,虽然该厂商很耐心,而我实在是烦透了!产品的开发也耽误了。我真是不想再花时间去调试那个廉价的内核了。后来得知我是该厂商的第一个客户,这个内核实际上没有完全测试和调试过。 还是回到正路上来,我决定使用内核A。五个用户的价格是5000美元,此外,我的每个产品还要付200美元的内核使用费。在当时,那可是一笔很大的开支。就算是花钱买个心里踏实吧。花了两天时间,内核转起来了。项目进展到3个月上,我的一个工程师发现内核好像有毛病(bug)。当内核中的这个毛病确认无疑以后,我把我的代码寄给了该厂商。此时,厂商提供的90天的担保已经过期了。为了得到答复,我还得支付每年500美元的维护费。我和销售商争辩了好几个月,他们应该尽快纠正这一处毛病才是。我实际是在为他们做好事。可是,他们不予理睬。最后,我只好认了,又签了程序维护合同。而该厂商6个月以后才改正了那个毛病。是的,6个月以后!我简直气坏了,最要紧的是,我的产品开发耽误了。花了将近一年的时间,内核A才在我的产品中稳定运行。然而,我得承认,从此以后,内核A再没有什么问题了。 渐渐的,我自然会想到,写个实时内核有那么难吗?不就是不断地保存、恢复CPU的那些寄存器嘛。于是我决定试试写一个自己的实时内核,主要用业余时间、晚上和周末。也花了大约一年的时间才使内核转起来,它在某些方面还比内核A好。我并不想开公司去卖这个内核,因为当时市场上已经有大约50个实时内核的产品。 我想到给杂志写篇文章,打算投《C语言用户杂志》(《C User’s Journal 》)因为内和是用C写的,我听说该杂志每页给100美元的稿费,而其他杂志一般是每页75美元。我的文章大约有70页。这笔稿费对我写内核所花时间是不错的补偿。很不幸,文章拒载了。有两个原因,一个是文章太长,杂志不愿意连载。另一个原因是,他们也不愿意“又登一篇关于内核的文章”。 我决定转向《嵌入式系统编程》(《Embedded System Programming》)杂志,因为我的内核是为嵌入式应用设计的。我和该杂志的编辑Mr.Tyler Sperry联系,告诉他我的实时内核想在他的杂志上发表,得到的答复和《C语言用户杂志》是一样的,我们不要“又是一篇关于内核的文章”。我告诉他们,我的实时内核和他们的不一样,是占先式的,可以和许多商业上出售的内核产品竞争,源代码可以放在《嵌入式系统编程》杂志网站的留言板(BBS)上。我每周要给Mr.Tyler打两三个电话,几乎是求他发表我的文章。他终于同意了,大概是我的电话打得他烦了。我的文章从70页压缩到30页,连载在1992年5月期和6月期杂志上。该文章几乎是1992年最热门的文章。头一个月,就有500多人从《嵌入式系统编程》杂志的网站留言板上下载我的源程序。Tyler先生真怕实时内核的商家们会要了他的命,因为在他的杂志上刊登了实时内核的源码,这使商家们感到不安。我猜测,商家们一定已经认识到μC/OS(当时称作μCOS)的质量和功能。该文章实际上是第一次把实时内核的内在工作原理曝光,一些过去的秘密公开了。几乎是文章在《嵌入式系统编程》杂志上刊登出来的同时,R&D出版社的Bernard (昵称Berny)Williams杂志来电话了。《C语言用户杂志》就是这家出版社出的,此时距我最初与该杂志联系已有6个月了。 我留言给我的妻子,说他对我的文章感兴趣。我回电话给他,“你不觉得你有点太晚了吗?我的文章已经在《嵌入式系统编程》杂志上发表了”。Berny只是说,“不,不,你没明白我的意思,因为文章那么长,我打算出一本书”。起初,Berny只是想简单地把我手上已有的那些出成一本大约80页的书。我告诉他,如果写成一本书的话,我打算写得更好一些。以后,我又花了大约6个月的时间增加书的内容,就成了本书第一版的那个样子。书大约有250页。我把实时内核的名字由μCOS改成μC/OS,因为《嵌入式系统编程》杂志的读者一直称为“mucus”,那个自发音像英语的“痰”,让人听起来不舒服。回想起来,这可能是第一次给实时内核起名字。总之,实时内核μC/OS就这样诞生了。开始时,书销售的很慢,Berny和我计划在书的适用期内能售出4000到5000册,可是照开始时的销售速率,能卖出去2000册就不错了。Berny坚持说,让人知道这本书需要时间。于是他连续在《C语言用户杂志》杂志上刊登广告,一直持续了一年。约在书正式出版一个月之前,我第一次参加了在加利弗尼亚州圣克拉拉(Santa Clara)举行的嵌入式系统会议,那是1992年的9月,我第一次见到Tyler Sperry先生,我给他看了即将出版的书的草稿。他很快地翻了翻,问我愿不愿意在下一届嵌入式系统会议上做个讲演。下届会议在亚特兰大召开。那再好不过了,我说我愿意。但我讲些什么呢?他建议我讲怎样使用“小实时内核”。路上,我想,我这是怎么了?我从来没有在那么多人面前讲过话,到时候我自己就蒙了怎么办?如果我讲的都是些很平常的知识……人们可都是花了不少钱来听会的。以后的6个月中,我准备了讲稿。后来的会上,听我课的有70多人。起初的20多分钟里,我出的汗至少有1磅多。课后,约有15人上前来表示非常喜欢我的课,也喜欢我那本书。我得到了1993年在圣克拉拉举行的会议的邀请,可我没能参加,我参加了1994年波士顿举行的会议。从那以后,每次嵌入式系统会议上都有我的例行演讲。过去几年中,我进了会议的顾问委员会(Advisory Committee),最近的几次会上,每次的会议我都要做至少三次讲演,每次的听众都在200到300人之间。会议对我的讲演的评价总是在前10%。 至今,μC/OS的书已售出了15,000多册。我收到并答复的来自世界各地的电子邮件超过1000份。1995年,《μC/OS The Real Time Kernel 》被翻译成日语在《接口》(《Interface》)杂志上刊登。μC/OS已经被移植到以下一些CPU上。 Analog 设备公司 AD21xx ARM公司 ARM6,ARM7 日立公司 64180,H8/3xx, SH 系列 Intel公司 80x86 (Real and PM), Pentium , Pentium Ⅱ, 8051, 8052, MCS-251, 80196, 8096 三菱公司 M16和M32 摩托罗拉公司 PowerPC, 68K, CPU32, CPU32+, 68HC11, 68HC16 飞利浦公司 XA 西门子公司 80C166和TriCore TI公司 TMS320 Zilog公司 Z-80 and Z-180 1994年,我决定写第二本书,《Embedded System Building Blocks, Complete and Ready-to-use Modules in C》。由于某些原因,此书不如μC/OS那么流行,虽然书中很多信息在其他地方是找不到的。我始终认为,对于刚刚步入嵌入式世界的人们来说,这是一本理想的书。 1998年,我开通了μC/OS的正式网站:www.μCOS-Ⅱ.com,打算在该网站上放进移植、应用短文、相关网站、常见问题解答(FAQ)、μC/OS和μCOS-Ⅱ的版本更新等。只是这都要花时间去做。 回到1992年,我绝没有想到写篇文章会改变我的生活方式,实际上确实是这样,我遇到了很多非常有趣的人,交了很多好朋友。我还是回答收到的每一个电子邮件。我确信,如果你写给我什么的话,回应你是我的责任。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值