STM32 DMA軟體式FIFO程式

用在通信及ADC上，使用DMA循環式架構。利用DMA上的計數器做為FIFO控制。
其中USART1_BUFFER_SIZE，要設定在DMA的大小中。
 USART1_Buffer[]也是DMA所使用的。

unsigned short last_count;

void Reset_USART1_Buffer(void)
{
    last_count = DMA_GetCurrDataCounter(DMA2_Stream5);
}

int Get_USART1_Value(unsigned char *Value)
{
    unsigned short current_count;
    int  pos;

    current_count = DMA_GetCurrDataCounter(DMA2_Stream5);
    if ( current_count != last_count )
    {
        pos = USART1_BUFFER_SIZE - last_count;
        *Value = USART1_Buffer[pos];
        last_count--;
        if (last_count <= 0)
        {
            last_count = USART1_BUFFER_SIZE;
        }
        return -1;
    }
    else
    {
        return 0;
    }
}

因為已用DMA，軟體過一段時間去收就好了，完全無需使用中斷。

Encoder使用

這個月被二位網友問到Encoder問題。
Bee看過很多MCU工程師寫的程式，大部分工程師將I/O暫存器當RAM用。
但實際上硬體不穩定時，就查得要死要活的，很難穩定系統，又不知問題在那裏。
Bee也是過來人，因為早期Bee也寫過不穩定的硬體(用FPGA)，軟體上吃了大虧，自此養成必要時才動硬體暂存器的習慣。
也就是使用Encoder，必要時才讀，再轉成32位元變數(64位元也可以)，以32位元為其他軟體的依據。
這招不僅是減少對硬體的依賴度，也增加不同平台的可移植性。
同樣的Encoder程式，用在數個案子內：
1. 8051，使用中斷方式解Encoder，可用。
2. FPGA，使用I/O讀取24位元，可用。
3. STM32，內建Encoder，16位元，可用。
上層馬達控制程式完全不用修改。

其中有幾行連博士也覺得神奇，找過各大網站，就是找不到為何可以用。
以STM32系統為例：

int Encoder_Count;
unsigned short Last_Encoder;

void GetEncoder(void)
{
    unsigned short Encoder = 0;
    int Encoder_Diff;
   
    Encoder = TIM_GetCounter(ENC_TIMER);
    Encoder_Diff = (short)(Encoder - Last_Encoder);
    Last_Encoder = Encoder;
    Encoder_Count += Encoder_Diff;
}
Encoder_Count就是32位元Encoder的值，一樣不管Encoder暫存器是16/24位元，都先轉成32位元。
之後再重新計算，看是單向運動，圓週運動，基本上32位元都不會掉精度。

Encoder_Diff = (short)(Encoder - Last_Encoder);
此行則是利用unsigned在計算時underflow/overflow的特性得到差值，這是一般人不會使用的。

在FATFS Sample中新增PC檔案交換功能

FATFS可以在PC上模擬，是利用記憶體做的一個Disk，但創造後是空的，難以做其他實驗。所以新增二個指令可以將檔案搬進Fatfs系統及搬出Fatfs系統。

搬入指令fy，程式碼如下：

            case 'y' :    /* fy <src_name> <dst_name> - Copy a file from PC*/
                while (*ptr == ' ') ptr++;
                ptr2 = _tcschr(ptr, ' ');
                if (!ptr2) break;
                *ptr2++ = 0;
                while (*ptr2 == ' ') ptr2++;
                _tprintf(_T("Opening PC file \"%s\""), ptr);
                fp = fopen(ptr,"rb");
                _tprintf(_T("\n"));
                if (!fp) {
                    _tprintf(_T("Open Fail!\n"));
                    break;
                }
                while (*ptr2 == ' ') ptr2++;
                _tprintf(_T("Creating \"%s\""), ptr2);
                res = f_open(&file[1], ptr2, FA_CREATE_ALWAYS | FA_WRITE);
                _tprintf(_T("\n"));
                if (res) {
                    put_rc(res);
                    f_close(&file[0]);
                    break;
                }
                _tprintf(_T("Copying..."));
                p1 = 0;
                for (;;) {
                    s1 = fread(Buff, 1, sizeof Buff, fp);
                    if (s1 == 0) break;   /* error or eof */
                    res = f_write(&file[1], Buff, s1, &s2);
                    p1 += s2;
                    if (res || s2 < s1) break;   /* error or disk full */
                }
                _tprintf(_T("\n"));
                if (res) put_rc(res);
                fclose(fp);
                f_close(&file[1]);
                _tprintf(_T("%lu bytes copied.\n"), p1);
                break;

