uc/os 怎么占用的RAM那么大？

hoguowi

我把下面这些文件全部编译了

#include <os_core.c>

#include <os_flag.c>

#include <os_mbox.c>

#include <os_mem.c>

#include <os_mutex.c>

#include <os_q.c>

#include <os_sem.c>

#include <os_task.c>

#include <os_time.c>

最后占用资源为如下：



Program:    6732 bytes

(.text + .data + .bootloader)



Data:       3133 bytes

(.data + .bss + .noinit)

我是用M64芯片！才剩不到1K左右的RAM给我用于其他程序用！
-----此内容被hoguowi于2007-05-21,17:23:24编辑过

chengyingavr

uCOS需要根据实际的需要裁减,内存占用有一个程序可以计算的,主要是任务表占用的多

hoguowi

我开了8个任务。每个任务给128个字节的任务栈，8*128就很大了！

bairg521

当然了，每个任务都需要自己的堆栈，再怎么说它也是一个操作系统，不适合在低端MCU上使用，这样的话资源都被内核本身占用了

chengyingavr

你减少一些任务就可以大幅度的减少内存的占用

以前把uC/OS裁减到可以放在Mega48上

ATmega8515

用AVRX或者Small rtos节省RAM些

ywhbn

人家怎么说也是个操作系统，虽然小了点，呵呵

ATmega16

uc/os有一点不好，就是中断处理不好：

1.中断占用任务的堆栈空间。如果每个任务堆栈用量为A（不含中断），中断需要堆栈B，

则至少要给每个任务分配A+B大小堆栈空间，中断越多。浪费堆栈越严重。

2.OS_ENTER_CRITICAL()会影响中断的实时行。



相比之下，Small rtos将所有空闲堆栈分配给当前任务，有非系统管理中断（不受OS_ENTER_CRITICAL()影响）。

只不过任务切换时间很长。

hoguowi

看来想在uC/OS上再加uC/GUI都很困难呀，苦闷压抑呀！资源严重不够用！

ATmega16

每个任务给128个字节的任务栈，是不是太多了点。

不用中断，每个任务64byte够用。

TTLife

To ATmega16:

    ucos在每个任务的第一次中断时,并不需要堆栈B,需要堆栈B甚至C或更多的是在中断嵌套的情况下使用的.<单片机与嵌入式操作系统>中有文章谈到改进的办法,这个办法主要说是在需要中断嵌套操作中,再增加一个大小不至于造成堆栈溢出的数组,n个中断嵌套就只需要增加n个此数组,此时每个任务的堆栈A就可以固定了.

    128个字节或64个字节是大是小还要视函数里调用函数的情况和每个函数里临时变量(或函数的形参)来定.每个任务有固定的压32个寄存器(按最大算)的堆栈长度,因为函数每调用一次函数,就AVR而言需要堆栈2个字节(固定).编译器会将每个函数的实参和临时变量用寄存器来传递和操作,函数调用函数时会将所用到的寄存器压入堆栈,如果被调用的函数再次调用其它函数......,此时长度将不固定,需要我们估算,首先尽可能的大,再使用ucos的堆栈检查功能的任务来确定.

To hoguowi:

    "我是用M64芯片！才剩不到1K左右的RAM给我用于其他程序用！".你能把你的定义任务的C文件和os_cfg文件上传吗?我的M32使用7+1个任务的情况:

Device: atmega32

Program:   20948 bytes (63.9% Full)

(.text + .data + .bootloader)

Data:       1910 bytes (93.3% Full)

(.data + .bss + .noinit)

ATmega16

To ATmega16:

    ucos在每个任务的第一次中断时,并不需要堆栈B,需要堆栈B甚至C或更多的是在中断嵌套的情况下使用的.



请教TTLife：

多谢指点。

ucos在每个任务的第一次中断时，中断用堆栈再哪里？

比如任务A运行时发生的中断，此时中断用的堆栈是A的吗？？






-----此内容被ATmega16于2007-05-22,20:21:00编辑过

ATmega16

TO TTLife：

每个任务有固定的压32个寄存器(按最大算)的堆栈长度



我对UC/OS不懂，SMALL RTOS会一点。

移植SMALL RTOS，如果用GCC，移植代码用汇编编写，任务切换时可以不必保存R18-R27,R30,R31 十二个寄存器。

因为C，汇编混合编程，R18-R27,R30,R31 可以任意使用，而不必恢复。



不知道UC/OS可不可以。


