老工程師的技術生活(三十四) --- 系統整合，技術商品化最後一哩路

我們過去經常討論關於 MCU 或單晶片的使用經驗與一些相關周邊的技術討論。

譬如：我過去也有專注  USB 介面技術整理了很多初步入門概念，到一些韌體

與軟體相關開發工作經驗。但其實這些許多單項或系統周邊應用領域來說：

都有其使用上的優缺點及使用上的適合性。有人覺得 UART 就夠用了，

也有人覺得 USB 好用，也有人覺得RF/Wifi 或藍芽等也不錯啊。當然我之前也有

在車用系統平台上舉了一些實務例子來說明 CAN Bus 的優勢等。

這些系統例子如果真的要一一的拿出來研究，寫寫技術文章，讓你搞一輩子也

寫不完啊。就算現在一顆 32 bit MCU 也都幫你整合了許多這方面的周邊資源。

但你也未必會在一個產品系統開發上，都會把這些周邊技術給全用上的。

這就回到一個很簡單又很嚴肅的議題：你要如何把這些周邊技術整合到一個

終端商品的系統之中？

我們現在當然可以用一顆 32 bits MCU 加上豐富的周邊支援與本身超強的運算能力，

我們當然可以拿來 Demo 演示一個影像識別處理，或一個多媒體撥放器，那就

更不用說那些所謂機械電機馬達控制了啊。但就搞這些技術就可以變現換

營收獲利嗎？我們大部分所碰到的商品化交易的，絕大多數都是要一個完整的

系統產品：除了這些周邊控制技術之外，還需要支援許多人機操作介面，或是與

其他相關周邊裝置連結與互動交換資訊的運算與操作處理。

所以你會常常在許多社群媒體上，看到很多創意或技術演示影片，看起來都

非常完美或令人稱奇，但實際上：這些技術演示最後有多少可以走到最後

商品包裝上架銷售的呢？你自己也可以回想自己工作以來：到底參與的產品

開發過程中，有多少真的完完全全的走完技術開發，系統整合，產品驗證測試，

乃至於量產包裝上架銷售的？而這樣的過程：你們是用多少資源、人力與多少

時程完成的？

我舉一下我本身的例子：

第一次搞Scanner SOC(含USB 介面開發)：前前後後超過三年，才真正在市面上

看到我們的這顆 SOC 埋在一台掃描器出貨...一個結合IC 設計，韌體系統開發

驗證，軟體(驅動程式)支援，業務及IC 生產製造等人力資源的投入。

我自己做的 數位CDI 點火控制器：從硬體、軟體到整個客戶驗證完成， 再到

我自己的量產QC 平台架起來，前前後後也走超過五年。(我自己一個人)

你說：我搞USB 的這項技術需要這麼久嗎？我自己寫個簡單的引擎轉速偵測

計算，然後準確地送出點火控制訊號會很難嗎？當然沒有那麼難，也沒那麼複雜啊。

(雖然我還是因為有一些之前國外的技術文件支援及基礎受訓課程的基礎了)

重點是甚麼？當然就是還是需要最終的系統整合工作，來完善一個技術的商品化。

在過程中，你的薪資、水電管銷費用要算誰的？你沒募資，沒押一點自己的本怎麼行？

---

以現在強大的MCU 與周邊硬體支援功能，你要寫個 USB 介面、弄個馬達控制等，

我都覺得這沒啥好拿出來講的。別人可以用八位元寫、也可以用一般 32 bits MCU 寫，

當然也可以用稍微搭配專業領域的MCU 、芯片來做。只要只是簡單的單項技術應用

都可以的。但問題是：現在許多商品就不光只是這些簡單應用就可以拿出來賣了啊。

肯定就是綁了一大堆周邊應用，還支援這些、支援那些等等才可以啊。

(有時還得在這些周邊或單項應用技術上，犧牲一點應用效能才行。)