搬出指令fz，程式碼如下：
            case 'z' : /* fz <src_name> <dst_name> - Copy a file to PC*/
                while (*ptr == ' ') ptr++;
                ptr2 = _tcschr(ptr, ' ');
                if (!ptr2) break;
                *ptr2++ = 0;
                while (*ptr2 == ' ') ptr2++;
                _tprintf(_T("Opening \"%s\""), ptr);
                res = f_open(&file[0], ptr, FA_OPEN_EXISTING | FA_READ);
                _tprintf(_T("\n"));
                if (res) {
                    put_rc(res);
                    break;
                }
                while (*ptr2 == ' ') ptr2++;
                _tprintf(_T("Creating PC file \"%s\""), ptr2);
                fp = fopen(ptr2,"wb");
                _tprintf(_T("\n"));
                if (!fp) {
                    _tprintf(_T("Open Fail!\n"));
                    break;
                }
                _tprintf(_T("Copying..."));
                p1 = 0;
                for (;;) {
                    res = f_read(&file[0], Buff, sizeof Buff, &s1);
                    if (res || s1 == 0) break;   /* error or eof */
                    s2 = fwrite(Buff, 1, s1,fp);
                    p1 += s2;
                    if (s2 < s1) break;   /* error or disk full */
                }
                _tprintf(_T("\n"));
                if (res) put_rc(res);
                f_close(&file[0]);
                fclose(fp);
                _tprintf(_T("%lu bytes copied.\n"), p1);
                break;

程式基礎是從fx指令改出來的。

Cortex-M7核心新增特色

找了一些資料，才弄清楚多了那些。主要是針對Cortex-M4之間的差異。

1. 核心改為六級管線加上分支預測
2. Bus界面改為64位元，除增加效率外，增加定址能力對於大型儲存週邊有很大的幫助。
3. 核心正式放入近端記憶體。
   可增加對Call Stack存取速度，改進RTOS效能。
   也有可執行區，可以將需要高速執行程式碼放入，改善中斷效能。
4. 新增硬體除法指令

MCU推展最大障礙在於對軟體操作能力

調部門已四個月，原先進技術部門已分解，重新分配到電子部門。
在新案開發上，軟體人員具有否決權。
使用新式電路，因為以前研究過軟體驅動方式，將電路放內產品。
結果軟體部門否決，因為無法控制，要求舊式電路。
不只如此，對特定廠牌MCU也有依賴性。所以也不易更換MCU。

目前看到二個原因造成MCU升級或更換後的障礙，造成軟體人員不願更換。
1.  對於MCU信號操作的陌生。
    不想量信號的軟體人員會如此，和畢業科系無關。一但投入軟體，便不再碰信號。
2.  對於軟體主架構過度依賴。
    對於慣用8/16位元MCU的軟體人員，已經開發大量函式庫，不願去改舊程式碼。
    常見於接手的工程師，對於原軟體系統並不是很了解，不想動原系統。
    在非RTOS系統上開發的舊程式，此現象特別嚴重。
    因為RTOS就是將軟體和硬體作適當分離。一但沒有O.S.連最基礎的延時功能都大受MCU架構所影響。
    無RTOS的系統本身其移植性就很低。