-----此内容被ATmega16于2007-05-22,20:26:40编辑过

TTLife

To ATmega16:

    每个任务第一次被中断之前的,寄存器里的数据全都是本次任务的,任务并不知道自己被打断,寄存器中的数据还安全放在里面,被中断之后,必需将属于被中断的任务的数据归还,此时这些数据在进入中断时保存在A.中断正式执行后,寄存器等资源被中断接管,本次中断如果没有意外,执行完后就退出,并不需要堆栈,但有一点需明白,中断期间如果调用了其它函数,中断将会"借用"被他打断的任务的堆栈保存PC值,而PUSH和POP是成对出现的,对任务没有影响(条件是不能溢出).而如果本次中断里又被打断了,寄存器里的数据也必需归还,此时,可以继续借用任务的堆栈(条件是这个任务的堆栈足够大,这正如你7楼的理解),更或再设置B、C、D......

    看了你12楼的帖子后,我很是惊讶,这在ucos中是不可能,寄存器中除了Y指针,必需全都(模拟或PUSH)入栈.打个比方,我正在黑板中计算一道算数,此时上课铃声响了,值日生要来擦板或老师将要板书,我肯定会把计算过程印在脑子里(如果我在打铃前计算得到了答案,就不需要黑板了,擦不擦对我来说已不重要),黑板是寄存器,脑子里堆栈,12个寄存器可以不管,不难想象,这些计算过程等到我下课的再来算的几率几乎没有.我相信编译器已经替你做了什么.你方不方便发一份Small RTOS给我?最好能直接编译的GCC工程.我想看看编译后的汇编代码,究竟是怎么回事!TTLife@gmail.com

ATmega16

TO TTLife

还是没明白。

如果任务A被中断B中断，中断B就好像是任务A的一部分。

中断B使用的堆栈（包括进入中断保护现场，以及中断局部变量）将占用A的堆栈空间。

如果中断执行完时进行任务切换，则当任务A再次运行的时候，实际上是返回到了中断B的结尾处，再由中断返回任务A原先被中断的地方。



small rtos任务切换时只保护20个寄存器很好理解。

因为GCC中 C，汇编混合编程，汇编可以任意使用R18-R27,R30,R31 而不必恢复。

也就是C调用汇编时，R18-R27,R30,R31不会保存任何有效的数据。



我是新手，学AVR不久。做了个急于SAll RTOS的频率计试验。

http://www.ouravr.com/bbs/bbs_content.jsp?bbs_sn=754877&bbs_page_no=1&bbs_id=1000





在OS_CPU.H里，可以切换 任务切换是保护全部32个寄存器还是其中20个。



#define OS_CONTEXT_SWITCH_METHOD        1       

/*

0:任务切换保护全部32个寄存器

1:任务切换保护其中20个寄存器

*/














-----此内容被ATmega16于2007-05-23,19:06:29编辑过

TTLife

14楼:

    我的语文学得不好,我打的比方应该是在阐述一种行为而不是喻物吧!

    "GCC-AVR在C编译器中是不会使用某些寄存器的",不会?还是根本不会?某些寄存器?能确定是哪些寄存器吗?这么多不确定因素怎能稳定地运行一个系统.我也留意过GCC编译后ucos的任务堆栈里有些寄存器运行很一段时间也没有使用,主要范围在R2-R10之间,然而并不是没有使用,而那12个寄存器是GCC编译器经常使用的,命中率非常高,不说别的,函数实参的传递全在这个范围.

    "但却根本不适合AVR这类内存受限严重的MCU使用",希望肯定地方没有出现,不应该肯定的却来了."根本不适合AVR"?!有人在AVR和51做了一个形象的比喻,如果51是轿车的话,那AVR就是跑车,51都能上ucos,AVR就肯定不在话下,只是型号有限,主要是RAM最好在2K以上(或可以外扩RAM的).我的M32跑了7+1个任务,长时间很稳定(大于连续三天),存在的一个问题是,通过串口发送一个30BYTE的字符串,不能地连续发送(手动连续点击),而间隔大约一秒则没问题,我还没有着手排除,我没有硬件调试设备,初步认为是堆栈设置稍小,发生溢出而不稳定.
-----此内容被TTLife于2007-05-23,19:29:32编辑过

ATmega16

"GCC-AVR在C编译器中是不会使用某些寄存器的",不会?还是根本不会?



AVR-GCC使用全部32个寄存器。函数（不是中断）在使用R2-R17,R27,R28会把他们入栈保护。

