对UCOS可用性的疑问？？？

ddllxxrr

对UCOS可用性的疑问？？？ [复制链接]

 最近看到网上又出一UCOSII的书，我想问的是，大家工作中都用么？？？我的结论是工作中根本用不到。。。

为什么呢？试想一下，一个前后台就能执行的东东，为什么总是把操作系统拉进去。都说好一起执行可是有几个能用到实际工作当中的呢？？？？

下面我举个例子：


一个嵌入式系统有键盘输入，有读IC卡输入，有图形界面，有串口通讯，有无线传输，有IIC存贮，有SPI通讯。有时钟模块

其中都是互相惨杂，比如我在显示时可以显示时钟可以有光标移动，可以有按键输入，请问这些UCOS能搞定么，有成百个函数时，又怎么办呢？？？？

我本身编了上百个模块。还得再想一遍哪个函数创建了哪个关了。还得把上百个都建一遍么？？？？

我觉得UCOSII只是个实验室的东东，或在开发板移一下，当遇到工作中成百上千的函数。你还会用么？？？？？

你还能用得起来么，若再加上USB CAN SD FATS 本身已经占空间，还会再加上UCOS么？？？？？

ltbytyn

1、执行效率要比裸奔高很多。
2、任务可以分优先级。
3、flash和RAM小的MCU就不要用UCOS了。用的话就会头重脚轻的感觉。

ddllxxrr

大神还有一个问题木有答，成百上千个函数都一一设优先级么？还是用哪个建立哪个？

funnylogic

对于楼主的应用，我觉得用操作系统比裸奔好得多。CPU的性能是有限的，即使PC应用也是如此，更别说单片机了。在一个有键盘输入、图形界面、串口通讯、无线传输等任务的应用中，串口通讯、无线传输以及键盘输入对实时性的要求是比较高的。因为如果通讯任务得不到及时处理就有可能造成丢失数据，而键盘输入如果有延迟则会造成系统响应慢，从而降低了用户的体验。所以一般对通讯任务和键盘输入设置较高的优先级，而对于图形界面这类对实时性要求不高的或者比较占系统资源的任务则设置较低的优先级。如果使用操作系统就可以对这些任务的优先级进行分级，高优先级的任务可以得到更多的CPU资源，从而可以提高系统性能，改善用户的操作体验。

funnylogic

并不是说成百上千个函数一一设置优先级，而是根据执行的任务进行优先级分级。例如你在吃饭的时候你们老板打电话过来说你做的东西太高级，他不会玩。马上习近平要过来看了，叫你立即赶过去。但饭也不能不吃，所以就把饭菜都端过去。此时你就执行了2个任务，一个是把你的宝贝开起来，这个优先级就比较高，必须保证得到尽可能多的资源。吃饭任务就相对可以低些，在空下来的时候就拔两口，如果忙不过来就暂时不吃。在这里调试和吃饭是2个任务，但每个任务都是需要N个函数才能实现的。以吃饭为例，至少需要包括：拿筷子、张口、扒饭、夹菜等函数。

[ 本帖最后由 funnylogic 于 2013-10-27 23:13 编辑 ]

ddllxxrr

谢谢回答，老板叫又领导叫，那就不愁没盘子吃了。

nqyijian

会不会用UCOS，就体现在你会不会划分任务。每个函数一个任务，你的RAM容量得惊人。

xuanxuan170

非常好的解答，正在学习中

pigeon84

解释的不错啊！

llpanda

那是因为楼主不理解UCOS的本质
1.函数是函数，函数不是任务，任务是一些处理的集合，任务可以调用函数
2.你的裸奔程序是中断服务程序和主程序循环的混合体，如果要避免大段的ISR代码，可以在ISR中设置变量，在主程序中查询变量，但是这种方式实时性不好效率低，占用大量CPU资源。如果使用UCOS，可以将代码从中断中剥离开来，从系统态直接返回到用户态的处理程序中处理，解决了这个关键问题。
3.UCOS经过剪裁，代码极小，不占多少FLASH空间。如果任务划分合理，不是很多，不占用太多的SRAM空间。
4.STM32等单片机的SYSTICK、PENDSV、MSP和PSP都是为RTOS的使用做好了工作

[ 本帖最后由 llpanda 于 2013-11-14 16:14 编辑 ]

error_dan

第一，LZ对于写程序这件事来说，就只有code，debug和test（有test吗？），完全没有design。因为稍微花点功夫对工程进行一个简单的需求分析和模块划分的话，就不会分不清function和mission，更不用说function和thread（两个function是不一样的，一个是功能一个是函数）。我估计现在LZ写程序的话，还是huge function为主，有木有写过一个函数上千行的？至于看起来很麻烦的“相互参杂”，哦，天啊这不是OS最擅长的进程间通信么，就是前后台系统对于不同任务间的资源共享也是需要设计的好不好？实际上，OS确实不是必须的，OS能做的用轮询和前后台乃至分时系统都一样可以做，但是这里面需要用到的轮子一个都少不了，与其自己重新造一遍轮子还不如用别人写好的，经过验证的。（实际上我非常推荐新手们自己尝试造轮子，调度器和mailbox都是非常简单的，加上一个通用的queue struct就可以做很多事情了，内存管理什么的需要功底比较深厚，HAL也是必须的，这些都可以慢慢实现的，等于自己写一个OS）
第二，用裸机和OS写程序之间的不同，在我看来就想做菜一样，你可以把所有的东西都丢到水里去一锅煮了，这样可以做菜。但是OS可以给你一个框架帮助你在某一时间点在某个容器里用多大的火候加多少调料，这些功能裸机也能实现，但是就像我说的，轮子一个都少不了。与其在一锅煮的情况下纠结这个煮烂了那个没煮熟，不如学习一下OS按照菜谱来。实际上LZ自己举出的这个例子就是OS的最佳应用场景，多任务，频繁交互，还需要一定的实时性，不上OS可以，但是这需要更深厚的功力。但是LZ既然还在纠结函数过多什么的。。。把我写的第一条看懂并且实践一下再说吧。
第三，UCOS的应用非常多，但是在我大寨国，UCOS这种收费的商业软件，虽然你可以拿来闷声发大财，但是用了还要到处说，想收律师函吗？

arthurli

哎，裸奔吧

wwwming0329

我们公司就用了操作系统，不过是FREERTOS，比ucos还要小巧点。

刘晓朋

大家的解释对我这个初学者来说很是受用，在此写过！