對於一年要換數個MCU的Bee來說，是早已克服的問題。
這也許是MCU系統工程和MCU軟體工程上的差異。
不過MCU軟體工程，不是PC上的軟體工程，可以完全不碰信號的。       

Forth語言在Swarm發展之可行性

1.  Forth語言之困境
    身為Forther是不會願意接受這件事，但此為現狀，Bee很早就認為，只是隨ARM MCU之流行，情況更加嚴重。
    Forth因為小而完整發揮MCU能力，確實在8/16位元MCU上一直有特色。
    但隨著時代推展，進入32位元MCU時代，小而完整之特質已無法凸顯其特色。
    32位元MCU時代的特性為：
    1.  豐富週邊
    2.  大量免費C函式庫
    3.  大量免費軟體工具
        RTOS, FAT File System, USB Driver, Ethernet Example, GUI Library, SD Card Driver...等等。
    以上特色，使得MCU以C發展可以快速得到成果，Forth則無廠商願意寫函式庫，變得跟不上時代。
    32位元MCU各大廠又以軟體元件為其發展重點，快速拼裝已成為特性，大大的拉開C語言及其他語言的距離。
    32位元MCU除了C外，其他語言完全變成非主流。
   
2.  Swarm Robot / Multi-Robot System發展之問題
    Robot一直是MCU實現的好目標。使用Forth發展是很方便的。但因MCU隨著32位元時代來臨，Forth被淡忘。
    實際上單一Robot發展並不是很方便，若非C語言在MCU上有大量的工具，使用C語言是一項沒有得選擇的發展。
    Bee曾認為Forth在Robot上的發展可能有一席之地。但32位元MCU推展過於快速，完全沒有給Forth有時間及機會去成長。
    在一個偶然的機會，Bee想到找群體機器人(Swarm)上的相關資料，發現以目前的Robot發展是困難的。
    主因為在於Swarm Robot除了實現Robot外，需要解決Robot之間溝通之問題。
    實現通信不難，但Robot之間溝通，實為發展社會語言，若非有電腦語言發展能力，此問題不易解決。
    一般實作Robot，多以電子為主，語言只是實現工具，故一般工程師無法有效解決此問題。
    常用工具C語言在此問題上，完全是缺乏應用之空間。故在此領域推展很慢。
   
3.  Forth如何解決Robot通信及Swarm程式發展之可能
    Forth寫Robot程式和C寫Robot有很大的不同。
    C語言寫Robot比較像是外科手術：
    1. Robot關閉;  麻醉
    2. 寫程式下載; 開刀
    3. Robot打開;  叫醒
    但此程序對於多機器人的程式發展及測試是不利的。
    因為有很多狀況是機器人已經面對和另一個機器人要做溝通協調，外科手術反而打斷取得狀況的方法。
    Forth寫Robot程式則是像老師教學生：
    學生接受老師的指令，一步步動作。有新狀況也可以回報,並加以修正。
    在Swarm的環境，所有的通信都變成廣播型式的指令。
    Forth原先只有一個對象，在此環境中，只要增加指定對象的指令、交換資料的指令，就可以開始使用。
    此時程式設計師成為教練，每一個機器都是學生、學生間可以交換資料，並下命令改變其他學生的工作。
    故Forth可以直接成為Swarm Robot的自然語言，人機一體語言在此環境是極為自然的溝通。
    在通信格式上，幾乎只要將Forth指令用通信封包包一下就可以直接使用。
   
結論：
    Bee認為Forth的衰退是時代的必然。但Forth要能使用下去必須找一個符合的環境。
    只是經過長久的觀察才找出可以有效利用Forth特性的使用場所。
    另一個說法是：C語言在MCU上已是霸主。
    Forth在單打獨鬥上是輸C不少，所以就不要單打，改打群體戰。
    在群體戰這個新領域Forth再利用其小而完美的特性重新站起來。