而R18-R27,R30,R31，函数（不是中断）在使用他们之前不会入栈保护。



SMALL RTOS我只保护寄存器中的20个并没有发现有什么不妥。

下面是一个基于SMALL RTOS的LED实验，16个任务全部打开，给所有任务600字节堆栈，还剩100多。如果32个寄存器全部保护，ATMEGA16 1KSRAM几乎要全部用光。

点击此处下载armok01155177.rar

TTLife

下载后我分析了一下：

void Task1(void)

{

uint8 i;//---i通过R17操作

        while(1)

        {

        for(i=0;i<2;i++)

                {

                OSWait(K_SIG,0);//---K_SIG通过R22,R23传递,0通过R24,R25传递

        }

        LED_PORT0^=_BV(1);                //40ms闪烁一次//---通过R24，R25操作

        OSSendSignal(2);//---2通过R24,R25传递

        }

}

"//---"是我写的注解。这个任务总共使用了5个寄存器，按照只压R0-R17和Y指针，那么R18-R27将没有保护，在执行“call OSWait()（编译你上传的代码，任务调用此函数的地址是0x000005D6）”前将有两个值需要传递，地址为0x05D4的LDI R22,0x00和0x05D5的LDI R24,0x01，GCC使用了R22对和R24对四个寄存器，假设在执行完0x05D5后发生中断，中断中如果没有压栈，这两对寄存器数据很有可能被破坏，你的代码里只有一个中断函数SIGNAL(SIG_OVERFLOW0)，地址为0x00000050，看看里面的汇编代码，GCC为你做了什么!可以让你感觉良好的是在这里呀！

    在ucos里也可以如此编写中断函数，但会重复压栈，因为ucos做好了压栈操作，就不在需要GCC来压栈了，因此，ucos里的中断用汇编编写：

.text

.section        .text

.global SIG_OUTPUT_COMPARE0

SIG_OUTPUT_COMPARE0:

OSTickISR:

    PUSH_ALL

    PUSH_SP

    .

    .

再在此处call 相关函数

    .

    .

    POP_SP

    POP_ALL

RET or RETI

    你如果使用32个寄存器全入栈的话，造成重复压栈，肯定要更多的堆栈了。

TTLife

To watercat2：

    我们有幸在此破读老外的东西，本是件好事，但无论在任何场合，我觉得我们应该遵守一个原则：对事不对人。要不然会伤了大家的合气！

    我承认我学历不高，所以造成我很多的不了解不明白，但有点我很清楚，寄存器就有如通用CPU的一级缓存，他为处理器的速度提高有很大的作用，如果不能尽用，那太可惜了，所以每个编译器都会充分利用，一个“volatile”就足以说明编译器对寄存器使用的用心。

    几乎40脚的51都有16位的PC指针，可以很方便的扩展部件。唯AVR在低端舍弃了这种做法，无法扩展。而普通51的Flash却没有AVR的容量，结果是，想要用ucos都得在各自的高端看。数据结构的作用是给系统用来管理工作的，结构大不大要看管理水平和工作效率是高还是低，他通过了FAA的认证，自然数据结构是合理的。既然是破读，当然就会有在理解ucos运行机制后进行自认为需要的更改或改进，用以灵活运行。《单片机与嵌入式操作系统》2004（1-6）合订本P440：《uC/OS-II任务栈处理的改进设计》，我认为很值得学习，论证了ISR也可以拥有自己的堆栈空间，即我在上面提到了堆栈B、C、D......就不必将任务堆栈再加上ISR可能用到的空间了。

     ucos也只有几个功能：任务管理、时间管理、信号量管理、互斥型信号量管理、事件标志组管理、消息邮箱管理、消息队列管理以及内存管理。至于8位机用不用得到，我只想引用《uC/OS-II》（第2版）作者的一句话：通过诸如上述的系统服务，实时内核使得CPU的利用更为有效。用实时内核做过系统设计以后，将绝不会再想返回到前/后台系统。

    欢迎watercat2再次辩证！

TTLife

