柳比歇夫的時間統計法

 1.只寫做事及花費時間

2.全天記錄

3.統計分析, 分類, 統計正事時間, 統計單項工時, 年度結算

只分工作及休息二類

工作再分： 中心工作, 附加工作, 社會工作

其他的都是休息活動

統計單一工作需要多少工時

找出下腳料

4.決策,制定計劃

簡單才是有效做事的方法，但如何才能找到簡單的方法? 還是要用科學

有關SWV的評估

 有人和Bee說，用SWV可以做很多除錯的事。我去查一下確實很好用，但它需要SWO這支腳。目前手上的ST-Link V2是沒有這支腳。要到ST-Link V3才有。或是上網買ST-Link V2-1這個變型debugger。待弄到手用了再寫後續...

STM32CubeIDE中合併BootLoader

將srecord-1.64-win32中的srec_cat.exe拷貝到專案\Debug之下。

然後將要合併的BootLoader.hex檔也放進來。

寫一個Merge.bat檔，內容為

srec_cat.exe Bootloader.hex -intel ProjectXXX.hex -intel -o ProjectXXX_all.hex -intel

修改Post Build Steps內容

發動Build Project後會自動生成合併檔

STM32 TouchGFX實際應用

 第一個是MCU換了。所以只能回去STM32CubeIDE上做編譯，這個問題不大。

然後再連上一個傳統的TFT，它是240*320 16bit color。

所以運作需要一個graphic buffer，容量為240*320*2 Byte = 153,600 Byte

一個MCU要超過64K RAM都不多。

所以第一個問題是要啟動 PartialFrameBufferManager

問題來了，要除錯看不到。

因為它是用hpp寫出來的，沒有用到就沒有實體程式。

有用到是有實體，但不在cpp檔中就無法設斷點。有時可以設斷點，但停下來很多變數又無法看。

另外若又加入freeRTOS，結果就是不動，還不知卡在那裏。

只好先拿掉freeRTOS，改成單工還可以追，只好先這樣弄。

弄出來的結果是RAM只用20KB，這個可以用的MCU就很多了。MCU不缺ROM，UI多是圖檔及字型檔，但RAM一向很少，RAM放不進去就無法用。

不過就算如此老闆還是想換成本低的MCU，主要是供貨問題。

不過我說沒法，整個專案生成時有150MB，大約一星期就可以生成這樣的量。換另一個MCU要做出類似的程式，沒有產生器，個人覺得進度以月來計。

結論是，TouchGFX確實綁在STM32上，但它可以將原先以月計的UI開發壓縮到以週計。

就看專案型式了，新專案比較適用，因為結案快，一年可以做好幾個案子。

若是cost down別人的，還是算了，光是MCU就壓不下來。

STM32 TouchGFX試用

 有客戶要做案子，希望看到會動的東西。

於是就用STM32的demo板做一個概念性的範例。

使用STM32F476 Discovery板做一個樣子。因為這個板子有支援，完全不需使用STM32CubeIDE及STM32CubeMX就可以更新程式。

然後就會遇到一個C工程師不太想遇到的問題: 升級成C++

個人不太想升，效益不好，90%的工作都在C上，升上去能用幾個案子?

所以只能選擇C/C++混編。

這個算簡單: C程式存成 *.c，不用改。

主要是在cpp內引用.c函式，要在函式前面多加 extern "C"

很快就做出樣本程式，還有Simulator的PC程式可以給客戶看一下。

對方很快的就提出正式規格了。

然後...痛苦的事一個一個來了。

STM32 TouchGFX評估

 因為專案需求UI又很趕的狀況下，只能利用別人的UI工具會比較快。UI後期最麻煩的是當圖型可以顯示，從老闆到業務到客戶每個人都會有意見。修改頻繁但不會是主功能。

個人很早就在想UI其實和MCU要控制的的事其實不太直接相關，其實可以單獨拉出來，用很少的界面函式去控制機器狀態機或是設計就可以了。

