因為移植了幾個程式，跑起來還是有點小問題，一一修正後，可以修正到我想要的結果。
但不同的不台，要加入不同的驅動方法。
像取用亂數這件事rand()。
在uCOS-II中，被視為共用資源，所以要保護起來。
但在Win32中有無保護都沒有影響。
現在才發現原來Win32已保護過了，所以一點影響也沒有。
但好玩的是每一個Task都有一樣序列的亂數。
那是因為在Win32，每一個Thread皆有自己的區域變數，rand()就是其一。
後來各task使用自己的srand()，利用windows的時間計數器為種子。
結果10個task只有分成二群，大概是使用雙核心的結果。
那在各task創造時加入不同的延時，果真創造出10個使用不同亂數序列的Task。
二年前還不了解的狀況，如今一下子就解開了。
試驗程式：
有十個Task，各自擁有唯一數字0~9，隨機找位置填入。
也就是擁有"0"的一直找地方填。其他Task也相同。
這是原始的程式結果，為MSDOS程式。
Win32模擬成功後的樣子。
發現所有Task皆使用一樣的亂數序列的狀況
這是加了使用系統時間做為亂數種子的結果，只有分成二群。
修改過最後結果。
版大您好,
回覆刪除我目前的工作是在使用MCU 直接寫Code , 對於 uC/OS 的應用 , 可以請教一下 ,
在單人開發的系統上, uC/OS 會有幫助嗎??
[版主回覆04/01/2012 12:20:44]使用RTOS的好處很多，不是只用於單人開發。依我目前的習慣是依據系統資源來決定是否使用RTOS。
使用8位元MCU，基本上不用考慮，用了效能消耗大。
16位元MCU，可以考慮，ROM/RAM的容量要夠。
32位元MCU，只要RAM夠就用。
ROM/RAM的消耗:uCOS為12KB/4KB，FreeRTOS為6KB/2KB，每開一個Task要另外加。
不符合條件的，皆用Bee自製的簡單多工。
寫MCU能在軟體擴充及效能上要能展現其實力，非要使用多工不可，連硬體的能力都要發揮。
這點不為什麼，因為軟體不會增加製造成本。
要是您在趕案子，還是不要直接用RTOS，出了問題一時解不了是會被K的。
一般有JTAG的除錯器下，RTOS會干擾Debuger的運作。
如果您很依賴Debugger，還是先用你自己的方法。這個時期還算是練功期，寫對比較重要。
對Debuger依賴低時，表示C的掌握度高，此時再考量使用多工的方法，以及RTOS的使用。
謝謝您的解答。
回覆刪除我目前使用 PIC30F 在開發系統，因是在控制 2 ~ 4 顆馬達，所以很重視效能。如果是一般人機介面，我或許敢用ＯＳ，但是如果太需要靠硬體的部分，為了怕做白工，所以還是使用我自己的控制流程。
您的８０５１簡單多工我在三年前有用過，還不錯，只是沒有寫來當正式產品，小Ｔｒｙ一下而已。
想請教你多工的部分，是因我都是一個人在開發ＭＣＵ系統，如果公司明後年人力增加，那我導入ＯＳ是否對整體開發比較有效率，還是系統可以切開成多人撰寫。
還是可以如Ｗｉｎ ＣＥ 一般，底層好了之後，上層的應用與控制就可以讓比較不懂硬體的人來處理。因我工作這幾年遇到的韌體工程師前輩都是一人開發ＭＣＵ系統，所以我對ＯＳ的開發使用上比較沒實務。
[版主回覆04/02/2012 13:29:47]使用多工就是希望可以多人開發，這是肯定的。但不可能完全分離，確實是有主要的工程師做底層，其餘的人寫應用層。
關鍵在於使用延時函式時，不要去干涉到別的Task。若是有人Delay是用while loop，就全卡在這個Task上，只是RTOS可以強制切換出來，但是效能還是被吃掉。所以不管那一種多工，對於Delay功能都要建立函式去管理。
四顆馬達，還好，但沒有內建硬體，軟體確實會很吃力。像是Cortex M0/M3內建PWM控制及Encoder解碼器的狀況下，軟體去管理四顆馬達還有多的能力去做信號處理。PIC要不是環境耐受力好，很容易被ARM給比下去。
我也是有在做馬達控制，新的PIC有用在機器人上的應用的MCU你可以試試。我是覺得並沒有花掉MCU太多計算力。而且TI的馬達Driver也做得不錯，依現在的IC，要簡化軟體負擔應是不難。會如此說，其實我不看好16位元MCU還可以活多久，看得上眼的只有MSP430，他的節能，無人能及。所以不是用8位元就是用32位元。這是我用MCU的感覺。