rtx51源碼

Ⅰ rtx51有用c寫的源碼么，是不是都是匯編

匯編做的系統初始化和系統框架 應用函數和系統函數是C，你做的是tiny還是full?

Ⅱ 為什麼我們需要uCos

，於是開始了uCos之路，但後來由於硬體平台的問題，畢設沒有用uCos ，而用了另外一個不開源的。 畢業後，做的項目用到過RTX51， uCos， linux ，當做linux下的項目時，研究過一陣子linux的源碼，後來又一天，閑來無事再去看uCos的源碼時，突然發現uCos里的一些原理，對於理解和構建一個操作系統這這么的經典和透徹！於是我覺得是時候再好好理解和整理下uCos里的一些原理了。 我覺得第一個要解決的問題是，為什麼我需要uCos？就像最開始學C編程時，老師告訴我，指針很重要，我那時就有一個大的疑問，指針到底有什麼好？還一邊在心裡嘀咕著：我不用指針不一樣把程序編出來了？現在想想c語言沒了指針，將寸步難行！回到正題，我們到底為什麼需要uCos？一般的簡單的嵌入式設備的編程思路是下面這樣的：main{{處理事務1}；{處理事務2}；{處理事務3}； .......{處理事務N}；}isr_server{{處理中斷}；}這是最一般的思路，對於簡單的系統當然是夠用了，但這樣的系統實時性是很差的，比如「事務1」如果是一個用戶輸入的檢測，當用戶輸入時，如果程序正在處理事務1下面的那些事務，那麼這次用戶輸入將失效，用戶的體驗是「這個按鍵不靈敏，這個機器很慢」，而我們如果把事務放到中斷里去處理，雖然改善了實時性但會導致另外一個問題，有可能會引發中斷丟失，這個後果有時候比「慢一點」更加嚴重和惡劣！又比如事務2是一個只需要1s鍾處理一次的任務，那麼顯然事務2會白白浪費CPU的時間。 這時，我們可能需要改進我們的編程思路，一般我們會嘗試採用「時間片」的方式。這時候編程會變成下面的方式：main{{事務1的時間片到了則處理事務1}；{事務2的時間片到了則處理事務2}； .......{事務N的時間片到了則處理事務N}；}time_isr_server{{判斷每個事務的時間片是否到來，並進行標記}；}isr_server{{處理中斷}；}我們可以看到，這種改進後的思路，使得事務的執行時間得到控制，事務只在自己的時間片到來後，才會去執行，但我們發現，這種方式仍然不能徹底解決「實時性」的問題，因為某個事務的時間片到來後，也不能立即就執行，她必須等到當前事務的時間片用完，並且後面的事務時間片沒到來，她才有機會獲得「執行時間」。 這時候我們需要繼續改進思路, 為了使得某個事務的時間片到來後能立即執行，我們需要在時鍾中斷里判斷完時間片後，改變程序的返回位置，讓程序不返回到剛剛被打斷的位置，而從最新獲得了時間片的事務處開始執行，這樣就徹底解決了事務的實時問題。 我們在這個思路上，進行改進，我們需要在每次進入時鍾中斷前，保存CPU的當前狀態和當前事務用到的一些數據，然後我們進入時鍾中斷進行時間片處理，若發現有新的更緊急的事務的時間片到來了，則我們改變中斷的返回的地址，並在CPU中恢復這個更緊急的事務的現場，然後返回中斷開始執行這個更緊急的事務。 上面的這段話有些不好讀，事實上，這是因為要實現這個過程是有些復雜和麻煩的，這時候我們就需要找一個操作系統(OS)幫我們做這些事了，如果你能自己用代碼實現這個過程，事實上你就在自己寫操作系統了，其實從這里也可也看出，操作系統的原理其實並不那麼神秘，只是一些細節你很難做好。 uCos就是這樣一個操作系統，她能幫你完成這些事情，而且是很優雅的幫你完成！ uCos的用處遠不止幫你完成這個「事務時間片的處理」，她還能幫你處理各種超時，進行內存管理，完成任務間的通信等，有了她，程序的層次也更加清晰，給系統添加功能也更方便，這一切在大型項目中越發的明顯！我們知道了uCos能給我們提供這么多的便利，那麼我們就開始使用uCos吧！