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

2 則留言:

  1. 最後結論呢?

    我當然認為以 stm32 的市占率及大陸一大票人幫他們搞平台版,

    完善這些UI 介面應該都不成問題,但我比較擔心的是:越往這一種MCU 上下游

    綁在一起的解決方案,可能到最後有可能回不去了。

    萬一改天碰到不是 stm32 平台時,怎麼辦?

    因為這些東西越綁是越龐大的東西。要移植到別的平台是越辛苦...

    所以我自己也還是保留一點其他做法。

    那你覺得像 emWin 呢?(我說的不是 STemwin 喔~要不然又要回頭被ST 掐住了)

    當然我覺得以MCU 原廠的產品銷售手法,這一種上下游全包的做法沒錯。

    但對於我們這一種整天在搞系統整合的東西,真的很難擔保:改天你也得

    面對其他MCU 方案時,怎麼辦呢?

    --- 純屬個人小看法而已。也望版主大大指教一下看法。謝謝!

    回覆刪除
    回覆
    1. 在一段時間的使用後,我是覺得可以出試用篇及實用篇。因為產品化的問題還不少。預告一下:試用篇的主要問題在C++及除錯。實用篇就有大哥您所說的問題出現了,個人就有面臨老闆想轉新唐的方案,不過我說大型案子是不太可能,結案效率差太多。小型案子才有機會。
      不過,現在最大問題不在研發,拿不拿得到MCU才是問題,小型案子有MCU可量產就偷笑了,根本沒得選。

      刪除