這就考驗著你在系統開發整合能力上的規劃與落實執行的經驗了啊。

為什麼我過去一直強調創業開公司：不要老是想接外包委託設計案，因為

你做的工作與所從事的技術領域，都是別人早就幫你規劃好，切割完之後才

分包給你的，或是你根本很難參與到這些外包商品最終的系統整合工作的。

開公司搞技術總是在這些單項領域，或是侷限在某些應用條件下發展，

其實你是很難走出比較大的格局與視野的啦。當然小公司，資源有限會限制

你的思維，但你是否有曾經認真想過此類似的癥結問題呢？

這還牽涉到人家公司對於此產品市場企劃與業務行銷策略等...你所沒看到的。

就算你接過或幫過世上一流大公司的委外設計或技術開發工作，那又如何？

你還是你啊。人家商品拿出來銷售，也不會在產品行銷發表會上提到你啊，

你又不知道人家最後到底有沒有把你的技術給整合進去呢？就別太自戀了啊。

所以寫單項周邊應用技術不難，但如何規劃與整合系統才是你一輩子要去累積

的寶貴經驗，但這些都需要實實在在非常務實的技術開發與整合工作。

以下我就這些簡單的經驗分享給各位參考：

----

第一個就是如何建立屬於自己的系統更新與升級方法？因為沒有一個產品技術

不會碰到系統開發更新韌體或未來修改與系統升級的。在你還沒開始寫程式，

進行系統整合開發前，你就得先規劃與想好的。

這是我二十幾年前進入業界，碰到的第一顆要撰寫 8051 韌體程式的平台架構，

我們可以看到系統可以透過USB --> DMA3 -->Data Buffer--> DMA1 來更新韌體的。

所以我們系統開發上就非常方便的不需要額外的硬體開發工具平台就可以了。

甚至我還可以依照不同的系統應用來不斷的隨時更新8051 所需要的韌體程式：

我在之前有用他弄了一套 LED DMX512 控制系統，就是利用這個非常方便的

韌體更新機制來開發 LED 燈條節目：相關演示影片連結。

所以你根本不需要多大的程式記憶體容量，就可以做到豐富節目的控制程式。

當然以現在 32 bits 標準MCU 也都可以做到這一點了， 以下是我一個用 stm32 所規劃的

系統更新升級功能：

同理，你只要有個 Bootloader 就可以隨時更新韌體程式了，當然以 stm32 架構來說，

他也可以讓程式下載到內部的 SRAM 去執行系統程式的。所以你就在系統開發之前

就得要好好的規劃與整理出你的系統開發整合平台的：

這樣子，你才可以把系統開發工作給分包出去給不同的工程師或系統應用開發人員使用，

然後你未來在系統整合工作上有更好的測試驗證平台。只要你在業界有一定的資歷就會

懂這些道理的啦。尤其當你在技術團隊的資歷累積到一定的程度之後，你就更應該懂得

這些東西，因為你是技術主管，你要懂得如何架設與規畫這些東西的。

那這些平台分包的工作越來越多，又越來越複雜時，你又要該如何讓每個子系統或周邊

應用資源不要彼此影響或造成系統負擔呢？此時你可能也要幫忙進一步規劃一套系統

平台的"多工作業系統"。尤其當現在 32 bits MCU 的功能越強大，你就越需要考慮這個

東西了，市面上有很多參考的"即時多工系統"平台供你使用，譬如 FreeRTOS、 uC-OS

或你自己也可以設計一個簡單的"分時多工系統"(Time-Division Multiplexing)" 。哪種系統

平台適合你的系統整合用，這就考驗著你在產品商業市場上的"Domain Knowledge" 了。

現在不同的應用領域，也都有非常多的參考範例平台，舉個例子來說：有名的

無刷馬達控制模組系統： VESC ，他也內建一個作業系統：ChibiOS。

而我自己本身一開始接觸單晶片MCU 時，是看到國外引擎控制系統的韌體架構，

