大家来献策, 为STM32打造一个高效精炼的RTOS

1万 · 2014-2-20 10:45

各位尊敬的网友同志们, 大家好. 先做个报告.
  自从大约十年前啃了那本邵贝贝《嵌入式实时操作系统μC/OS-2(第2版)》, 一直非常热衷于钻研在单片机里的编程技术.
  事实上, 单片机(嵌入式系统)里通常所有的应用都不是单任务的. 往往检测到一个按键后, 后面的 20mS 的消抖延时, 就能错过很多该做的事情. 当然有很多办法利用好那 20mS 延时时间, 但 RTOS 无疑是这些编程技术中很优秀的办法之一.
  ucOS 在嵌入式 RTOS 无疑是个佼佼者之一. 功能和稳定性方面值得推崇. 但是我感觉内部比较庞大的数据链表等结构处理导致系统的内存开销也不小, 同时对任务切换导致的时间开销也不小, 导致 ucOS 的时钟节拍不能设定得太小.
  不说那么多了, 希望大量来献策, 希望打造一个时间节拍在毫秒以下, 开销尽可能小的 RTOS.
  首先请大家给她提点要求. 该提供什么样的功能.

参与之前, 希望参与的朋友有机会先了解以下 RTOS, 有空也可以先看以下《Cortex-M3 权威指南》.

1万 · 2014-2-20 10:48

嗯，楼主想法不错，有空大家一起研究。ST的产品以性价比赢得了不错的市场口碑。值得一学

只看该作者 · 2014-2-20 11:09

用状态机+中断的架构完全可以很好地解决问题，不必强求使用RTOS。

使用RTOS可以提高开发的效率，但肯定降低资源的使用效率。

只看该作者 · 2014-2-20 11:23

本帖最后由 jlwg 于 2014-2-20 11:42 编辑

对于72M乃至36Mhz的stm32,运行ucos,时钟节拍设置为1ms,毫无压力,不知道楼主说的"时钟节拍不能设定太小"是什么意思?1ms的时钟节拍不够小吗?如果1ms的节拍都无法满足您的要求,您就应该考虑修改您的设计思路了,而不是考虑改操作系统.

1万 · 2014-2-20 11:32

3万 · 2014-2-20 11:56

支持。楼主准备在哪款芯片里验证RTOS？

ps;楼主好牛叉，一个贴能散200分

只看该作者 · 2014-2-20 12:03

如何散200分?我曾经一个帖子里散20分都三不出去,系统只支持每个人给3分,如果回帖的人少于7个,就散不了20分.这个是怎么回事?

3万 · 2014-2-20 12:08

实时性怎么样呢？和裸机比

只看该作者 · 2014-2-20 12:21

mmuuss586 发表于 2014-2-20 12:08
实时性怎么样呢？和裸机比

除非您的裸机功能完全基于中断的前后台方式,否则,裸机系统,别谈事实性.非前后台的裸机,哪有事实性可言.

只看该作者 · 2014-2-20 13:22

众口难调，楼主还不如教大家如何写

只看该作者 · 2014-2-20 13:25

200分好多呀，我现在有多少分了？帮顶，系统正在学，有想法再提。

1万 · 2014-2-20 14:39

C:\Keil\ARM\Pack\ARM\CMSIS\3.20.4\CMSIS_RTX\SRC

只看该作者 · 2014-2-20 14:55

MDK自带一个 RTOS ，但是我没用过。
前后台异能答题搞定这个问题。RTOS 的实时性也不是绝对的RT，也是在某个可准确计算出的延迟内得出结果然后这个时间符合你的需求，就OK了。
UCOS 其实就挺好的，很好的兼容了各种不同的需求，如果楼主有不同的需求可以对他的源码进行修改。自己搞一个未尝不可，但是站在巨人的肩膀上，你看的更高，而且更快。

只看该作者 · 2014-2-20 14:55

至于OS这方面，你要自己打造的话，我先给你泼一盆冷水，如果说你的OS能超越RT-Thread的话，那你可以做，如果你认为RTT不是你的目标，那好你能否有把握超越FreeRTOS，这也不行，如果你还要超越更高的目标那你试试ChibiOS这个可是切换速度最快的。像其他的比如RTX、eCos、ucOS、openRTOS、safeRTOS、Raw-OS这几个你是否可以超越呢，做不到的话，就不要做了。。。

OS在实际的产品项目中还是要使用可靠的，你要自己学习使用时可以的，但是不要拿出来害人就成。。

只看该作者 · 2014-2-20 15:23

shaobing1231 发表于 2014-2-20 14:55
MDK自带一个 RTOS ，但是我没用过。
前后台异能答题搞定这个问题。RTOS 的实时性也不是绝对的RT，也是在某 ...

内置的叫rtx，在一个项目上用过。OK。

只看该作者 · 2014-2-20 15:35

楼主想法不错，顶一个。

只看该作者 · 2014-2-20 15:43

支持一记。

只看该作者 · 2014-2-20 16:48

在 72MHz 的 cortex-m3 上，普通的 RTOS 的任务抢占时间都可以做到 5-10us，系统节拍设置为 1ms 周期基本无压力，我就长期使用 1ms，更短的周期（比如 500us）对大多数应用环境也应该压力不大。

只看该作者 · 2014-2-20 17:07

john_lee 发表于 2014-2-20 16:48
在 72MHz 的 cortex-m3 上，普通的 RTOS 的任务抢占时间都可以做到 5-10us，系统节拍设置为 1ms 周期基本无 ...

实际上,操作系统的节拍没有任何理由设置为小于1ms,对于小于1ms的实时性要求,完全可以用中断来实现,而大于1ms的实时性要求,可以用任务来实现.这也是所有rtos的对实时性的处理方式.即分两个层次,一个是中断,一个是任务.这两个层次,满足了不同的实时性要求.
当节拍小于1ms时,任务切换的开销增加,效率降低..这中情况下,还不如直接用中断来保证实时性.

--------------------------------------------
**用keil,16年不动摇,因为2020年,**就到期了

只看该作者 · 2014-2-20 17:30

积极学习！

大家来献策, 为STM32打造一个高效精炼的RTOS

荣誉元老奖章

坚毅之洋流

十世金身

技术领袖奖章

核心会员奖章

技术导师奖章

技术高手奖章

甘甜之泉水

以坛为家

希望之星奖章

涓涓之细流

七世轮回

技术奇才奖章

永恒之光奖章

无冕之王奖章

沉静之湖泊

伴坛终老

技术新星奖章

经常做客

突出贡献奖章

缘定三生

湍急之河流

精华达人奖章

社区建设奖章