Cortex M7面世對其他MCU影響

日前ARM發表了Cortex-M7 MCU核心。就規格上來看並沒有多出Cortex-M4很多。
其實因為Cortex-M7和Cortex-A5已有部分市場重疊，所以並沒有一口氣做出很大的超越。
不過倒是另一家公司的產品可慘了: PIC32。
PIC32是一直向Bee推廣，但Bee認為MPIS核心已不會成為主流，所以一直在觀望。
觀望的原因在於PIC32在效能上確實較CM3/4來得強。
但CM4已內建浮點運算器，而PIC32仍遲遲未推出帶有浮點運算器的狀況下，已開始處於劣勢。
唯一只剩下主頻仍強於CM4。
如今最後一項優勢也消失了，CM7可以達到PIC32的同頻且具備浮點運算器。
這下PIC32已完全失去硬體優勢。
剩下的就是軟體環境了。
就軟體開發性來說STM32系列是相當不錯，完全Open Source。只差會不會拼裝。
Microchip也是不錯，大部分功能也都有，但在核心的部分和MPLab相連。
造成移植上不好弄，有支援到可以直接用，沒支援到要拼裝就麻煩了。

另外一個32位元的MCU是TI的DSP。這顆在浮點運算上沒有問題。
但在實際使用上，週邊輸了一截。
也許在運算上，TI的DSP是有贏。不過STM32則是利用其DMA直通週邊，將週邊管理時間省下來。
使用靈活度上是以STM32來得靈活。

但Bee也發現大部分工程師即使已知MCU輸人一截的狀況下，大部分仍不願換新廠商MCU。
主因是要閱讀的資料量過大，要能有效運用，真的要花一點時間。在專案的壓力下，通常不採用新MCU。

MCU現在入門，不管是那一顆其資料手冊都破千頁。這個才是推展上的最大問題。
所以一時三刻，不會有明顯改變，但長期來看，應是很明顯了。

MCU使用回顅

最近和某個代理商FAE聊了一下，剛好將歷史上幾個重要的改變都提了一下。這些改變，也使得各時代MCU主導的廠商有所不同。
剛好記下來寫成文章。

8051時代，MCU是一門特殊行業，大部分是電子工程師兼程式撰寫。
因為MCU除了UART外，也沒有什麼周邊。寫程式還要一方產生除錯信號。軟體工具亦不全，ICE比車貴。還是自寫寫除錯比較實在。因為MCU效能低組合語言算是此時代的霸主。
其實Bee覺得C語言太貴也是組合語言流行的主因。
這個時代能好好發揮MCU的功能就很好了。
所以工程師比較喜歡使用具有應用說明的MCU。
故在此時代應用說明做的好MCU也會相對好推。MicroChip及Atmel就出了自己的MCU加上豐富文件，順利以非8051/6800進入市場。

後來週邊相對多了，C語言寫MCU開始流行。因為MCU整合週邊進同一個晶片，變成沒有信號可以量。此時寫軟體驅動變得相對重要。
另外內嵌除錯介面的MCU亦開始流行。此為MCU最多種類的時代。
因為每加入一項週邊大概就可以出一個型號，而新的MCU核心也不斷出現，開始強調便利性。
而8051在此也不是省油的燈，也一起增加週邊並改進核心效能。
不過整合進MCU也不是沒有代價，工程師更依賴軟體工具。
此時代有好的週邊範例程式才是推展重點。但大部分人的眼光仍在工具及MCU規格上。
MSP430則是Bee用起來不錯的MCU，TI在範例程式上很下功夫，所以開拓了不少新市場。
同時這個時代的工程師也開始變成專業，因為軟體變大也變複雜些。