哈哈,原来如此,看来watercat2对ucos认识比较深呀.先讲个故事,美国发明了圆珠笔,而日本则列出他们圆珠笔的十大缺陷,针对缺陷进行改进,结果生产出来的圆珠笔比原创者"性能"更好而迎得了市场.其实,学ucos可以实用,而他的开源为我(们)剖现了操作系统运行的原理,与其它商业操作系统而言,无疑可以使用更灵活地运用,而我(们)则可以根据操作系统运行原理,针对ucos的缺陷进行必要的改进以自用,更或根据自己的实际需要和理解程度进行创作是很有帮助的.我个人对不符合ucos硬件要求的芯片选择C和汇编,灵活运用嘛.

    市场决定一个产品是否成功,价格首当其冲.而我对ARM不熟悉,也没有准备去学.现在AVR32出来了,我的心里却产生莫明的欣慰,并且还将我的电脑里所有的ARM资料都删除了.如果阿莫邮购部有的话,我会考虑的,才不管他是BGA的.

zhzzh18

技术论坛以数据说话，有道理，也应该这样。

TTLife

　　哟,还真较上了.数据是在解决产品出现问题或了解产品的性能才摆出来的，行为则是用来仿效而设计产品的，所以摆行为就能更好的理解产品（或工作）的原理。如果没有飞禽，也许现在还没有飞机。建议多看看Discovery,会很有启发的。

　　对于AVR32，ucos只是内核，对其丰富资源的利用那是任务事，不是有ucgui/ucfs/ucip/ucusb等现成的软件吗，付得起费用的话也可以拿来使用啊。Linux是AVR官方主推的操作系统，免费的是不错，但让一个没有认识操作系统运行原理或相关知识的初学者去学Linux，可以学会，但会花很长时间的，我引用邵贝贝博导所发表的一篇文章的话：“我不主张将嵌入式Linux、uClinux等用于教学。它缺乏适当的定位，虽然有源码，但并没有一本适于做教材的书籍，对于非计算机专业的学生来说太难了，也没有必要花那么多的时间去抠懂。将uClinux移植到不同32位系统上是计算机专家的事，非计算机专业的人士，仅仅是使用而已。...uClinux等嵌入式Linux不是实时的。....要切记防止浮躁...后来，能成为IT高手的，不是我们培养的，而是通过他们自己艰辛努力实现的。”我国自主研发的五轴连动机床，精确度非常小，不到头发丝的十分之一（可以用到航空零件制模上），可见实时性非常高，还有人机界面（即操控板），主控芯片在性能上不知是否比AVR32强，但有点可以确定，即使需要GUI，也不会用Linux来控制的。在数据量大如多媒体、网络通信、机顶盒等应用中，AVR32与Linux结合可以发挥到及至，那AVR32与ucos结合就一无是处了吗？别忘了AVR32还是有160 GPIO pins，他对QCIF/QVGA/VGA/SVGA的支持为实时操作中需要GUI的场合也提供了不错的解决。

　　我现在还是个没有做过任何项目的个人学习者，我只想让软件与硬件都尽其用，在高端用操作系统与相应的硬件结合（注意：是相应的硬件，没有说限定），如果低到可以用汇编与51结合，我当然乐意；至于软件，用C和相应的汇编来完成某种行为或功能，然后形成软件，也应该没有限定特定的软件吧。
-----此内容被TTLife于2007-05-24,14:11:31编辑过

TTLife

　　俗话说：“授之以鱼不如授之以渔”。

　　18楼发言：“SMALL RTOS我只保护寄存器中的20个并没有发现有什么不妥。”我可以只给出数据（我20楼的帖子）告诉他这个思想是错误的（即授之以鱼），但为什么会错误呢？为了能让他理解，我摆事实（我13楼的帖子）告诉他这个原理（即授之以渔），我用这种方法来帮助解答居然遭到藐视，莫大耻辱啊。

　　ucos不能在8位机（AVR）中用，又不能充分利用32位机（AVR32）的资源，幸好AVR没有产16位机，要不然ucos因其自身的种种原因不知要往那塞了，我不禁想告诉Jean J.Labrosse,你的ucos高低使用都有问题，几乎是个垃圾了。FAA你们是个混蛋，居然认了这样一个垃圾。

　　如果邵贝贝能够看到此贴就好，我就不用在这里（貌似）为ucos说好了，还省去了电话费。

TTLife

　　是可忍，熟不可忍。我无权干涉有些人揣他人意，但那些以揣意生出来的非好意图对被揣者放话，想想这样的人的品德也好不到那去。与这样的人交流非但没有受教，反而还受气，不与这样人的交朋友也罢。

　　我们两个真可悲，非但没能破读ucos的架构还自已先非合作性争起来了。

