發表文章
老是講經營或人生道理也沒啥吸睛的，每個人所遇到的或所能選擇的無奈，
也不是我們外人所能支配的，我還是來講一些技術上的經驗與分享。
關於這個題目應該還是可以寫一點東西的啦。你說弄個 USB 、數位CDI 點火或是
弄個無刷馬達控制這類單項技術分享，也沒多大意義，現在滿街都是AI 輔助設計，
只要你有心，有錢(沒生活壓力)又有閒，你愛怎麼賣弄技術，也沒人能說甚麼的。
但只要從單項技術走向產品的技術整合(這個才能真正變現換收入的啦)。你就得
要有一套能協助你完善整個系統整合處理能力的平台。而這個我們都俗稱為嵌入式
作業系統。先不管它的系統平台有多大、多複雜？就是一個你所需要的平台。
以前我們的單晶片系統也沒多複雜，所以大家就一路往下寫程式，哪管這麼多啊。
像我之前分享的那個 Bar 台逆向工程系列 中的程式：
程式一開始就把幾個主要的中斷定義完，然後就直接進 Main Loop。有甚麼
額外的功能需求，就直接在 Main loo 給他搞定，反正網路上也是一堆類似的
開箱文，不管你的MCU 效能有多強，就給他用力寫下去，然後就收工等著
別人來按讚，但很可惜的是：這些東西是賣硬體或模組廠商在做的生意模式。
對你人生要完善整個產品系統開發經驗的累積是幫助不大的啦。
你要學真正產品的系統開發，就得要有一定的系統平台架設與維護的能力。
以前你可能覺得八位元MCU 資源有限，也好像不怎麼需要這種平台玩意兒。
但你沒經過這些系統平台歷練，你未來怎麼應付日益複雜的MCU 平台呢？
就以我自己來說：我之前五年來，也好不容易從傳統八位元的 8051 轉換成
32 位元的 ARM，但一時間也是把32 位元的MCU 當作比較強大的八位元在用。
就是 stm32 入門款：STM32F103。
但你也不能怪老闆，因為可能它的產品需求可能用這樣子的MCU 就夠了，
你公司產品的技術開發有其天花板門檻，就算你想進修升級也沒啥機會啊，
久了也就有點"厭世"了。幸好我去年老闆"終於用一筆錢"把我資遣了，
我就又可以海闊天空的任我翱翔了。
結果短短不到一年之間：我就因為產品開發需求一路的從：STM32F4：
再到 STM32H7：
也只能說：市場訊息萬變啊。有時候真的也由不得你所能左右的啦。
以前我說過：你想學甚麼單晶片MCU 平台，怎樣的學習環境與平台最好？
就是讓市場需求推著你往前走就對了。又有錢賺，又可以學習新知識技術，
不至於落後被淘汰的風險。所以我才不幹那一種，整天在那邊十年磨一劍，
搞了老半天，結果你的變現營收的主要機會就只剩下"開班授課"...現在可能
連想賣個開發平台硬體都很難了。更何況現在等你去買書上課回來就可以
馬上上手嗎？你有真的學到整個系統平台的整合能力嗎？
以上述的TFT LCD 顯示功能平台來說：我就遇到客人跟我說，為什麼別人的
平台光只要加個按鈕或簡單的控制個周邊模組時，螢幕就黑屏，甚至就直接
死機了？是啊，現在產品系統需求越來越複雜，你怎麼維護系統平台呢？
簡單一個USB 或無刷馬達控制，就像我剛剛說的：那就是一個模組功能啊，
大家只要寫個 Main Loop ，其他啥功能都沒有，誰不會？原廠或賣你硬體
模組廠商隨硬體附個範例程式，都沒問題啊。
但你這樣子就算學會了系統開發了嗎？這個你可以去問付你薪水的老闆，
看他同不同意你這個觀點？
----
好，我們現在就來說說所謂系統開發平台：嵌入式系統平台。
其實從我以前在離開第一份工作(機械國防役)，真正進入電子園區業界開始
寫韌體時，我就把那個引擎電子控制裡那套分時多工系統給帶出來，也一直
沿用到USB 掃描器SOC、MP3 SOC 及數位CDI 點火系統....這些都是八位元
8051 平台，其中前兩個：USB SOC 及數位CDI 點火系統內的程式碼空間都
只有區區 8 KBytes，記憶體容量也都沒有超過 256 Bytes....肯定會有人跟你說：
很難吧。這的確是一種挑戰...但那時候，人家還是很努力想完成這種挑戰，
譬如在 8051 平台上最早的 uC-OS 。但還是弄得很複雜，所謂的嵌入式OS：
給我們使用者最大的挑戰就是：使用開發上與系統平台維護不能太複雜。
要不然還要自己下去維護，真的太辛苦了啦。
但問題來了：現在MCU 功能越來越強大，程式空間與記憶體容量也一直
在增加，所以要架一個嵌入式系統平台已經是輕而易舉了，最主要還是
系統應用市場需求。你總不能要一個強大的ARM M7 拿來寫個 BAR 台吧？
所以現在就有各種嵌入式OS 可以供你挑選評估使用。
不過，也是因為系統應用市場區隔發展，也漸漸地讓一些知名的嵌入式OS
在不同應用領域裡，走出屬於他們自己的亮點。
譬如：像在應用系統裡，需要即時快速反應的，譬如無刷馬達控制系統或
無人機操控系統的 ChibiOS；像一般普羅大眾使用的 FreeRTOS...等。
這些還是要視你真正系統應用的需求，當然也要考慮到你自己本身對於這套
嵌入式OS 的上手熟練度與維護能力。畢竟這些都不是你自己發展的平台。
我後來碰到一個也不算是笑話的笑話。就是因為現在許多系統應用越來越
複雜所以有些IC 設計公司就會針對一些常見的系統平台開發出專屬的SOC
解決方案。可能這些IC 設計公司裡，人才濟濟，資源也豐沛...所以在他們
的SOC 解決方案裡，直接埋了一套 Linux 作業系統，這的確是一個非常
強大的作業系統，也絕對可以因應許多系統開發平台上的各種奇奇怪怪
未來需求。但問題來了：這套系統不是外面公司或系統設計屋所能承受的。
那你說：萬一市場客戶有特別系統開發需求的話，那你原廠願意在投資源
幫小眾市場修改嗎？--- 這種結果就有點大而不當了。
你當然可以學個 Linux，人家都跟你說：這套系統很強大，也是開放源碼
的平台...你有多少機會可以找到適當的平台使用？
每一種嵌入式OS 都有其特殊應用市場特色，人家可以在競爭激烈的市場
脫穎而出建立口碑的，也都具有一定的代表指標性。就看每個人的需求：
這一點的確就是當你在學所謂 USB 或無刷馬達控制系統時，所必須
學習建立的系統開發資歷的。
時代環境不同了，拿單晶片寫控制系統開發，已經很難用以前那一種
我常說的：用十根手指頭寫程式的方式。隨著時代與控制系統複雜度的
演變，你就得要慢慢的建立一套屬於自己所能掌握的系統平台。
這絕對是你在未來系統開發技術發展職涯所必備的能力。
---
要不要後續以實作方式，貼文說明？再說吧。
因為現在AI 協作開發程式真的太強大了啦。舉例寫個嵌入式作業系統，
真的不難了。至於哪個控制系統應用平台，要用哪個作業系統？
我想還是靠每個人的需求判斷吧。有機會再慢慢聊吧。
Hi,
回覆刪除STM32H7 這系列效能蠻強的，有單核心 Cortex-M7，也有雙核心 Cortex-M7 + Cortex-M4 的型號。
實際使用上要稍微注意一下 Cache，尤其是有用到 DMA，或雙核心共用 Memory 的情況。如果 Cache 一致性沒有處理好，有時候會遇到一些看起來很奇怪、也不太好查的問題。
如果是開發初期或 Debug 階段，也可以先在 CubeMX 把 D-Cache Disable，先把問題單純化，等功能確認穩定後，再看效能需求決定要不要打開。
RTOS 的部分，我自己比較傾向用事件驅動（event-driven）的方式來設計，按照功能和責任把 Task 切開。
Task 跟 Task 之間的資料或事件，盡量透過 IPC，例如 Queue、Mailbox 來傳遞，減少彼此直接相依。這樣各 Task 的責任會比較清楚，之後要維護或擴充也會比較容易。
以上是一些實際應用上的想法，提供參考。
Tom
謝謝你的經驗分享。
刪除H7 核心都可以跑到 480MHz 了，使用Cache 架構是必然的啦。
幸好現在真的有AI 可以輔助開發與Debug，只要我們有一些
MCU 或處理器基本原理架構概念，基本上都可以很快抓到訣竅的。
更何況我說：只要有市場、系統產品需求，你的學習與導入時間
就會跑很快了啦。根本也沒時間讓你在那邊耗啊。
RTOS 也是一樣的，只要你有一定的系統整合開發經驗，
你就會懂那些RTOS 基本上在玩甚麼？用幾個基本應用
跑一下流程(譬如GPIO或資料傳輸等等)。也就可以上手了。
文中所提的 ChibiOS 或FreeRTOS (uC-OS也是)也都算
業界很成熟的RTOS 了，在處理這些訊息量的交換也都有
一定的強健穩定性。
所以我才說：現在MCU 效能一直提升，你想不用RTOS
都很難了。既然都已經是系統開發整合老手了，
說都不用也說不過去吧。
若只是弄幾個模組或單一個USB 、無刷馬達控制等的開箱文
那都已經沒啥好玩或創意的東西了。
能玩玩整合一些RTOS 進真正的產品系統開發，
那才是真正的技術整合開發者啊。
PS： AI 分析整理：
在開發開源無刷馬達（BLDC）控制系統時，VESC 和 ODrive 為了確保通訊、多工管理與馬達保護機制的即時性，分別採用了不同的實時操作系統（RTOS）：
*
* VESC (Vedder Electronic Speed Controller)：
主要使用的是 ChibiOS/RT。
* 特點： [ChibiOS](https://github.com/topics/chibios?o=desc&s=updated) 是一款專為微控制器（主要為 STM32 系列）設計的高效能、輕量級 RTOS。它提供了極佳的硬體抽象層（HAL）和超低的執行緒切換延遲，非常適合 VESC 這種需要高頻率進行 FOC（磁場定向控制）及馬達物理特性計算的動力系統。此外，VESC 近期推出的周邊硬體（如 VESC Express 擴充板）在 ESP32 晶片上也開始結合使用 FreeRTOS。 [1, 2, 3, 4, 5, 6]
* ODrive：
主要使用的是 FreeRTOS。
* 特點： [FreeRTOS](https://github.com/odriverobotics/ODrive/issues/751) 是目前嵌入式領域市佔率最高且極為通用的開源 RTOS。ODrive 利用 FreeRTOS 進行多工設計，將馬達控制的通訊協定（USB/CAN/UART）、編碼器數據採集、PID 位置/速度環計算，以及安全監控（過溫、過壓保護）分配到不同的即時任務（Tasks）中執行。 [7, 8, 9, 10]
*
需要特別注意的是，無論是 VESC 還是 ODrive，核心的 FOC（磁場定向控制）電流環與 PWM 中斷服務常式（ISR），通常都是直接掛在硬體的高優先權中斷（Bare-metal Interrupt）中執行，以確保達到最高頻率（通常為 20kHz - 40kHz）與零抖動的硬即時控制。而 RTOS 主要是用來管理通訊、上位機指令解析和低頻率的狀態監控。 [8, 11]
如果您正準備進行無刷馬達控制系統的開發，可以告訴我：
*
* 您預計使用的微控制器（MCU）型號是哪一款（例如 STM32、ESP32 或是 TI C2000）？
* 您的應用場景更偏向於 機器人/伺服高精度定位（類似 ODrive） 還是 載具/滑板等大動力驅動（類似 VESC）？
*
我可以為您評估最適合的軟硬體架構與 RTOS 搭配建議。
[1] [https://github.com](https://github.com/topics/chibios?o=desc&s=updated)
[2] [https://github.com](https://github.com/vedderb/bldc/issues/181)
[3] [https://github.com](https://github.com/greiman/ChRt/issues/12)
[4] [https://chamberplus.blogspot.com](http://chamberplus.blogspot.com/2024/06/blog-post.html)
[5] [https://github.com](https://github.com/svenssonjoel/lispBM)
[6] [https://www.lispbm.com](https://www.lispbm.com/getting-started.html)
[7] [https://blog.csdn.net](https://blog.csdn.net/weixin_31476015/article/details/163456173)
[8] [https://blog.csdn.net](https://blog.csdn.net/gitblog_00469/article/details/157155242)
[9] [https://github.com](https://github.com/odriverobotics/ODrive/issues/751)
[10] [https://github.com](https://github.com/zhbi98/MotorKit)
[11] [https://zhuanlan.zhihu.com](https://zhuanlan.zhihu.com/p/430467251)
MCU用的核心我寫了十多年了。從前景(中斷)/背景系統，一路改善中斷管理，然後學了uCOS-II，再轉用FreeRTOS。再來於STM32上看到timer+DMA，就在想這個幾乎取代RTOS，因為可以定時固定將資料送去指定的硬體上，rtos只是在管理多人同時寫作。
回覆刪除然後MCU開始被MPU取代，然後我就遇到嚴重退化的MCU=NFC應用場合，又退到只剩8KB RAM，執行時間極短，因為感應電力可以執行的時間很短，為了這種場合，我才再"寫"(實為重新拼裝)coroutine型類OS寫法。
現在，主要是找AI能寫的核心，freeRTOS沒有問題，我的Coroutine系統AI也看得懂。
再來，我認為AI會直接生成WASM放進MCU跑，因為WASM本來就是browser上可以用的，AI熟到不行。還可以先在Browser先生成一個模擬的出來。未來還能使用的電腦語言不多了，人類大部分都是用口語叫電腦做事。ASM又不可能消失，所以只會剩下WASM
我們以前那一種從單純八位元MCU ，寫寫一些簡單應用，
刪除那時候挑戰的是：周邊支援介面或模組有限...只要把這些東西
以程式搞定就好，就可以做一些系統應用產品。
所以像我寫寫USB 模組，或搞一些六步方波，乃至於PWM 來
控制馬達，就已經不得了了。
但後來MCU 整合的硬體周邊模組外加DMA 等硬體加速機制，
結果就讓我們原來那一套玩法就不稀奇了。
反而現在這些硬體功能能加就加給你了，就開始考驗你系統
整合能力，所以就開始孕育而生許多各家RTOS 的架構：
有些標榜架構輕薄短小，有些強調穩健擴充性強...
玩的是記憶體、堆疊、時程、Tasking或訊息量管理...
就看每個人、每個系統產品所需要，或所要求的目標來選擇
適當的RTOS。這比起傳統寫單晶片MCU 更有挑戰性、也更好玩。
你今天看別人玩玩那些甚麼 USB、CAN Bus 、NFC 、Ethernet，
乃至於影像處理、無刷馬達控制、工業控制等等系統應用。
這些真的也沒什大不了技術亮點的，最終你還是會碰到這些
RTOS 在系統開發配置問題。
現在你真正需要的職場謀生技能，已經不是我們那個時代的硬體
架構或甚麼周邊元件或電路控制的...更需要的是在這些硬體背後
所能掌握、更重要的核心作業系統處理能力。
就像我們現在所看到的各個AI 平台或Agent 所創造的價值。
至少以我這個年紀，所經歷的經驗告訴我的。我是非常認同的。
剛才有人寄了他要的AI程式給我，我有點看不下去。然後發現同一個需求，AI寫給他是他要的，寫給我是我要的，但二者寫出來的功能一樣，名字差很多，變成我看不懂他那段程式。同一套程式語言都會這樣了。以前人寫的程式是給別人看的。而AI是寫給特定使用者看的。現在造輪子不用錢，所以每個人開的車輪全都是特製品，完全沒有交換的可能。但是...有需求交換嗎?
回覆刪除這個問題，不要說別請AI 寫給他的程式，你看不懂。
刪除就連同一個問題，用同一套AI 平台，不同的時間用不同
方式提問或要求規格略有不同出入(那怕措辭差那麼一點點)，
所產生的程式碼也會大相逕庭啊。
往好處想：代表AI 非常聰明的在不同環境與思考模式下
因應你的需求都可以滿足你當下的需求。
但這些是你最終所要的程式樣子嗎？
或許你可以一直跟他耗下去，弄到你滿意為止....
最後你再回頭看看：他給你的程式邏輯是你給他的？
還是他一直在修正你的想法與邏輯？
可以回到原來的初衷想法嗎？
結果可能就如你所說的：
"現在造輪子不用錢，所以每個人開的車輪全都是特製品，
完全沒有交換的可能。但是...有需求交換嗎?"
所以有人現在開始擔心AI 失控問題，不是沒道理的啦。
我們自己在跟AI 互動中，我們也常常被它所左右我們的
邏輯思考啊。好玩吧~
我弄清楚描述出來的程式表達的視角不同點。我的朋友都是喜歡使用MCU內部設定暫存器名稱，他的程式本來就不好讀，他非常討厭換MCU，對細節控制很在乎。所以程式看過去就是暫存器做什麼又設了什麼。簡言之，完全工程師視角。
刪除我的程式為了維護，我的很多名字都直接對應電路圖，或是使用者看到的功能，所以我大部分能用HAL函式就直接套用，這樣換MCU以及電路修改時都好維護。
我看他的程式很累，因為我還要去查暫存器做什麼。他看我的程式也一頭霧水，這功能為何要套來套去(因為他追去HAL內)。AI只是放大了問題。
每個人寫程式有他自己的風格，但像他這樣子怎麼活下來的？
刪除我們也不方便表達甚麼？但這樣子，你要拿他的程式去讓
AI 承接下來也沒問題啊：因為AI 就是你給餵甚麼？它就做甚麼。
早期我剛接STM32 時，我一開始也是用 STD 標準函數庫，
覺得它就比較接近我們以前學 8051 或其他單晶片的使用習慣...
但當我後來開始要維護系統或升級功能時，
我就發現這其中的問題了....別人會跟你說：HAL 效能沒有
STD 好，STD 效能也沒有寄存器版好...
我真的搞不懂所謂的效能好？
是指程式執行效能？還是程式維護效能呢？
這只有一種可能：那就是你朋友的寫的系統程式(或系統產品)
種類太少了，他們公司可能就是我文中所說的：一顆MCU 做完，
做滿公司的所有產品...所以當然也就不喜歡換MCU 啊。
之前我也喜歡這種模式啊，哪個工程師不喜歡啊，一招半式
闖天下啊。光靠這一兩顆MCU 可以存活一輩子，有甚麼不好的？
不長進，沒進步又怎樣？只要老闆可以賺錢，也可以給你年年
加薪，大把大把的分紅有甚麼不好的？
真的有這種好康的公司給大家多多介紹一下啊。
喔~據了解:我之前那些多核心MCU 公司，從我離開也快二十年了，
人家也就一直只有那個架構的MCU ....產品線也還是那一項而已，
也沒人說不行啊。只是每個工程師所想追求的不一樣吧。
我也突然想起中秋連假前一則新聞：
"營運虧損難平！鑫創科技將大量解僱 11／23起分批辦理員工資遣"
https://www.ctee.com.tw/news/20260923702035-430502
這家公司是我近三十年前從USB 開始切入玩隨身碟控制IC 時，
多知名的IC 設計公司啊。那時我們私底下都俗稱它 3S 公司(LOGO)。
工程師怎麼辦？你說一家讓你玩這麼久的公司，有甚麼不好的？
資遣費拿一拿就可以直接去勞保局辦退休了啦。
也不用玩甚麼新MCU？也不用管甚麼 32 bits MCU，更不用管
甚麼 RTOS 系統平台，甚至甚麼AI ？都與他無關啊。
也更不會因AI 放大問題啊....
這個就是工程師人生啊。我也看了不少了啦，你又能說甚麼？
或許就人家常說的一句話：
當他自己不覺得尷尬，尷尬的就是別人了囉。
AI解釋：
這是一句廣為流傳的網路流行語，完整說法是「只要你不尷尬，尷尬的就是別人」。 [1, 2]
## 意思與用法
* 核心概念：當你在社交場合或日常生活中發生出糗、失誤、或是做出不符合常理的行為時，只要你自己保持神態自若、毫不心虛，覺得難為情反而是旁邊看的人。 [1, 3]
* 心理機制：這是一種強大的心態防禦機制或厚臉皮幽默。尷尬其實是一種主觀情緒；當事人若無其事，旁人就會懷疑是不是自己太大驚小怪，進而把「尷尬」的氣氛轉嫁出去。 [3]
如果你想聊聊這句話，是遇到了什麼有趣的糗事或尷尬的社交場景嗎？我可以陪你笑一笑，或幫你想想怎麼應對！
[1] [https://buddhistcompassion.org](https://buddhistcompassion.org/content/%E5%8F%AA%E8%A6%81%E4%BD%A0%E4%B8%8D%E5%B0%B7%E5%B0%AC%EF%BC%8C%E4%BD%A0%E5%B0%B1%E4%B8%8D%E5%B0%B7%E5%B0%AC)
[2] [https://blog.udn.com](https://blog.udn.com/eastolga/162758725)
[3] [https://baike.baidu.com](https://baike.baidu.com/item/%E5%8F%AA%E8%A6%81%E6%88%91%E4%B8%8D%E5%B0%B4%E5%B0%AC%EF%BC%8C%E5%B0%B4%E5%B0%AC%E7%9A%84%E5%B0%B1%E6%98%AF%E5%88%AB%E4%BA%BA/57340676)
讀者來信轉貼：
回覆刪除我個人覺得現在工程師可以與時俱進的跟上技術潮流真的不錯。
也很厲害，我的那一套東西也只能扮演一個拋磚引玉的功能而已。
我們也已經老了啦。這點我自己是有自知之明的啦。
大家還願意來我這部落格走走看看，我都心存感激了。
我們傳統那一套光靠基本的MCU 架構或簡單的周邊元件，
乃至於那些基礎系統應用：USB、引擎點火控制或無刷馬達控制，
其實已經在都成了MCU的基礎應用了，玩玩這些東西也只不過是
班門弄斧而已。要真正現在複雜的系統應用產品都還差遠了。
引擎控制？人家都已經是無人自駕車了啦。
無刷馬達控制？人家現在都已經是無線上網、遠端連線控制或所謂
的智慧家電了。
要整合這些東西，已經不是光靠你只會寫寫基礎MCU 就可以了。
像我這篇文章提到的 嵌入式RTOS 都是基礎必要的條件了。
而要完成所謂的這些嵌入式RTOS，你所要建立的也不光只是
嵌入式RTOS 本身這個東西而已，而是他所延伸的所有
驗證工具或系統整合管理平台等等。
所以我也好高興有讀者也願意一起分享他自己的經驗。
大家都可以從中一起學習參考。
謝謝大家這麼捧場的加入與分享。
以下就是讀者經驗分享：
=====
看到留言裡講到「AI 每次寫出來的程式都可能不一樣」這件事，我前陣子其實也有碰到類似的情況。
我的想法比較不是去規定程式一定要怎麼寫，而是反過來先把系統裡誰負責什麼、彼此怎麼溝通，以及 State、Interface、Ownership、Error Handling、Verification 這些東西先定清楚。
起初我是從 Host-Device Control Framework 開始做，後來又覺得不應該只侷限在 PC 對 MCU，所以再往上拉了一層，弄了一個 SCAF（System Control Architecture Framework）。
我自己把它想得比較像是「架構／框架的憲法」或施工準則。
也就是底下實際怎麼施工，可以有很多種作法，但是一些基本的責任邊界、介面、狀態、錯誤處理、驗證方式，大家還是遵守同一套規則。
這些東西雖然人也看得懂，不過我當時其實有一個很大的目的，是希望它也能直接「給 AI 看」。
也就是把架構、規則、責任邊界、驗證方式等資訊留在 Repository 裡。之後即使單獨開一個全新的 AI 聊天室，把 GitHub Repository 或 ZIP 丟進去，請 AI 先完整閱讀、理解，再檢查第三方授權／版權標示，以及程式裡是否有明顯的惡意或攻擊性內容，它還是有足夠的上下文可以重新接手，而不是一定要依賴原來那一長串聊天紀錄。
Coding Rules 這部分我也有另外整理。
C# PC App 這邊主要參考 Microsoft 的 C# Coding Conventions、Framework Design Guidelines、async programming，以及 .NET code style / code analysis 等官方指引，再把 Architecture、Concurrency、UI Boundary、Testing 等規則加進去。
Embedded C 這邊則是以 MISRA C:2023 當作底層的 language-safety reference，再另外補上比較適合實際 Embedded System 的規則，例如 Memory、Arithmetic、ISR、State Machine、RTOS、Protocol、Error Handling 等。
當然這不代表寫出來就可以直接宣稱「MISRA compliant」。真的要做到正式 compliance，還是需要 Static Analysis、Deviation Record、Compiler Configuration、Code Assessment、Review Evidence 等完整證據。
我的目的其實很單純：就算 Code 是 AI 寫的，至少不要每次都從一張白紙隨便長，而是有一套基本工程規則可以約束它，讓產出的東西至少維持一定程度的可讀性、可測試性與可維護性。
未來底下的 Code 就算換人寫、換 AI 寫、換不同品牌的 AI 寫，甚至換不同程式語言，我覺得都沒有太大關係。
只要最後還是遵守同一套 Architecture / Contract 就好。
不然現在 AI 寫 Code 的成本越來越低，每個人很快都可以弄出自己的一套東西，最後真正麻煩的反而可能變成：
每一套都可以跑，但是彼此接不起來，也不好維護。
當然這些東西也不是我一開始就想得這麼完整，而是跟 AI 來回討論、修改數十次，再配合實際 PoC 去驗證，慢慢才收斂成現在這個樣子。
當時我也另外做了一套很單純的 Host-Device PoC 來試這件事情，就是一個 Windows PC App 加上一塊 STM32F446RE 開發板。
PC App 負責 Serial 連線、Command / Response、Telemetry 接收與顯示，也有 Fake Device，可以在沒有實體硬體時先做測試。
STM32 FW 則是 Bare-metal、event-driven 的方式，處理 Communication Protocol、Command State、資料串流，再產生一些簡單的模擬波形資料送回 PC。
目的不是要把功能做得多豐富，而是想看看：
如果架構、需求與驗收條件由我來定，實際 PC Software 與 MCU Firmware 都交給 AI 開發，最後到底可以走到什麼程度？
那時 PC App 和 STM32 FW 的程式我基本上都沒有親手下去寫，我比較像是在扮演 User / QA 的角色。
實際操作、測試，有問題就把現象與測試結果回饋給 AI，再讓它分析、修改、重新驗證。
後來我又把這個想法往前推了一點，加入類似 closed-loop verification 的做法。
概念大概是：
AI 修改 Code
→ Build
→ Self Test / Unit Test / Regression Test
→ 必要時跑實機或 UI / E2E Test
→ 收集 Log、Screenshot、測試結果等 Evidence
→ 發現 FAIL 就回給 AI 分析與修改
→ 再重新 Build / Test
→ 一直跑到 PASS。
之前也曾經把這套流程包成類似 verify.bat 的一鍵驗證入口，讓測試結果與 Evidence 可以直接打包回來，再交給 AI 分析。
這樣就比較不是「AI 說它改好了，我就相信」，而是：
Code → Verify → Evidence → Fix → Re-verify
形成一個閉環。
我自己認為，以後 AI-assisted development 越來越普遍之後，工程師工作的比重可能也會慢慢改變。
單純 Coding 的比重可能下降，但是前面的規格確認、System / Function Analysis，以及後面的 Test & Verification 反而會變重。
尤其是 Verification。
因為最後產品真的出了問題，要對規格、設計與驗證結果負責的，終究還是人類工程師，不是 AI。
某種程度上，這些東西也算是我自己拿來做的一些 AI-assisted development 實驗。
目前停工一陣子了 😆，之後如果又碰到適合的實際案例，再拿回來繼續磨。
有興趣的話可以隨便看看：
SCAF：
https://github.com/jkman357/System-Control-Architecture-Framework
Host-Device PoC System：
https://github.com/jkman357/host-device-control-poc-system
PC App：
https://github.com/jkman357/host-device-control-poc-pc-app
STM32F446RE Firmware：
https://github.com/jkman357/host-device-control-poc-stm32f446re-fw
=====
喔~我順便借花獻佛一下，讀者所提供的經驗分享，
回覆刪除可以先看看的他的初衷想法：
https://github.com/jkman357/host-device-control-overview
我是覺得會有這些想法的，都是真的有經歷產品系統整合開發的人
才會有這般的體會與想法。
以前我剛入職時，我覺得我會寫寫MCU 程式就很厲害了。
後來發現：我公司裡的那些主管、前輩們，真正厲害的是
會想到這些該如建立開發環境，然後再把工作給分配下去。
所以那些所謂的專家或老師，如果都只是拿個基礎一個應用，
然後就貼著 Main Loop ，證明這個基礎應用運作得多漂亮？
就講得天花亂墜的厲害...大家就看看、聽聽就好。
還是我那句老話："不是你最厲害或別人都是笨蛋，
只是人家要不要理你而已罷了。"
稍微看了下，這位仁兄真的是最辛苦，而且很有經驗的的系統整合RD，就不是單純的FW 或軟工。整篇看完，彷彿工作生涯發生的事又在眼前走跑馬燈(不是人掛掉前看到的那種)
回覆刪除如果未來，這套準則可以由AI來執行的話，照現在AI進化的速度，那也可以提早退休了，因為我己經失業了XD
回到主題，嵌入式OS其實我用得很少，什麼你聽過的我在工作上都沒用過，幾乎都是純non os，第一份工作用的嵌入式OS就是timer+Scheduling，後來工作經手過的系統就是Main Loop在那邊跑.....你說這不能做產品嗎？人家留下來的CODE就這樣，你想從頭再來搞OS？花費的時間和金錢不說，有沒有經過內部測試和客戶驗證？
你想用FreeRTOS、uC-OS，問題是請來的人能會寫C就不錯了，有的請來還要上課，
拿著一本「The C Programming Language 」在那邊教...為什麼要這麼做？有經驗的人價位就是貴啊，又不像現在有AI，有問題？上網查！
我的工作生涯，簡單來說就是當維護(或是俗稱救火隊)，後來都是在做printer比較多(但不能說是哪種printer，真的會被認出來XD)，一般手上有機器，有CODE有人給你問己經是很理想的狀況了。有時機器沒到只有CODE，期限就擺在哪怎麼辦，
就只好看一份十幾年前留下的CODE瞎猜，搞出個BIN檔給對方燒錄測試，完成功能就是過了
一般來說printer只有UART走最簡單的指令集，系統就真的只走Main Loop；
但複雜的printer，基礎的馬達，印字頭控制，再加上USB、WIFI、Ethernet、藍芽等等，
只有Main Loop玩得起嗎？
但我碰到的狀況就是這樣，但寫的人要很有觀念，要習慣別人風格，內部機器搞壞還好，真的把版本送出去，送到客戶或量產才發現有問題怎麼辦？
重現BUG，然後這種事多了後，才開始有測試流程，什麼自動測試不存在的，反正請的人這麼便宜就手動測吧。開發只有一二個人時，溝通與整合問題都很少，人一多時，每個人各改各的，回頭要看改了什麼，就出動WinMerge一個一個檔案看吧(雖然那時本地端SVN己經很成熟了)，雖然對上面各位前輩來說很神奇，這樣平常要怎麼工作？但還是有公司是這樣做產品的。
所以用不用OS，其實很多時候是人的問題......
說真的，不是說誰比較厲害。
刪除而是就像我說的：如果現在或往後都可以用一個 Main Loop
來做系統應用開發是很幸福的一件事。
但事實上卻是越來越難啊，所以現在的系統應用工程師就
很辛苦啊，很難像以前那樣子只單純做個韌體工程師啊，
(做韌體工程師還不光只是寫寫單晶片程式碼而已，偶而
還得要懂一點硬體，才能幫忙釐清韌體所控制的周邊...)
這下還要涉入一點軟體世界裡的作業系統概念，能不這樣子嗎？
我算有早一點認知的人：所以早早就在PC 平台上用C 語言寫寫
Multi-Thread 東西(那也是因為USB 傳輸需要所逼啊！)
不然怎麼辦？現在有很多應用的Open Source， 動不動就給你塞個
RTOS 給你啊。你想縮短開發時程，就得站在別人肩膀上看天下啊。
也就是我文章裡提到的：人家就在他的SOC 解決方案裡直接個
linux 給你啊。就像你自己講的：就簡單做個印表機：基礎馬達控制，
又要接收列印資料，又得做記憶體緩衝管理，你又要USB、WIFI 、
Ethernet 及藍芽的...不是 main loop 一路往下寫不行，
而是搞到最後：整個Main Loop 就像貼狗皮膏藥一樣，既臃腫又
雜亂不堪。誰最後接手維護Code ？就誰倒楣。
所以我才一直說：如果寫韌體就只有寫個Main Loop 單一馬達控制，
再讓你閃幾顆LED 或收個一兩顆按鍵...這有甚麼難的或挑戰的？
貼幾張無刷馬達控制訊號的示波器圖，這又算甚麼？
如果搞系統應用這麼簡單，人人都可以是專家、老師了啦。
所以啦，為什麼那些人總覺得開箱文弄個Main Loop 程式，
跑跑簡單的模組，貼幾張示波器圖或幾張照片....覺得自己
天下無敵了？其實就如你所說的：都是他們自己本身的問題啊。
那為什麼這些人，這些老闆會這麼想？也只有你在公司裡
上班，然後你又有心斜槓的人，自然就會看到危機與自己的機會
在哪？
因為實際上未來的許多系統應用已經很難再回到我們那個
八位元單晶片的系統開發概念了啦。(main Loop 一路寫到底)
大家如果覺得你自己在單晶片系統應用開發上，只想搞個簡單
Main Loop 控制無刷馬達控制或簡單幾個介面控制，
你的未來競爭力會在哪？這才是我們要想的重點。
別人的函式庫有使用rtos的，我都是用freeRTOS去套。然後在IdleTask上再套上我自己的Coroutine系統。所以bare-metal的系統也可以跑得很正常。只是我在想其他人能不能看懂這個雙系統混合型程式。
刪除用甚麼RTOS ？或是你不想用RTOS 。
刪除像你所說的用的 Bare-metal 系統也可以。
只要這些系統程式找得到維護人員，別人也可以接手就好。
但我想表達的是：現在MCU 的架構與資源，都可以輕易的
架設一個 RTOS ，或是說：如果你沒有這些分時多工系統的
基礎概念。不是不行，而是真的有點浪費了。
以前我們都要花很多時間去搞USB、周邊硬體乃至於像
無刷馬達控制系統裡那些複雜的硬體周邊。現在人家
MCU 都可以幫你整合到可以輕易導入，就算不完整，
也都有提供範例程式供你參考，再沒有，網路上或AI
都可以輕易的幫你整理處理。所以這些技術門檻都
沒像以前那麼遙不可及了。
但現在這些MCU 希望你們應用系統設計開發者，能更著重在
更複雜或更進階的應用：譬如Wifi 物連網或雲端資料交換等。
為MCU 應用市場創造高階智慧應用。這樣子也才能彼此
教學相長推動產品或產業競爭力。
簡單來說：你說你只會寫寫傳統MCU 控制程式，現在你看
還有幾家MCU 想再跟你合作了？但如果說：你說拿他們家
MCU 可以實現連網，使用AI 雲端運算的...那肯定就是市場上的
技術亮點了啦。
我是老了，現在只能看得到，也未必做得到了。
但我相信這是一個趨勢，年輕人你是可以看得到也做得到的。
就看每個人給自己的期許或所能創造的機會在哪了。