而32位元MCU呢?各時代其實沒有缺席，只有一個問題，價格高很多，使用比率低。
ARM以省電及價格低進入市場。其實在省電這一項並沒有比MSP430來得好。不過32位元確實開始有需求。
另一個開始流行的重點是，當單價開始低於10美元時，和原本8/16位元MCU相近時，需求開始大量增加。
32位元MCU的使用，一方面是容量增加，沒有8/16位元MCU有64KB的限制。
另一個是軟體程式庫的使用，因為可以直接使用PC軟體程式庫。
經由軟體桯式庫，MCU可以再開拓以往8/16位元MCU不易做的，而PC原先就發展過的。
也就是部分MCU取代了部分原先工業電腦的領域，且體積小價格低。
這個時代工程師的需求轉而修改最接近的軟體架構，而不是從各週邊範例來合體。
另一個說法是，刪除不要的比較快。再加入特殊需求就好了。
可以提供如此需求就是ST，也造成其MCU開始流行。
當然STM32系列的週邊也是很豐富，也有不錯的工程設計，在升級時方便也是其優勢。

不過到此MCU開始變的更專業化，已不是原先電子工程師或軟體工程師可以容易轉入。出現了純電子/純軟體無法直接進入的專業知識=RTOS。
RTOS只是新MCU工程師的專業一部分，在此做為其電子無法理解的代表。
而在豐富到爆炸的週邊，要有效利用其週邊能力，又必須有電子知識，這是純軟體人員無法跨過的障礙。
除了RTOS，要能有使用32位元電腦軟體去拼裝成MCU使用軟體，也不是純電子人員能做的。
另外，分散式控制也出現了。將PC,MCU共同合作形成系統，也非純軟體可解決。因為系統分割，如何使用最少接線，還是偏向電子為多。
原先從8位元時代來的MCU專業人員，也面臨一樣問題。因為主要是學電子來的，一下子要使用如此豐富的軟體元件，不是一時三刻可以學得會。
32位元MCU工程師和8位元MCU工程師突然有所區隔。也就是同為MCU工程師，使用技術大大不同。連分享知識都可能造成另一方無法理解。

MCU的下一步呢?其實在硬體上已經沒有可以做的，因為差不多等於小型PC。
各MCU製造商也開始發現，其實新時代工程人員是明顯不足的。
所以重心開始調整為整合套件。而MCU的硬體是不相同的，就算是同一家只有出現相同週邊時才能做軟體套件。
硬體抽像層是接下來的重點。若是MCU使用上像軟體，只要元件拉一拉，就可以拼裝出系統，可以大幅降低使用門檻。
而且MCU升級到後繼MCU也比較沒有問題。

各時代有其不同需求，造就了不同的MCU及其製造商。
回顧歷史讓大家知道各時代的興衰。也希望可以啟發大家對未來新MCU的選擇。
或是給即將轉換到新時代MCU工程人員一個參考。

STM32 USB驅動程式的第一次

Bee大部分用RS232和PC溝通。但現在PC有RS232越來越少了。所以轉往USB看看。
USB的資料相對龐大許多。且USB相關程式也不在一般驅動函式庫上。
新的標準驅動函式庫已加入USB相關，有獨立資料夾，內容還是很多。
對於MCU的工程師來說，USB可能比CPU還要複雜。除了硬體層外，還有還有連接PC時一堆程序。
另一個問題是，無法像以前一樣用示波器就可以看。沒有封包解析器，完全無法了解到底是怎麼回事。
USB入門還真是不簡單！

結果，只有從依樣畫葫蘆開始，用Demo板上的USB及程式下去試。
內定的專案及程式是可以用。用的是High Speed的程式。
改為Full Speed端，就又不行了。
因為High Speed用的腳位太多了，會降低使用場合，還是FS有價值，但就是連不上。
Google了很多文章，突然出現一個字VBUS_SENSING_ENABLED。
心想，該不會除了D+及D-外，就是這支腳的問題了。於是註解掉重編譯。
總算過了！

只能說：比CPU還難搞！

