Cortex M系列開始進入Tick-Tock時代

Intel的Tick-Tock策略是成就CPU帝國的重要推手。
沒想到Cortex-M也開始進入這樣的時代。

在今年(2013)年Cortex-M4進入火熱競爭的狀況下，在推展上很快進入價格戰。
也就是功能性推展(Tick)戰正在進行中。但Cost Down(Tock)也已經展開。
可是面對硬體價格低，功能卻不斷增加，但應用推展卻是緩慢的狀況下。
各廠商開始意識到，客戶是無法一口氣能夠控制複雜功能MCU。
韌體開始元件化，而硬體設定簡單化成為目前推展上的重點。

整合開發工具的方便性將會拉開Cortex-M系列和其他MCU開發上的差距。
也就是使用Cortex-M系列的工程師在圖型化界面拉一拉，就可以設定好MCU的工作模式。
反觀傳統MCU還在工程師一行行寫程式的狀況下，產能會逐漸拉開。

MCU功能多樣化，韌體元件化，程式資源的豐富性，PC資源連接。等等加速拉開Cortex M和傳統MCU之間的距離。
價格成為最後的底線，只要Cortex-M壓到多低，傳統MCU就只能更低。
而學MCU不是一二年可以成的，若是學傳統MCU只能在NT10元以下的MCU市場寫程式，可想而知薪水也高不起來。

Tick-Tock的出現，時代轉變。MCU的下一步?
還在觀察！

舊文章搬過來了。

總算搬成功了。文章有搬過來。
另一個隨意窩的也好了。不過那邊的不會主動去更新。
還是留一個連結：
通通都是半路出家

32位元MCU軟體的改變

8位元MCU最大的問題在ADC/DAC超過8位元後，取值及計算效能會下降。因為每筆資料皆需多次ALU計算。

16位元MCU則無此問題。它的問題是遇到32位元MCU。

8位元MCU多半沒有IP付費，應是說沒有利潤去買，不如自己做。

理論上16位元也是如此，但16位元自認為價格應高於8位元，價格不願低。

然後，32位元MCU突然在三年內劇降，直接壓縮了市場，價格直逼8位元。

16位元變成沒有空間。比價格比省電，不如8位元，比效能不如32位元。

再來是32位元不僅是核心快，週邊多到爆。幾乎和PDA接近。

更恐怖的是軟體，不用修改下，以前DOS程式近乎直接移。

這種軟體方便性不是8位元/16位元可以做到的。

和PC程式及資料相通，程式開發快且功能多。

32位元MCU對MCU是一場革命。

是一場軟體工程師對嵌入式系統主導設計的使用習慣變革。

大部分硬體信號可以由MCU內部軟硬體結構出來。

ADC/DAC精密度提高，使得濾波器可以使用軟體來做。

Flash容量一下子到1MB以上，多到可以做磁碟機來用。

一但檔案系統出現，連資料庫都可以放進去。

8/16位元要做，程式有得大改。

且大部分PC上的軟體多以作業系統下做主。

移到8/16位元會是大工程。

而32位元因有RTOS，所以問題小很多。

RTOS也有8/16位元，但因效能及RAM空間不足，安裝後不會有好表現。

MCU市場因使用慣性，不會馬上變化。

不過一但原先16位元可以用的應用，32位元會以優勢周邊攻入。

可能會有巨大資料儲存器，無線通信功能等等。

所以說像是PDA。

也可以說MCU正在PDA化，且價格不變。

MCU工程師也要進化為PDA工程師，不然就會變成傳統工程師，不再有價值。

這波革命是新的，軟體工程師正在工業化，變成勞工。若不升級，難保工程師之名。

開張

因為Yahoo部落格關閉了，另找一個家。

ProtoThreads於VS2010下編譯問題

過了許久才動作。先將ProtoThreads編起來。
在VS2010下竟然編不出來。
錯誤訊息是說將巨集的東西做變數是不行的。
奇怪了，不是只有取用行號。
發出錯誤的是debugger。

查了一下，要將Debug Information Format設定從/ZI改為/Zi
這個應是除錯用外部資料，可能是有干涉。
總算動起來了。

不過使用行號嵌入巨集應是可以做的。只是少人用。
另外一個C/C++先進功能，將Label做為變數值這個功能在VS2010也是不支援。
手上已有二支程式需要使用Label做為變數值的程式了。
分別用於Coroutine及動態編譯。
但二者皆有函式域限定問題。不過VS2010連這個功能都沒有也不用試了。
寫程式這麼久，開始出現程式寫得出來，編譯器編不出來的狀況。

真的不能限定使用單一語言，編不出來是Compiler的問題，不是人的問題。
程式創作也不應被語言限定。只要CPU可以執行，就一定可以寫得出來。

Protothreads結合簡單多工之構想

簡單多工在閱讀上有Task及Function不易分別的問題。這個部分用Protothreads來補強。
因為Protothreads功能限定在單一函式內。
所以Task在程式結構上會分成二部分。
一個是狀態及時間控制，此部分以Protothreads為主要描述。
另外的是資料處理，基本上這部分還是沒有改變。
工作元仍採用動態加入，主要是要限定反應時間。

一度還想用Protothreads為主結構，但發現有限制。
所以仍以簡單多工為主要結構，這樣在簡單多工上產生出來的動作行為仍可以使用。

這樣的程式結構和FPGA上寫法相似，程式分為狀態控制及資料處理。
這種調整，應可以使程式在有作業系統及無作業系統下看起來更為相似。

簡單多工將移轉到Protothreads

簡單多工的效率不錯，但一直有一個問題：可讀性。
並不是不可以讀，而是和PC上寫程式的風格有差異。

Bee很早就知道有Coroutine可以用，但已知的Coroutine只有在FreeRTOS上。
今天找到了Protothreads正是符合需求。

比對簡單多工，只是短時間性延時的實現使用Protothreads做出來，就可以完全取代。
再來就是情境上的使用差異，在實際使用後才能寫出來。