裸奔和os其实没啥可争的

3万 · 2007-12-7 08:53

裸奔适合小系统，比如，xinlinx的有一款小软核，才2k程序空间，
怎么跑os?厂家连C都不提供，只能用汇编。这种结构的cpu有点是
占用硬件资源少。资源就是钱啊。

比如最新的酷睿或者K10之类的，你裸奔个网络游戏试试！

所以呀，微小系统，对资源及其严格要求的裸奔；大系统，资源随便用的肯定用OS。

项目要求是第一位的，确定了要求，才能确定软件，确定了软件才能确定系统结构，最后才能确定硬件！

不要为了裸奔而裸奔，也不能为了os而OS。凡是不能走极端。
中庸之道.

1万 · 2007-12-7 08:59

那位被拍得满头烂额的仁兄，应该想表达的是在一个MCU能支持OS 和裸奔的情况下，用OS比裸奔好吧～～～～

2万 · 2007-12-7 09:07

只看该作者 · 2007-12-7 09:27

两个比喻：
1、在技术装备越来越发达的今天，士兵在徒手和简单装备下的战术训练还有没有意义。
2、正规军？特种兵？还是游侠？

1万 · 2007-12-7 10:30

3万 · 2007-12-7 12:46

有些情况下是在两头的临界状态中间的
比如说资源比较多,可以跑OS,但是又不是太多;软件裸奔又不太容易,跑OS的话,资源又不是太宽裕,现成的OS还要多加斟酌的定制,那到底怎么办好了?
哈哈
是不是有点扯淡了?
这种情况我没玩过,哈哈

3万 · 2007-12-7 13:15

取决于你的水平，项目的需要。赚钱是第一位的。

只看该作者 · 2007-12-7 13:20

同时适合OS和裸奔的情况是相当多的.

3万 · 2007-12-7 13:33

只看该作者 · 2007-12-7 14:17

如果你的嵌入式裸奔能写到线程调度，那我出的题目就很容易解决了。毕竟代码都是人写的，你要写个嵌入式多任务调度的程序代码，那我没话说，但问题是有多少人又精力能力去做. 项目的时间进度你总还是要考虑的是吧.. 但如果你只是简单的单线程状态机化，我告诉你，那个问题很难处理好！而且系统以后增加什么任务，将导致系统复杂度大大增加，而且可能还需要重新分析划分系统状态。

其实我一开始就直接说明了两者根本区别：
单线程状态机无论怎么做，都需要在退出某种状态后，方有机会去处理事件。而多线程，在事件发生后，系统就立刻进行线程调度以决定是否对该该事件进行处理。两者差别在于实时性。你那样的才真正是弱实时，因为你不允许在执行完当前状态前去处理事件，而这个时间的花费是不确定的。这就是两者根本区别.

只看该作者 · 2007-12-7 14:18

只看该作者 · 2007-12-7 14:27

“单线程状态机无论怎么做，都需要在退出某种状态后，方有机会去处理事件”在采取实时层次转换后，这么做是非常正确的。
“多线程，在事件发生后，系统就立刻进行线程调度以决定是否对该该事件进行处理”在同步任务时是非常容易出BUG的。

俺不知道LS是否能真正理解这些。

只看该作者 · 2007-12-7 14:27

呵呵，要具体问题具体分析
如果把任务切的够细，那么响应时间可能小于上下文保存,调度，恢复的时间。当然这只有在很简单系统中。

只看该作者 · 2007-12-7 14:33

LINUX写的程序才是系统复杂度大大增加。
嵌入式裸奔以极其可靠、极其兼容、高度扩展（产品范围）胜出。
俺做的嵌入式裸奔支持几十种语言界面，可以随意调整窗口特性。

这些只是项目规划和设计策略，和OS特性没关系。

只看该作者 · 2007-12-7 14:35

抢占调度可以满足优先级最高任务的响应时间，较低优先级的就听天由命了。
更何况还有那么多不支持抢占的OS，又如何保证响应时间？

只看该作者 · 2007-12-7 14:36

特别在有GUI的系统中，LS强调OS对实时的支持，俺个人认为是用一片树叶代替整个天空了。

只看该作者 · 2007-12-7 14:40

同步在操作系统里自然还有同步的方法，信号消息互坼等都是用来任务同步的，所以所长过滤了~~~

13楼的，我想请问，你的这种方法好吗？整个系统的任务为了其中某个任务最小响应时间而全部切割细分成N个状态，那万一系统以后增加了一个任务，而刚好该任务最小响应时间比原系统任务最小响应时间都小，而且这个任务很重要，那你是否准备把整个系统推翻重新将任务分片切割以满足最小时延要求？还有，上下文调度恢复的时间并不是每时刻都作的，只有在任务发生切换时才做的，这样的设计效率比你将系统所有任务切片分割，用状态机控制效率反而高啊...

只看该作者 · 2007-12-7 14:44

“整个系统的任务为了其中某个任务最小响应时间而全部切割细分成N个状态，那万一系统以后增加了一个任务，而刚好该任务最小响应时间比原系统任务最小响应时间都小，而且这个任务很重要，那你是否准备把整个系统推翻重新将任务分片切割以满足最小时延要求？还有，上下文调度恢复的时间并不是每时刻都作的，只有在任务发生切换时才做的”

状态，你可以再加一百种没问题，但这是一个模块中的事情。你这是说的N个模块N种状态。
也不存在“该任务最小响应时间比原系统任务最小响应时间都小”，如果说有，早已经属于弱实时处理的层次，这不是OS的思维。

只看该作者 · 2007-12-7 14:47

15楼
任何操作系统都有任务调度功能的，只不过是否是实时抢占的而已。对于linux，任何任务在时间片到来时，都可以被系统检测是否相应，而没有操作系统的，只能通过状态机的任务切割来实现，而在这些任务里处理，你根本很难控制每个任务延迟时间... 也就是说，当系统处理某个任务的时候，来个一个更高级的响应要求，对于状态机来说，他不能及时对该事件作完整的处理，它需要把当前的事情（任务）做完了，他才能退出来处理那个事件~ 但操作系统可不存在这样的问题~~

只看该作者 · 2007-12-7 14:47

“同步在操作系统里自然还有同步的方法，信号消息互坼等都是用来任务同步的”是个双刃剑，非常容易伤着自己，即使是很高的高手。
和动态内存一样的双刃剑.

裸奔和os其实没啥可争的

相关帖子

这其实也是话外题了

呵呵，可是它的例题刚好是裸奔比OS更好:-)

两个比喻：

哈哈，实际情况实际应付~~~所以啥都得准备，到时才能应付

我觉得老王这话说的就有些极端的意味

你这种情况，看我说的最后几句

个人认为中高端的8位机都比较适合跑OS,

自己试一下就知道了，合适自己水平的才是最好的。

设计需要严谨的治学风格，而有无OS确实不同，就任务来说区

我不知道这里到底有多少人真正理解上面那段话的

ls如何评价WINDOW3.1？

to圆圈

LINUX写的程序和俺的嵌入式裸奔比较

抢占是目的还是手段？

产品中最大量的是非实时处理

农民

你还是在用OS方式在想问题

|||

搞过大系统的都知道

荣誉元老奖章

坚毅之洋流

十世金身

技术高手奖章

核心会员奖章

经常做客

终身成就奖章

技术领袖奖章

以坛为家

精英会员奖章

奔腾之江水

永恒之光奖章

技术导师奖章

七世轮回

常驻人口

突出贡献奖章

甘甜之泉水

涓涓之细流

技术新星奖章