2024年9月12日 星期四

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

我們過去經常討論關於 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 SOC開發過程中,光一開始到底

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

軟、韌體及硬體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 通訊界面,也不是甚麼引擎控制程式或電機馬達控制...

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

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

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

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

27 則留言:

  1. 大學也有在搞LED相關的應用,那時候是先用8051做單色LED的POV Display,可以透過PC Windows APP或Android APP以藍芽傳輸資料去改變顯示內容,本來還想再整三顆 74HC595去針對RGB LED三隻腳位做控制的,讓他可以顯示彩色內容,但當時覺得太難就沒做下去。結果現在燈條好像都是直接把這部分整合成控制IC在RGB LED裡了,像WS2812B,所以彩色的POV Display早就到處都是了,真的都是在比誰系統整合最好,能最快完成商品。

    回覆刪除
    回覆
    1. 你只要知道單色 POV Display 怎麼做就好了。
      至於還要再搞那個三色 RGB LED ,其實意義就不大了。
      除非真的有那個應用市場,或是有人願意費錢或有其他
      利益交換條件再投入資源(人力、物力與金錢成本等...)
      ---
      因為接下來就不是工程技術問題了,就是我們常說的:
      那是應用市場客戶業務問題了。
      這種道理與感覺,等你慢慢"資深"一點就知道了。

      刪除
    2. WS2812B做會有更新率不足,應該是做不出來。又因WS2812只有4pin(power就用去2pin)資料率上不去。要找其他資料線比較多的傳輸晶片才行。WS2812只合適做靜態顯示的應用。因為它的設計只用來對付靜態人眼視覺。

      刪除
    3. @Bee 謝謝你提供相關技術訊息。
      大家可以參考一下。
      據我所知:一般POV 的LED 都是用 74HC595 ,就可以用
      硬體的 SPI 來支援了。也供各位參考了。
      ---
      反正這些東西在技術上都可以簡單輕易克服的。
      不懂或沒經驗,只要多做多看就可以了。

      刪除
    4. 改用SK9822,它是SPI輸出,一顆有6pin,但因為layout上成本比WS2812貴,使用量不足,我下單沒說明是要給機器視覺用,就寄給我WS2812。變成手上一堆實驗板以及燈條。所以記得很清楚差異性。

      刪除
    5. 我真的不知道還有這一種 5050 的LED 型號耶。
      APA102C 及 SK9822 。不過,我搜尋一下,真的沒有WS2812 普遍。

      非常謝謝你的資訊。

      刪除
    6. 感謝Bee的資訊,因為最近是在用WS2812本來以為市面上的應用都是用這顆。

      刪除
    7. 不過。因為市面上的LED字幕機裡,都是使用結合
      74HC595介面(SPI)+定電流功能的專用驅動控制IC ,
      所以這種SPI 內建在 LED 中的,真的比較少見。
      畢竟那一種大型LED 廣告或電視牆的顯示驅動,
      應該還是需要定電流驅動功能為主。
      這樣的市場需求真的比較大。
      而WS2812 就比較出現在這一種簡單燈條控制市場上。
      控制上只要簡單便宜就好。一條控制線畢竟還是簡單
      便宜啊。
      道理都是一樣的:技術不難,成本創造的業務市場才是王道。

      刪除
    8. 我翻到程式,ws2812b及sk9822寫成一個,都用spi驅動。因為程式96%共用所以寫在一起。usb可驅動,會生成virual-COM,可以寫指令點單燈。目前用在8*8 WS2812燈板以及SK9822 128顆燈條上。MCU=stm32F072。試過是可以用手機供電做單點demo。都是自己拼湊自寫的。

      刪除
    9. 我的確在網路上有找到有人用 STM32 的SPI+DMA 做到
      WS2812 的燈條控制。戲法真的大家都會變的~
      (還有人用SPI 的Payload 資料的三個Bits來定義 WS2812 的 1/0:
      110 : 1/100:0 )
      所以我為什麼會想這篇文章:
      針對這種周邊控制,就算是複雜的無刷馬達控制,
      搭配特定的MCU ,外加原廠提供的範例與開發工具,
      現在都不是很複雜的系統應用,但最難的,最麻煩的:
      就是當客戶市場端提出相關產品應用規格之後,
      你要如何架設這些周邊應用的系統整合平台?
      包括:你的開發除錯與系統升級、系統輔助驗證平台?
      你還要能提供給客戶的後端測試人員簡單的操作系統工具平台。
      要不然,就是我說的:你寫這些東西,寫很爽,寫得很得意。
      那又怎樣?阿福跟宋狀師(宋世傑)說的一樣:
      寫得漂亮有甚麼用?我又不能掛起來,我還不是還要找別人
      再寫一次啊。😁😂😂

      刪除
    10. 阿福與宋狀師的對話故事:
      https://chamberplus.blogspot.com/2023/09/blog-post.html

      刪除
    11. 個人解讀是 => 能夠換現金 "卡實在"

      刪除
    12. 這只是用WS2812做實驗的過程,然後我證明它是失敗的,再來是換成SK9822,當然不是直接換"現金",LED控制只是光控的一部分。我做的是機器視覺。還有一位匿名的在插話,感謝各位關心。

      刪除
    13. 個人解讀是 => 能夠換現金 "卡實在" ...
      是啊,要講技術誰不會啊,只要給你時間,有人願意付你薪水,
      或是你有家產不用你供養家裡,老人小孩也不用你照顧...
      你要怎麼玩?你高興就好。<--- 如果是我,我也喜歡啊。
      但現實就是絕對多數的人都不如此啊。

      刪除
    14. @Bee 沒關係啦。
      對你這種老鳥工程師,隨便花點時間來做個簡單實驗,
      也沒啥多大損失啊。
      我有朋友在做半導體設備的:
      https://www.bestintech.com.tw/zh-tw/index.php
      你有沒有興趣啊?需要我幫你引薦一下嗎?
      開公司衝市場,那就是完全不一樣的玩法了。

      刪除
    15. 感謝您的關心,不過距離有點遠且目前工作才上手要做重要產品升級。暫時沒有想異動。

      刪除
    16. 真巧,下午我就在寫autoFocus相關功能,系統慢,用PC算就可以了。

      刪除
    17. 我自己也常常用 Visual Studio 寫 C++ 語言視窗應用程式。
      甚至有些工程運算、或是邏輯副程式,也都是在PC 上先
      模擬試算驗證後,再移植到單晶片(embedded) 系統中的。
      ---
      其實PC 在一般工程算力上,已經不錯了啦。
      況且PC 也算是一個穩定成熟的市場,
      但Intel 這一種大公司,就是不能以穩定成熟的市場佔有率
      為滿足的。真的辛苦啦。

      刪除
  2. 然後想冒昧請問一下,最近剛碰stm32的mcu,用STLINK V2 Unitity都無法Connect到,這方面不知道是什麼問題,有照網路上的去調整boot 0和boot 1 High Low都還是沒辦法,想說先確認MCU是不是活著,該如何確認?

    回覆刪除
    回覆
    1. 你可能要留一下:
      你的目標板上面有沒有硬體的 RESET (NRST) 那隻腳?
      STlink-V2 要連結目標版的 MCU 時,是要先把NRST 先壓著。
      然後在 STlink V2 Utility 上面按連線時,放開NRST 。
      你只要操作幾次就知道了。
      我猜應該就是這個問題點吧。
      你試試看~不行再提出討論。
      要寫韌體。最好自己也學點硬體Debug,如果有個硬體高手
      可以幫忙是最好的~這樣子比較快。

      刪除
    2. 感謝回覆,目前發現可能是這塊板子的問題,之後去百年買另一塊板子就沒這問題。

      刪除
    3. 在百年買?所以你也是在新竹了囉?
      能解決問題最好,

      我外甥也在新竹園區上班,真的辛苦,
      他現在的生活態度就是:只要花錢能買時間,
      他就不要再想太多了。
      我現在年紀也大了,也體會得到:省錢過日子,
      很容易失去生活品質,不如趕快持續去創造
      業績收入,還比較實際一點。
      但這種年紀,說是簡單,但要如何做到?
      真的很難啊,所以才常常奉勸年輕人:
      年輕時,鑽研技術無可厚非,但真的要想遠一點啦。
      不過,等你慢慢累積歲月之後,你自然就會懂了。
      大家加油囉。

      刪除
    4. 是的,目前是在竹科一家二線網通廠擔任軟體工程師,在網通業資歷比較長,之前是在某間小間的USB IC Design House 寫macOS driver,給的薪水實在不高,就又回到網通業,但還是希望回到IC廠,想趁業餘學一些韌體設計,只是以前比較少碰stm的mcu,比較常碰Atmel AVR和8051的MCU,所以也不太會debug,感謝前輩提供寶貴意見。

      刪除
    5. 我是不知道你所謂的"小間" IC 公司規模。
      但我相信:現在規模不大的IC 設計公司生存不易。
      這就跟我們文中討論單晶片市場趨勢一樣:
      複雜的應用市場逼迫 IC (SOC) 功能趨於複雜強大,
      也代表著設計驗證複雜,生產風險與成本都變大。
      (晶圓代工不容易取得與生產封裝資源有限)
      但市場卻趨於相信大者恆大的定律。
      想在百家齊鳴的IC設計公司中突圍,真的不容易啊。
      ---
      至於學習技術,最佳環境還是在於案例的參與及實施。
      有實際案例(我指的是:有人願意付出薪水及有個明確的
      市場規格定義的產品設計功能),這樣子才會有資源、
      有配合團隊一起參與(包括:系統平台、硬體及設備實驗室等)

      像那些坊間的短期教育課程啦,甚麼名師授課...個人認為
      入門可以,但長期實質意義不大。
      就像你去那家"小間" IC 公司一樣,我相信人家出來開公司,
      在技術或某個初始資金上,也有一定的過人之處,
      但你為什麼還會想離開再回原來跑道?
      那肯定你看到、或想到一些長期規劃的缺失與盲點吧。
      真的不要過於相信:我在某個大師底下,跟著幾年我就
      會一樣的成為大師的。沒有資源,也沒有實質的市場產品
      設計驗證生產行銷整體的歷練,光只有學習技術是沒有用的啦。
      ---
      師傅你技術好,但我不用跟著師傅你學技術,我應該利用
      師傅你的技術來看看見習,師傅你要如何做生意?
      或是我直接反過來:拿這些技術來創造商品市場,
      行銷開創營收獲利。這不是更好嗎?

      刪除
  3. 本來是想寫系統整合想法,後來又放著。現代軟體的工作變多也不可能只由一人完成。個人上次和人合作,個人包下太多軟體變成公司產品發展瓶頸。有二個系統整合問題可以看到1. 產品整合上的技術問題:現代MCU產品在應用上有可能連線到手機進而上網路,MCU->手機->雲端有跨系統整合問題。2.MCU內部拼裝不同函式庫的可能,系統複雜且可能影響到穩定性。要是又有AI導入,AI程式要放雲端還是放MCU也是問題,更何況AI工程師又是另一類的軟體工程師,跨域整合又是一個問題。員工是可以不用面對這問題,這是主管要面對的,但主管也不一定有認知到這個問題。我可以看到,但要如何和高層溝通?
    這應該是這個時代才出現的問題。所以跟本上找不到參考。

    回覆刪除
    回覆
    1. 嗯~闡述得很好。
      這也是我想表達的概念:
      現在單晶片整合系統已經很難像以前一樣:
      只要寫一個獨立運作的控制系統平台就可以了。
      雖然有些單晶片的產品看起來好像是一個獨立的系統。
      但其實背後已經有很多你所沒看到的系統整合工作在裡面。
      就像我文中最後所貼出的那張量產產線小姐操作的驗證平台
      一樣。
      更強大的單晶片系統,不只是讓你寫一個應用產品系統而已,
      而是讓你有更多周邊連結擴充功能,來協助你在系統開發上、
      或你的產品在系統應用市場上,有更豐富、有方便的
      使用環境與條件....沒有系統整合去創造出更平易近人的
      系統產品,再好的單一領域的技術也是沒有多大市場價值的。
      這是早從蘋果手機出現後,所創造出的新世代產品概念。
      未來再加入AI 之後,那就又是另一階段的應用市場了。

      刪除