2021年10月28日 星期四

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底層分開來,這種整合是做不到。
目前評估只到這裏,其他的還在研究中。

2021年8月8日 星期日

行銷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的目的看起來很模糊(造福人類是什麼行銷?)。

2021年2月20日 星期六

最近用的MCU IDE整理

 STM32CubeIDE, MCU為STM32, UI是Eclipse, 編譯器是GCC

MCUXpresso IDE, MCU為iMX系列, UI是Eclipse, 編譯器是GCC

CodeWarrior IDE, MCU是HCS08, UI是Eclipse, 編譯器是專用及GCC

Simplicity Studio, MCU是C8051F380, UI是Eclipse, 編譯器是Keil C51及GCC

STDV, MCU是STM8, UI是專用, 編譯器是Cosmic

以上的C編譯器都免費使用。

看來會使用Eclipse介面在轉換MCU時就不會不適應。

2020年9月13日 星期日

STM32CubeIDE試用

 改用免費軟體來開發。所以重新試工具。

就簡單編個LED控制程式,程式是沒有問題,因為HAL都限定好名字。

比較有問題的是除錯。

Run為下載後全速跑。好像沒有中間停下來。

Debug是可以單步。也可以看裝置設定。也可以下載記憶體內容。

剩下的就是適應及功能組合。

2020年3月31日 星期二

手遊轉PC趨勢分析

最近微軟大放送無線搖桿,這不算什麼,也許在清庫存。
然後Bee還在玩為數不多的手遊都開始出PC版本,基本上都支援無線搖桿。
這就怪了! 怪事不會連著來,一定有事。
資訊不足,改用反推法。
若手遊要移植到PC,應做那些事?
  1. 使用的電腦語言可以換去PC重編,沒人會想重寫,又會有維護問題,沒有相同的程式碼一定不可能。
  2. 驅動程式要相容,這個不保證,但工一定比第一項來得小
  3. 引擎要相容,主要是3D引擎或是物理引擎。若有同套問題就小。
個人認為2,3項看運氣,但game數量如此多,一定有符合的。
再來就是第1項了。PC軟體主導是微軟,若是微軟的compiler打通這條路,後面會自然生成。
微軟如何造這場局往微軟想要的地方發展?
搖桿是XBOX的! 也就是局勢要往XBox走微軟才有商機。XBox也是一種PC。
這樣路就明顯了,若是手遊轉PC很簡單,同時轉成XBox也會很方便。
重點是PC的操作和XBox有點不同,這個坎要弄平,怎做?
就大量撒搖桿給PC。這下就串起來了。

嗯,這局有很多行銷行為,值得再研究。

2020年3月19日 星期四

手機上C compiler應用心得

算是記錄,因為還沒有找到理想的。
個人目標是做MCU上的程式試跑及除錯用。
(老婆逛街時放置狀態)

Mobile C
簡中介面,範例多。也可以連上手機部分裝置。
但只能單檔,在移轉應用上不方便。
移轉來的程式要另外作業,不容易作這樣的準備。

Cxxdroid
可以使用CMake,但試跑我的直譯器時,出現segment fault,不知道是那裏有問題。VS2019下沒有什麼問題。同程式在Mobile C下沒有問題。

CPP N-IDE
也可以用,相容性不錯。但缺少可以用的make,所以目前也是只能單檔。

2020年2月19日 星期三

工件語言及工作語言的功能及插件功能設計

DXP或是SVG都是工件語言,它只描述工件的樣子,但沒有說是如何做加工。
機器手動作語言是有加工程序,但它有它自己的語言及函式,和工件語言並不相同。
且各家機器人使用的工作語言也都不相同。
所以MCU製作的機器人就有二套語言,一個是工件語言解析器,另一個是它自己動作用的工作語言解析器。
工件語言解析器分解後變成工作語言格式,這是一般工作。
但現在軟體都流行插件,也就是使用者可以加工作程序。很多軟體會後加工DXP檔,就是要加入一些機器才有的工作行為。
若是沒有將工作語言獨立出來,插件功能就無法成形。
所謂的插件,就是工作語言函式,它由使用者從機器操作界面輸入,然後在指定的工件語言指令中插入。
對於使用者來說是工件語言指令插入,實則是分解成工作語言後才插入,只是使用者看不到工作語言層的狀況下會以為是工件指令插入。

本來是想以巨集方式解決,就是使用文章插入的方式做。
但後來想到有可能要解析工件語言參數的狀況,改成用函式插入,這樣就可以在執行時取得參數做判定。

有了工件語言,也有機會做使用者新加指令的可能。
在解析工件語言,若遇到無法解析指令,就轉跳去工作語言的使用者新增指令掛勾,就有機會利用工作語言去做新指令解析並插入對應函式。

在實際上這個插件功能可以做什麼? 主要用在加工中插入檢查功能。
機器手上除了加工手指外,還有camera手指,工件語言不會使用機器檢查機制,就要用插件來做。
變成加工到一半,可以叫camera進來看,簡言之就是拍照存證。
這樣的機器可以由使用者加檢查點,或是改變部分加工行為。