發表文章
老是講經營或人生道理也沒啥吸睛的，每個人所遇到的或所能選擇的無奈，
也不是我們外人所能支配的，我還是來講一些技術上的經驗與分享。
關於這個題目應該還是可以寫一點東西的啦。你說弄個 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
剛才有人寄了他要的AI程式給我，我有點看不下去。然後發現同一個需求，AI寫給他是他要的，寫給我是我要的，但二者寫出來的功能一樣，名字差很多，變成我看不懂他那段程式。同一套程式語言都會這樣了。以前人寫的程式是給別人看的。而AI是寫給特定使用者看的。現在造輪子不用錢，所以每個人開的車輪全都是特製品，完全沒有交換的可能。但是...有需求交換嗎?
回覆刪除