MCU作業系統硬體化構想

Bee在大陸網站時討論的構想。現在台灣已沒有可討論的地方，所以逛到對岸去。
Bee曾說過，中斷是實現作業系統一個很重要的關鍵功能。
所以常用的作業系統功能是可以被硬體化的。
在PC上MMU就是一例。
而在MCU側，因無MMU環境多，被硬體化的地方其實不多。
而MCU使用RTOS的工程師比例也不高。所以作業系統硬體化不積極。

分析MCU上使用RTOS的需求，其實除了週邊硬體中斷外，使用最多的就是Timer。
所以Timer硬體化應是需求最高的。
其實很多RTOS也是以工作切換需時短做為其效能指標。
故RTOS的system tick一直是最常用到的函式。
在RTOS移植的第一個工作為context switch後，第二個工作就是system tick的移植。

在使用Cortex M3時可以發現system tick已經標準化。中斷也標準化。
所以Cortex M系統可以開始進行RTOS的統一。因為C語言已可以做完一大半工作。
現在RTOS仍有組合語言，是因為Task Control Block(TCB)各家不同，仍需用組合語言去完成。
即使TCB有統一，執行時最常用到的仍是system tick。
所以TCB使用硬體做，連接上system tick及其管理能力，就等於是將RTOS硬體化。
此時所有的程式看起來會有自己的CPU，但其實只是在RAM上的CPU暫存器影像。
也就是MCU開始具有虛擬化CPU核心的能力再加上system tick調度的能力。
這樣就算是完成RTOS硬體化。

若是這個硬體可以做進MCU，RTOS也就大一統了。
依現在人人都可以做出RTOS的狀況下，等在後面的是硬體公司的RTOS硬體化。
技術門檻變低的同時，也要小心全自動化的取代。

STM32Cube初看心得

ST推了一些時間了，但實在不是很清楚是什麼樣的東西。
最近在找USB函式庫，只好安裝起來找原始碼，才去了解這套是什麼。
安裝後，有分成二套。一套是Firmware套件，另一個是腳位驅動程式產生器。

驅動程式產生器對於寫MCU的人比較容易理解。
主因也在於現在MCU單一腳位的功能實在太多，確實有設定管理工具會方便許多。
就算是Bee這樣的老手，仍有發生因腳位搞錯了，除錯除了一、二個小時的糗事。

Firmware套件，解開來沒有應用程式，只是一個檔案夾。
後來才了解是分類好的Firmware結構。有RTOS,FatFs,USB等套件原始碼。
和以前的週邊驅動函式庫不同的是，多了一層抽象硬體層軟體架構(HAL)。
想想也是合理，硬體若是沒有用抽象化軟體層去統一，其他應用模組就要人工嵌套。
所以用HAL就可以統一，順便連相近MCU都一起統合起來。
也就是STM32全系列都可以統合使用這些軟體套件。
可說是MCU軟體元件化。

Bee在想，有了HAL，其實在PC上也可以實作成模擬器。到時常用元件，如GUI，是可以全部在PC上模擬出來。
其實現有的GUI已經有PC側模擬。只是HAL的統合會使界面更標準，實現上就更簡單了。

離職前擺爛是對的?

半年內部門一半人離職，我才發覺原來大部分人離職前擺爛，程度各有不同。
記得前公司，從我提出離職，就先趕手上工作到各一段落。
先依部長需求找人交接，沒有交代的部分，若是交接人不收，就另外找人交接。
再來是交接工作文件，光是寫文件就花了不少時間。
我的態度是：不要因個人離開，使工作斷，或是找不到程式。
所以到最後半天，才有空。因為電腦及文具都交出來了，真的沒有可以做的。