在2013年就有公司是利用硬體分開，出的所謂的顯示界面晶片。說穿了也是用另一個MCU將TFT及touch整合。當時採用的界面語言是arduino。不過這個是在不計成本下可行的方案，MCU本身就是有點成本敏感的市場，個人覺得不太可能有什麼量。

回到現在MCU本身的執行能力比以前強大，所以UI又回來了。但市場同時也有變化，手機人手一機。MCU有可能自己管理TFT+touch的UI，也可能利用手機通信產生在手機端的UI。

在架構上就有二個UI會存在，不管是在MCU上管理的UI，或是手機遠端UI。很明顯的核心和UI一定要分開，UI分離下模擬器就更有機會做出來。

個人在開發手機端測試時，MCU上只要有命令解析器就可以了。所以就使用類似終端機的界面就行了。這個很容易驗證，就算不用手機USB就會有這樣的應用。USB上架個VCP(virtual COM port)這個在STM32開發上只要勾個引用，就會帶入，不太需要了解太多就會生成一個USB VCP。USB通信驗證可以用，再轉去手機一般問題不大。

這次剛好遇到需要顯示+touch的案子。除了案子趕，可以預見的是後期只修改UI的非核心工作會很多。不能再用以前的土方法了。重新評估新工具: STM32 TouchGFX

看完資料後，發現TouchGFX可以生成PC模擬器，這個實現了個人很早以前的想法，更確定使用後可以有效降低修改頻率。因為生成的模擬器是沒有實體沒有錯，但所有畫面都可以先在PC上操作，客戶可以先行檢查。另外手機APP公司也可以先利用這個模擬器做手機界面。

再來是工具是如何使用?

大約的流程是這樣(目前還在試用，也許不太正確)。先用CubeMX生成專案，但要引入使用TouchGFX套件。

再來去CubeIDE內可以看到有專案內有多出TouchGFX專案入口檔，點它會開啟TouchGFX designer，它是UI 設計的核心(這個很大，還在研究中)。在designer中可以使用UI物件做編輯，最後再按Gererate Code就會生成程式碼，不過它是生成C++。C++個人一直覺得沒有必要用，因為MCU一般RAM不多，不用到如此複雜的管理。不過在使用TFT的場合下RAM的使用量會增加很多，再加上新式RAM(=OctoSPI SRAM)也出來了，外掛RAM的成本不如以前高。看來C++又要去看一下了。至於PC模擬，它用自帶的GCC編譯器，生成執行檔會在bin/下，要給別人用要整個目錄壓給別人，重點是內有很多DLL檔要一併給。

看得出來touchGFX就是利用MCU HAL函式及PC 的DLL做為其底層。只要函式名相同，就可以在調用HAL或DLL在二個平台上執行。果然只有大公司才有機會做這樣的整合。不過MCU不再是價格之爭，支援工具強大專案產出會有不同的效率。前題是若沒有HAL將MCU底層分開來，這種整合是做不到。

目前評估只到這裏，其他的還在研究中。

行銷5.0心得

 簡單翻過: 沒有說明5個版本行銷分界原因，但有將行為及現象說清楚。

行銷代別：

行銷1.0 產品導向

行销2.0 顧客中心導向

行銷3.0 以人為本行銷

行銷4.0 傳統轉型數位

行銷5.0 科技造福人類

行銷5.0 和 4.0 主要是多了一些行銷工具,一但使用完全壓過4.0。其中大多和AI相關。工具應用的目的再分類，形成新的主體。多的行銷戰術為:

資料行銷

預測行銷

場景行銷

增強行銷

敏捷行銷

以上行銷戰術不是新的，是從遊戲行銷來的。

主因是軟體服務+實體已成新產品。所以實體產品不是客戶唯一選擇。舉例，手機的選用只看硬體規格? 不否認有些X世代的消費者是，但目前人口已經很少了。

所以對遊戲行銷有研究的人來說，只是擴展，並正式納入成為行銷5.0。這也是行銷5.0的目的看起來很模糊(造福人類是什麼行銷?)。