他也有一個自己的分時多工系統，簡單又好用，我一直沿用到許多簡單又需要一點

多工處理能力的平台上，以下是他原來的系統平台規劃原則：

我們可以看到：一個八位元的單晶片，他所要處理的周邊感知器(溫度、壓力等)

或其他控制單元，其實是非常忙碌與辛苦的。所以他就依照每個感知器的物理反應

能力與系統所需的即時資訊，作一個簡單的分時多工的處理(第二列所示)。

而至於這些分時多工要如何架設與規劃？這就真的要是你的實際應用而定。

這才是考驗你在這個系統應用整合能力了。

------------------------------

我在上一篇文章中，我有把她分享到社群媒體上，其中有位讀者的回覆留言，

我覺得值得深思的問題： 

感謝賈老師好文,當代對於成本評估為方案架構中BOM價+開發成本.總價算法.

所以確實不一定要拘泥舊的開發方法.

我是很羨慕當年EE工程師只要專心技術,真的還可以賺到不少錢...

(雖然產品都有點灰色邊緣....etc 盜版電玩,賭博機台等)

那像現在技術實力要夠外,還要分心處理非技術部份才會有比較好的收入...

不是當年EE 工程師命好，而是真的時代不一樣了。以前，單晶片MCU 的功能有限，

開發工具或平台也沒現在這麼發達或平易近人...能搞懂的，或能融會貫通、或是那時

MCU單晶片能做的產品功能也比較簡單，所以只要你找到對的產品，對的應用市場，

當然就有很好的機會。

但現在呢？一個 MCU 單晶片 或一個單項的應用領域，其實也都沒有那麼明顯的

應用市場可以發揮了。就像我懂USB 介面，就算我會寫引擎控制程式等，或是

會寫個無刷馬達的控制程式，其實都不是很難的挑戰，因為這些東西現在網路上

有很多類似的Open Source 可以供你參考使用，甚至有些MCU 原廠都可以免費的

提供相關設計程式範例或開發工具平台給你用。就像你在Arduino 平台上弄個LCD 

面板顯示或相關應用，在我們這些資深應用工程師們眼中，也都不是太困難的挑戰。

大家可以留意一下：早期有些網路的博主，會針對 Arduino 平台應用，寫了許多

外接擴充板模組的範例或使用方法....但慢慢的，他們部落格也會失去鎂光燈的焦點。

為什麼？道理是一樣的。因為這些在單晶片平台上，針對單一模組或單項技術開發

應用，其實也都還是停留在技術研究或探討而已，最後其實都很難走到系統整合，

也就是技術轉換成商品化的最後一哩路的。

許多人看了這些技術文章內容之後，還是無法真正落實到產品商業化的系統整合

開發驗證測試平台階段的。你以為園區那些科技大公司的工程師們，整天在公司裡

寫程式，忙得天昏地暗的，就真的只是鑽研一個單項的系統應用問題而已嗎？

弄個影像處理SOC 晶片，就只是像我們搞 Arduino 平台這麼簡單嗎？

當然不是的啦。就像我自己的經驗一樣：從系統應用市場回推到一開始的系統

整合規劃與架設開發驗證測試平台，不斷的來回折衝與討論，這邊是否要退一點

系統效能？那一邊要不要犧牲一點操作不便之處？不行...那到底可不可以魚與熊掌

兼得呢？大家就努力的集思廣益的反覆驗證開發與平台測試...

我記得：我園區IC 設計公司，在第一顆Set-Top Box 開發過程中，光一開始到底

要選用哪一種即時作業系統時，就不知道開了多少跨部門會議討論，投入了多少

軟、韌體及硬體IC 設計工程師們進行多項的可行性評估實驗與開發設計....

大家都是從這些系統平台實戰經驗中給磨練出一身資深又豐富的工程歷練。

這些都不是你一家小公司或小小工作室可以相比擬的。(人力、物力與資源等)