現在才發現，沒多少人這樣做。
離職提出就擺爛，別人因為工作做不下去就會自己接走，這是一般人的想法。
本以為管理主管會比較好，結果也一樣。
看到主管是這樣，心想我就算以後在別的公司再遇到這樣的人，絶不會一起工作，更不用說有工作機會介紹。
因為離職不是一個工作的結束，而是工作移轉的態度。
也許我將工作和個人成就看成一體。
但一般人工作就只是工作，換工作和個人無關。
可是換工作是不可能重回，老闆一般也不會去搭關係。可是同事在離職後仍是朋友，有好機會還是會在別家公司再見面。
所以離職只是人際關係上的改變，並不是切斷。
這也就是，為何有人老是有新工作等。而一般人為了找新工作而拼命。
因為工作交接做得好，其他人有好機會，一定會先找工作交接好的人來。
而工作交接擺爛的人，從本質上就是切斷，有機會也不會想到已經切斷的人。

以上只是個人想法。

RTOS Task無限迴圈內是什麼?

使用RTOS中的Task等同使用一個新的執行單元，所以除了初始化程序，再來就是一個無限迴圈了。
實際使用上，因為絶大部分不會執行Kill Task的狀況下，最好用的模型就是狀態機了。
也就是用switch case做狀態控制，使用狀態變數顯示工作狀態。
基於這個模型，使用Coroutine也相同，這也是PhotoThreads可以使用的原因。
Task和Coroutine皆使用狀態機做最上層控制，所以是可以互轉。
也就是架構對了，有沒有使用作業系統，其程式結構是相似的。
可以自由調整架構及大小，對於MCU軟體元件共用的很大的幫助。
必竟可以重覆使用軟體，可以省下很多開發時間。

64位元電腦流行後的MCU

明年(2015)開始，手機進入64位元時代。報導預計2018年就差不多過半手機使用64位元。
PC已經差不多都是用64位元了。
也就是使用32位元的只會剩下MCU。
32位元MCU開發也會進入新局面。基本上在PC上模擬應會變成主流。
各式軟體及硬體元件也幾乎可以在PC上做好。上MCU只是功能測試。
PC也未必使用完整Compiler軟體，On-Line Compiler會變成新趨勢，這是因應平板及手機上開發的需求。
MCU上開發軟體和軟體工程相近，基本動作是在拼裝軟體元件。
工程師新的技術將會移轉到如何使模擬器和MCU的結果盡可能相同。
也就是在PC上使用32位元模式，要和MCU的32位元執行是相近的。
而PC環境是和MCU不同，為了相似，使用作業系統將二邊環境拉近是必須。
另一個是MCU有可能多核?非常可能。
原先手機上32位元多核CPU可以修改為MCU。因為價格及週邊多會進入MCU市場內。
多核MCU的操作又會變成新技術。此時有無作業系統已不是選擇，變成是必須。
在MCU的設計上已經變成不是重點，MCU能做成的產品市場才是重點。
MCU的使用，會變成以軟體為主要工作。因為硬體可以選擇太多，已經不是關鍵。
在工程師等級上，也會呈現M型分布。只能使用8位元及可以使用32位元會明顯區隔開來。自然會反應在薪資上。

MCU和PC其實已經模糊了。或是說MCU已追上PC的腳步，只是應用上不同。
最後MCU也可能只是電腦應用的的一個分支。

ucgui於VS2010下編譯

取得3.90版本，發現有Simulation。在VS2010下卻編不出來。

有幾個問題：

1.  FiveChess.c找不到iostream.h
    解法: 直接註解掉
    因為這是C的寫法，VC6可以，但VS2010不行要改用namespace。不過沒有用到，所以直接註解掉。
   
2.  Linker找不到LIBC.lib
    解法: 修改propreites設定
    Linker->Input->Ignore Specific Default Library
    將內容libcmt.lib改為LIBC.lib
       
3.  Debugger找不到執行檔
    解法: 修改propreites設定
    Linker->General->Output File
    將內容Simulation.exe改為SimulationShip.exe
   
執行可以見到畫面了。