　　只要AVR32是用晶体管制作，并且有其汇编语言，更或支持C的编译器的话，拿定他是迟早的事。

    To watercat2:我与你志不同道不合，很难有共同见解，再这样下去也无意义。还有我并没有说一定要ucos与AVR32结合，我只要AVR32在非Linux下能够完成相关操作，并始终稳定运行就行了。

hoguowi

两位大虾都厉害都是好样的，不过经常在这论坛泡的不要伤和气呀。有空欢迎你们来广西桂林来玩。我请你们看看桂林山水妹！

TTLife

To watercat2:

    别的我不说了,你说我以非专业人士的态度给专业人士"授渔",那好你也别光说不做,就"18楼"的问题,你来给出一个专业人士的态度来"授渔"方法,期待中......

    还有我是用猫拨号上网的,电话线路特差,经常掉线,一但下雨,电话里全是嗡嗡声,根本别想拨号,要我上传图,以后吧!

mark0908

两个人给干上了

都是热心人何必呢

rainyss

唉,都想证明自已是牛人,当然会吵起来啦.

从讨论上看得出来楼主的OS里是用切换栈指针的方式来切换堆栈,而现场保护用的是完全保护,这两种方式合起来用命中注定会费大量内存,而如果再开启中断,每个任务栈里都要再加最少2字节断点.

解决的方法是

1.使用公栈方式,即所有任务在运行态时用的堆栈地址都是相同的,任务被换出时,将堆复制到私栈中,任务换入时,从私栈中拷贝内容到公栈中,然后在函数嵌套较浅处切换任务,这样就无需担心私栈容量过小,内存占用也就小了.这是目前很多内存紧张的单片机上(比如51)用得较多的方式.

2.任务切换使用不完全现场保护.
现场保护分为寄存器保护和堆栈保护.不完全保护指的是只保护堆栈,不保护寄存器.
中断期间现场完全保护是不可省的,留到后面讨论.先说任务切换时的现场保护:
寄存器和覆盖变量在未使用完时就进行任务切换将会丢失上下文,反过来说,只要不使用寄存器和变量内存覆盖技术,切换任务时就不需要保护上下文.但取消变量的内存覆盖将会占用过多的内存,因些还需要用到下面一项"技术":

3."局部变量生命周期控制",这里所说的局部变量当然是指寄存器变量以及未使用内存覆盖的变量.只要在使用完变量后切换任务,就不存在保护的问题,这样,私栈长度可以大大缩短.

4.中断保护会占用大量内存,但如果你采用的是活动任务共用公栈方式,并且使用协作式多任务模式,则中断不需影响到私栈的长度,因为任务被换出时,中断必定已经结束.

结合以上4种方式,私栈长度可以缩到非常短.当任务切换速度要求较高时,可以取消公栈,这会导致私栈长度大幅增加,但任比不使用以上任务手段时要短.

本人愚见,与其说OS是一门技术,不如说是一门艺术,根据应用的特性灵活组合以上的方式,现场构建操作系统,是51及低端AVR的"唯一"有实用价值的方式.想在这样的单片机上采用泊来主义生搬硬套主流操作系统,不说其性能如何,光是内存占用就是无法解决的问题.

eduhf_123

楼上的4点说到点子上了。

hellish

mark

wantao0916

不明真相的群众围观中……
从你们的辩论中学到了一点概念性的东西，表示感谢。

eddia2012

"2.任务切换使用不完全现场保护.
现场保护分为寄存器保护和堆栈保护.不完全保护指的是只保护堆栈,不保护寄存器.
中断期间现场完全保护是不可省的,留到后面讨论.先说任务切换时的现场保护:
寄存器和覆盖变量在未使用完时就进行任务切换将会丢失上下文,反过来说,只要不使用寄存器和变量内存覆盖技术,切换任务时就不需要保护上下文.但取消变量的内存覆盖将会占用过多的内存,因些还需要用到下面一项"技术":

3."局部变量生命周期控制",这里所说的局部变量当然是指寄存器变量以及未使用内存覆盖的变量.只要在使用完变量后切换任务,就不存在保护的问题,这样,私栈长度可以大大缩短.

4.中断保护会占用大量内存,但如果你采用的是活动任务共用公栈方式,并且使用协作式多任务模式,则中断不需影响到私栈的长度,因为任务被换出时,中断必定已经结束.

结合以上4种方式,私栈长度可以缩到非常短.当任务切换速度要求较高时,可以取消公栈,这会导致私栈长度大幅增加,但任比不使用以上任务手段时要短."

36楼讲的很精!

Dirichlet

受教了。

jz701209李

路过.学习一下