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
   
執行可以見到畫面了。