裸奔適合小系統，比如，xinlinx的有一款小軟核，才2k程序空間，
怎么跑os?廠家連C都不提供，只能用匯編。這種結構的cpu有點是
占用
硬件資源少。資源就是錢啊。
比如最新的酷睿或者K10之類的，你裸奔個網絡游戲試試！
所以呀，微小系統，對資源及其嚴格要求的裸奔；大系統，資源隨便用的肯定用OS。
項目要求是第一位的，確定了要求，才能確定軟件，確定了軟件才能確定系統結構，最后才能確定硬件！
不要為了裸奔而裸奔，也不能為了os而OS。凡是不能走極端。
中庸之道.
網友評論：呵呵，這種方法不好，但有時是不得已的選擇。硬件允許當然用os。
另，由于所長這個結構沒啥搶占的，所以任務同步反倒是小問題。
to所長，你咋不強調實時性了？
網友評論：PC上寫磁盤、數據庫管理。協議處理，全是緩沖。
“以前的系統，任務最小響應要求是5微妙，執行時間2微妙”是MCU強實時處理，是用中斷，而且還是最高等級中斷。
弱實時一般5MS中斷，你只要申請注冊，就可以被調用，N個弱實時處理都可以被處理。
網友評論：我知道會用緩沖，但有些時候是不允許你將系統數據先緩沖再容后處理的~~
26樓，你這樣說就對了。我在這里討論，并不是爭論誰的輸贏，我只是想說明，有OS和沒有OS確實不一樣，而且我也分析了沒有OS的設計模式特點，也可以認為是弱點，這個設計者自己做產品前需要認真考慮權衡。沒錯，有oS會對資源有限定，所以彼此都有優缺點~并不是所有東西都是萬能的~os也是有他獨有特點的~
網友評論：工控行業軍工產品醫療器械等等~其實這樣的應用需求的還是很多的~
網友評論：操作系統有句話，永遠不要去假設處理器的速度
網友評論：“他的要求是響應時間1微妙，執行時間1微妙”
你覺得還是OS的范疇嗎？
還是弱實時系統嗎？
這時這一部分代碼還不應該特別處理，還不應該裸奔解決嗎？
所長前面說了：你還是用的OS的思維方式，沒有去分析系統的強弱實時層次...
其實硬件的中斷、優先級才是最高層次的強實時的OS，而區分系統層次和采用軟件OS的目的恰恰是為了把弱實時的需求降低，以便讓出更多的資源來保證強實時（中斷程序）的可靠運行、激活。
區分系統實時層次、采用裸奔的目的就是為了讓中斷占用的時間最短，從而讓任何最短的請求都不遺漏。
如果誰都有特權，那就等于誰都沒有特權，明白嗎？
一味推崇OS的，恰恰沒理解到這一點哦。
不用急著說服誰，自己先去想想吧。
網友評論：在有OS的系統里，也是有中斷的，而且有些東西也可以放中斷里處理，這方面兩者沒有區別的，彼此都能做都能達到要求~比較這個比較不出彼此差別的~
網友評論：比如：TCP/IP數據被強實時的中斷接收，存放在接收緩沖隊列中，因為是協議，所以在需要的數據外殼包含著大量的封裝代碼，如果不及時解析處理，在MCU中會造成緩沖區的溢出。這時候，弱實時層的中斷處理（一般5MS）開始起作用，將協議轉為數據量極其小的真實數據或事件，通過消息隊列或另外的緩沖區向非實時模塊傳遞。
網友評論：因為概念極其清晰，處理手段分明，大小MCU通吃。
網友評論：很多處理器上的很多實時操作系統能達到那個指標要求~
你也不要鉆那個點，那如果是響應時間1毫秒，執行時間100微妙呢，再多加幾個類似任務呢，若再加個響應時間500微妙，執行時間200微妙的呢？還有其他響應時間50~100毫秒，執行時間50~100毫秒的呢？
網友評論：高中低三個層次，對應著高等級中斷、低等級中斷、主循環。倒是OS，想提升哪個優先級別就提升哪個，一點也沒規則，全靠自己掌握。
網友評論：1、復雜系統中，OS也不能保證響應時間，大家都在盡力而為。例如搶占調度下，一個最高優先級任務的響應時間是：所有可能同時發生的中斷的處理時間＋任務上下文切換時間；但是因為驅動層的隔離，你可能根本不知道有多少個中斷源。
2。有些任務間確實具有明確的優先級高低。但很多時候這個優先級是想像出來的，并不具有天然的含義。結果往往是，大家還是順序執行，你做完了我做。
3。誰也沒有否認OS的價值。但如果離開OS就連較簡單的問題都解決不了，那才真是被誤導了。
網友評論：但嵌入式裸奔太難了點，初學者選擇OS也完全可以理解。
俺以前說過“MCU高手不用OS”，現在還是有效。
網友評論：主循環層次處理的時間模糊性，可丟失特性。
比如要求LED0.5S閃爍一次，沒比較做到很精確，需要發揮模糊特性：0.45-0.55S都可以，類似模糊控制原理（呵呵，假的）。
網友評論：前者針對不同情況采用不同的處理手段，能夠處理任何的硬骨頭，但要求技術高超，非常而且費神；
后者就簡單了，把肉直接扔進去就行了，一般情況下都可以把肉切的比庖丁的都好，但是碰到“要求是響應時間1微妙，執行時間1微妙”這樣的硬骨頭...那還是的優庖丁解決:-)
而且，切肉機對肉也是有要求的，你要是把頭豬直接扔進去...出來的肉只怕沒人敢吃了吧？
誰都知道Windows下要實現個1uS的精確延時多么的難，難道圓圈你沒聽說過嗎？
竟然還舉出這樣的例子，這不是給反方增加論據嗎？
呵呵^_^
網友評論：農民，我也不想說什么，只不過你的那種做法，我以前單片機上也做過的~其實要想做那種模式，上手并不難~了解狀態機，熟悉軟件系統分析，模塊拆分的，很快能上手做~不過我做單片的時候，也確實從來沒用過os，因為根本沒必要浪費那個資源~但其他地方就不一樣了~
網友評論：我吐下先~~拜托能不能不要把自己看太高~~
網友評論：用嵌入式裸奔是比較好的，不管8位還是ARM9
但如果需要多人協作，并支持外部未知設備的，還是OS好，這點OS表現非常優秀，規則大家都遵守。
個人看法。
網友評論：1、復雜系統中，OS也不能保證響應時間，大家都在盡力而為。例如搶占調度下，一個最高優先級任務的響應時間是：所有可能同時發生的中斷的處理時間＋任務上下文切換時間；但是因為驅動層的隔離，你可能根本不知道有多少個中斷源。
//////////////////////////
這條不敢茍同。
區別也就是在立即調度還是等當前任務放棄cpu后再調度，至于多個中斷源啥的，裸不裸奔沒啥區別。
網友評論：這和多人是否協作沒有關系~關鍵看產品，看產品的復雜度指標要求資源配置進度等等...
網友評論：說來說去其實論點很簡單：
所長說的是裸奔區別對待實時要求，概念清晰，處理手段分明，大小MCU通吃。
圓圈說的是OS萬能，實時性勝過裸奔，開發比裸奔簡單
我的觀點是說實時性OS永遠不可能勝過裸奔，說應用則要各取所需
牛頭不對馬嘴，更不想變成人生攻擊，懶得說了。
你們愛爭的就繼續爭吧...
網友評論：圓圈強調：在沒有OS時，“很難控制每個任務延遲時間”。
我的意思是，使用OS在稍復雜一點的情況，要分析每個任務的響應時間，都是一件很頭痛的事情。最高級任務還好分析，最低級任務不管它，中間那些呢？所以，大家都在盡力而為。
網友評論：圓圈強調：在沒有OS時，“很難控制每個任務延遲時間”。
我的意思是，使用OS在稍復雜一點的情況，要分析每個任務的響應時間，都是一件很頭痛的事情。最高級任務還好分析，最低級任務不管它，中間那些呢？所以，大家都在盡力而為。
//////////////////////////////////
討論嘛，大家平心靜氣
圓圈這句話也沒啥錯。當然你也沒啥錯。
所長大人那個裸奔結構，任務最大延遲==分割的最長一塊代碼執行時間，這還是在有優先級的情況下。如果不分優先級，那么最大任務延遲==其他所有任務最長代碼段總和
網友評論：做個WINDOW程序的都知道，一個
MOUSE點擊、一次KEY動作就是一個函數，說白了就是一個狀態發生變化，一個事件產生了。如果你想象的OS線程來寫程序，肯定是傻傻的等待。嵌入式裸奔分成穩定的狀態來表達事件的需要，才是符合程序設計的世界觀。
分割不是亂來的，是狀態改變的需求。如果只在狀態改變時執行有效代碼，那么狀態沒改變的那些任務可以出讓大量的時間給改變中的任務。
嵌入式裸奔從宏觀上看，是一個巨大的平均器，將處理事件平均化，誰冒泡就敲誰。
網友評論：對于資源稀缺的mcu,半裸（嵌入式裸奔）是一個比較好的方法或者說架構。
網友評論：只要不是很大的系統，只一兩個人做的
用嵌入式裸奔是比較好的，不管8位還是ARM9
但如果需要多人協作，并支持外部未知設備的，還是OS好，這點OS表現非常優秀，規則大家都遵守。
個人看法。
=======================
記得所長說過裸奔過200w行的程序，不知道這100w行是多少人合作的。
記不清楚了是不是200w行，記錯了還忘諒解。
網友評論：看大家爭得熱火朝天的...俺不參與...
至于如何裸,是半裸,全裸,黑裸還是色裸,大家自己都有自己的裸的體驗~~~
至于要統一裸的標準,估計很難~~~
網友評論：...
網友評論：另外回樓主
你把它當作爭論也好，討論也好。
在這里能夠學到新知識新方法才有意義。
在討論中學習。。。。
網友評論：感覺所長的嵌入式裸奔還嫌穿得多~~~要"裸"就裸個"透"~~~
網友評論：俺想實現MCU設計標準庫化，
工具化，解放廣大的貧下中農。目標遠大。
網友評論：而且回調"穿"和"脫"都更方便些~~~
網友評論：在一年內寫出200w行程序。
一年的工作時間算300天的話，一天要寫6000多行程序，什么天才也不行啊。
網友評論：..
網友評論：以前有很多類似設計，只是移植到2410上，另外還設計了一個PC資源管理程序，這個花了三個月。前后一年。
網友評論：呵呵.我是菜鳥!
但是二姨里面很多高手都是我的偶像.我現在也不知道什么時候開始用用OS
一直都在裸奔.
近來的論壇把我已經搞暈了.
網友評論：個人的感覺是初學者，先學“裸奔”，對MCU編程了解的比較深入了再上OS。
對于先學習下，想找份好工作的人，建議兩個方式都要會，并且都要精通才行，尤其是上了OS很容易迷惑人，一些底層的東西被封裝起來，如果拿來別人移植好的平臺就用，可能許多東西就不會考慮到，最經典的就是聽我同學說過他的一個同事做數據庫編程，居然認為執行數據庫操作是0時間。
網友評論：裸奔的背后，其實就是一個小巧的，未封裝的，專用的os，如果想把MCU設計標準庫化，工具化，最后提供給客戶的可能是個lib，但是如果加上一定的調度思想，其實也就是提供了一個os，各位高手沒有必要急著和os劃清界線。至于高手提到的誰冒泡就敲誰，本質上也是一個callback的思想，就是不要把自己寫的程序當作主線，而是把系統的需求當作主線。這樣無論怎么劃分程序結構模塊都不會覺得支領破碎了。總之，優美的程序背后，一定是有一個優秀的編程思想。理論化的編程思想就是os，而經驗化的編程思想就是優美的裸奔。而能夠提煉其中微妙的可以稱之為師，而可以完美實現之的可以稱之為匠了……
網友評論：關于US級相應時間，
用os提供的中斷或者裸奔的中斷都能解決。
復雜項目用os的最高等級中斷，但是，達到目標可能比較困難，需要對該
os徹底了解，自由修改的程度。這個項目的價格很高才值得做。
簡單項目用裸奔，則很容易解決--所有的硬件資源你都掌握中，沖突好解決。
甚至把不合適的硬件替換掉都可能。
us以下的相應時間不單純是軟件的問題了，應該硬件配合，甚至用fpga的
硬件邏輯實現。
ms級相應時間，linux2.6內核就能做到。win俺不懂，不知道。另外，恐怕ecos,ucos之類的小系統也沒問題。
用不用裸奔，具體看項目，就是看值不值。沒有做不到，只要給足夠的錢。
網友評論：這是個矛盾,微型機講求通用,單片機擇重專用,二者有逐漸靠攏的趨勢
要用辯證法去看待這個問題,再通用的系統做具體任務的時候的都是專用的
例如我此刻的
計算機此刻就是一部打字機,沒有最好的,只有最協調的!就像兩把扳手,做具體的事好用慎手肯定是死扳手用起安逸,但要翻修家用機電設備,可能一把活扳手方便性通用性就好了!
網友評論：裸奔有理，OS無罪！
喜歡裸奔的裸奔，裸出自己的特色，要象所長那樣期望大家裸奔的一個模式，一看就是一個單位的就不容易實現了，工作量大��！
在目前做8位機的系統里還沒有遇到非要上OS不可解決的事情，甚至連用OS一定方便過自己裸奔的情況也沒有。
解決問題，做出產品是最終考慮，手法各異，目的一致！
網友評論：#include<setjump.h>
jmp_bufjumper0,jumper1,jumper2,jumper3;
voidTask0()
{
staticintn=0;
if(setjmp(jumper0)>0)
{
while(1)
{
if(setjmp(jumper0)==0)longjump(jumper1,1);//任務切換
n++;//一段任務代碼
if(setjmp(jumper0)==0)longjump(jumper1,1);//任務切換
n++;//一段任務代碼
}
}
}
voidTask1()
{
staticintn=0;
if(setjmp(jumper1)>0)
{
while(1)
{
if(setjmp(jumper1)==0)longjump(jumper2,1);
n++;
if(setjmp(jumper1)==0)longjump(jumper2,1);
n++;
}
}
}
voidTask2()
{
staticintn=0;
if(setjmp(jumper2)>0)
{
while(1)
{
if(setjmp(jumper2)==0)longjump(jumper3,1);
n++;
if(setjmp(jumper2)==0)longjump(jumper3,1);
n++;
}
}
}
voidTask3()
{
staticintn=0;
if(setjmp(jumper3)>0)
{
while(1)
{
if(setjmp(jumper3)==0)longjump(jumper0,1);
n++;
if(setjmp(jumper3)==0)longjump(jumper0,1);
n++;
}
}
}
voidInitTask()
{
Task0();
Task1();
Task2();
Task3();
}
main()
{
InitTask();
longjmp(jumper0,1)
}
//以上代碼在keilc中調試通過
//非占先式任務切換
//任務內變量必須是靜態的，子程序不用
//任務內不要用
寄存器變量
網友評論：有個例程學習下更好
網友評論：原理都一樣
網友評論：#setjump.h具體是?
網友評論：關鍵是longjump的實現。
有變成OS的苗頭。
網友評論：用longjump的我也試驗過,但并不好用,比如兼容性不好,同樣的程序,換個CPU又不行了.因為各個CPU實現的不一樣.在一個子程序內跳轉還可以,如果跨越子程序,基本很危險.
所以77樓的后面也說有不少限制.
在網絡上找找,有不少用longjmp做任務切換的例子.
網友評論：自動放棄cpu,協作式os.
不過要小心局部變量。
把每個任務的sp分開
網友評論：longjmp是c的標準函數，它本身就是為線程跳轉用的。子程序內跳轉用goto就行了。
后面的限制是由于c51
內存分配機制決定的。在pc上就沒有以上限制。
網友評論：如果任務調用子程序，子程序能直接跳到別的任務嗎？還是子程序也要一個jmp_buf?
網友評論：如果要在多任務切換，不要在子程序里面用噢。
如果不是做多任務切換，整個程序用一個jmp_buf.可以隨意跳轉。我回答的對么？
其實看得出，你才是高手
其實我貼它的用意是，不用OS也可以完成多任務切換。我用的是匯編版本，匯編版本在子程序里也是可以的。其實俺壓根也沒把這看成OS,也就是一件緊身衣。