所以你在媒體社群網路上，看到很多Maker 玩家出來展現一個成果時，為什麼

沒有多少資深工程師們會出來按讚，喊個好棒棒的呢？也不會很熱衷追蹤與建議？

因為大家都知道：很多技術的沒有做到系統整合，來落實技術商品化的最後一哩路，

其實對老闆、對投資者來說，還是沒有多大的市場價值的啦。

---

如果你還年輕，你當然可以報名上課：上一些MCU 單晶片基礎課程，你也可以去

上個 USB 應用課程或是去上個電機馬達控制課程，回來之後，你會寫MCU 單晶片

程式，你懂了USB 介面，也把馬達給轉起來了...然後呢？你終究還是得去歷練出

產品商品化的系統整合資歷的啦。以下我來舉個我自己USB 應用例子：

常來我部落格的讀者應該對版主我的USB 技術能力，不會有任何懷疑吧，

但我還是會在系統應用整合上，陰溝裡翻船的。我以前在USB 與PC Host端的

韌體與軟體開發上，一直很堅持說：有通訊協議問題，一定要明確地去解決。

不要為了省事，PC host 端不要隨便加個 Delay 語法來避開問題。(以 C 語言來說

不是 delay 啦，而是 Sleep(n mSec) 。)

以上是我在 stm32 的 USB 軟體控制介面，去要求 stm32 去做內部 flash 更新工作。

然後，上層的應用軟體就開始 Polling stm32 是否已經完成內部flash 更新工作。

看到分析儀看到了甚麼？竟然單晶片與PC Host 端系統資料交換會失敗(掉資料)，

造成USB 介面 Reset .....其實這是一個非常簡單的USB 介面應用，正常的所有USB

介面控制介面都很正常，但在系統應用整合時，他就是會出問題啊。

你說這樣的問題，公司怎麼可以讓你的產品順利地通過品管出貨呢？

好吧~直接說答案啦：因為stm32 在處理內部 flash write (更新)時，他MCU 是會停止

不動的。所以此時PC host 端下的任何USB 指令就可能遺失了...

解法：你就不得不加入 Sleep( Delay)  指令啊。<--- 簡直重重的打自己臉啊！😁😂😂

 ----

所以啦。你現在要我天天拿USB 技術應用，來寫一大堆技術文章，然後來賺取

網路流量，或拿來噴別人說：自己搞USB 比誰還資深、厲害....有甚麼鳥用？

當你拿這個東西真的碰到系統整合測試驗證，要走到生產出貨時。還不是又會被

打回原形了嗎？沒有整合到產品最終的整體驗證測試品管過的~在老闆眼裡：

都只是工程師們自己 high~自己爽而已啦。😅😅😅

這張照片是我今年寫的一個生產驗證品管中所使用的 USB介面 PC 應用程式軟體之一。

產線上的小姐只要簡單按照螢幕上的軟體操作，就可以完成產品品管出貨了。

當然就是出貨收錢啊。看似簡單的螢幕操作，其實下方就是一台待出貨的產品系統

驗證QC 平台。搭配生產輔助設備，模擬出系統產品真正實際的應用環境...

系統整合不是工程師自己寫程式寫得自 High 就好，如何讓產線人員輕鬆領薪水，

在老闆眼中，你才有你的工程價值啊，在公司中你也比較有人緣啊~😍😍😍

---

各位年輕工程師們，這個時代裡，你真正要學的不是那些基礎的MCU 單晶片，

也不是甚麼USB 通訊界面，也不是甚麼引擎控制程式或電機馬達控制...

你的未來真正需要的，可以幫你有更高、更遠的工程師視野的，是這些

不容易磨練出來的系統整合能力 (一個產品從系統規格定義，架構系統框架，

建立起系統整合開發平台，再到後段的產品驗證測試，協助產線品管檢測出貨等)，

老闆、企業主需要的就是你可以幫公司的產品完成最後一哩路的工作能力。