老工程師的技術生活(四十七) --- 從生態系應用學習與成長經驗談

我本來是想整理一下關於 stm32 USB HID 的技術文章，因為我之前有

寫過一系列的STM32_USB_DIY Custom HID 。那是用傳統標準函數庫

寫的。但後來人家就已經全面不再採用 std 標準函數庫了，而採用了

HAL 方式，經這幾年下來整個該公司MCU 在系統應用端也完全建立了

相關族系的開發生態系(ecosystem)。我後來也全面改用 HAL 方式了。

但經由前幾篇貼文，大家都非常熱烈的討論關於 AI  輔助開發的議題之後。

我想若老是拿這類文章出來賣弄，也只不過是增加AI 搜尋的一項而已。

倒不如來寫寫不一樣的經驗分享吧。或許AI 比較不會涉及人類情感的

議題吧。(現在的 AI 啦，以後AI 發展會不會出現類似人類的情感描述

或表達？不知道 ...或許有一天也說不定吧。)

既然AI 也是透過不斷的機器學習與訓練來的，那我自己也來看一下自己的

系統應用的學習與成長吧。如此對比一下，讓大家也可以從中學習或看到一些

不同的故事與科技發展的軌跡吧。

以前我剛開始學單晶片(8051) 時，是從組合語言開始的，那是因為那時代也沒  

C 語言組譯器。後來就出現支持 8051 的C 組譯器了，但還是因為單晶片的周邊

資源很少，所以也不能像一般在電腦上用C  語言的隨心所欲....雖然用C 開發

系統，但還是有點綁手綁腳的。(雖然那時候，我也有寫一點PC 端 Visual C 了。

但也是技巧生疏啊)。所以像以下這樣子宣告都已經不錯了啦：

上圖中，就是我還在一直販售中數位 CDI 點火器的韌體程式碼。你說：這樣子

的小系統應用程式，用C 語言寫，可以寫出甚麼大架構或多複雜的邏輯啊？

包括要宣告一下比較複雜的資料結構的變數，都還得拿捏一下單晶片的記憶體

夠不夠你隨便用啊。所以對我這一種非科班出身的人來說：若純粹以學習成長的

軌跡來說：哪有機會進階到高級的程式語言技巧？這還反而限制了我在 PC 端

寫 Visual C 語言的習慣。所以那時我在PC 上用C 寫視窗應用程式，還是笨笨的

用傳統的 C， 還不是所謂的 C ++ 的方式，反正啊，東西會動就好，賣出去也沒

出甚麼大問題。

但慢慢隨著單晶片的資源成長與系統架構的複雜化之後，也就慢慢也被改變了：

尤其是在USB 的系統應用環境與條件中。更顯得明顯重要：因為USB 的基礎架構

是固定的，但隨著不同的 Class 的定義與使用，他就往上長出不同的上層應用方式，

所以那些MCU 原廠的工程師們就得要想出一套能涵蓋不同USB Class 應用層面的

程式語言架構的HAL 底層函數庫。

所以我們就可以看到同樣一顆 MCU 的USB 應用，在不同的USB Class  應用。

(一個是MSDC隨身碟，另一個是 HID)應用，就用一個資料結構的宣告方式

給簡單處理掉了。這樣子的處理方式真的給我們這些在系統應用開發者帶來

莫大的幫助。也可以幫他們自已把底層HAL 架出一層系統開發的保護層。

(以前我們在大公司要釋出程式碼給客戶時，最怕的就是沒有完善的架構定義，

結果，還讓客人不得不去亂改你的底層...造成系統混亂與難以維護，這樣子

你就知道為什麼像微軟或Andriod 慢慢也是如此做法了。)

其實這樣子的程式架構就非常適合發展出一個系統發展的生態系(ecosystem)。

記得：我會一直強調這個生態系的概念。

然後呢，只要善用這些資料結構的宣告，就會讓你的系統開發變得非常清晰明瞭了。

因為我們一般寫系統韌體時，就只想到趕快把老闆與長官要的東西，用貼狗皮膏藥

的方式，硬貼或硬湊的方式給趕出來，哪會想這麼多複雜的架構宣告與應用。

自然我們自己在自己的系統應用學習成長中，很難累積出屬於自己好的生態系。

這樣子的概念，在USB 的系統應用中特別顯得相得益彰。發揮到極致了。

也讓我因為常在這個生態系中開發USB 系統應用，也讓我有另一種耳目一新的

學習成長機會。相對來說：也再進一步的改變我在 PC 端撰寫程式的習慣了：

所以在PC 端的應用，也開始加入這些高階的程式語法，就連回到單晶片MCU 

的平台中，也是如此：

就愈用愈順手方便了。我只能說：這一切也都是因為需求創造的學習成長的機會，

也因為不斷的踏出原來的領域與環境，給自己創造一個不同的成長機會。

你說：如果我還停留在原來八位元的MCU 開發環境中，我可能還在用組合語言

在那邊慢慢地刻出每一個系統應用。譬如我還在那個多核心MCU 的那個窘迫的

資源條件下，我還能有多少技術成長空間，或許還可以一直領薪水餓不死啦...😂😅

當然啊，我們也會在這樣的應用環境條件下，不斷的學習成長...我說了：

只要有個案磨練的機會，你寫程式的技巧十年不成仙，也會成精啊。

這也沒甚麼好拿出來吹的...只怕你就是傻傻地沒目標機會的一直自嗨的寫。

這不就一大堆在社群媒體中，常常有人就拿個模組寫個開箱文，然後大家

就拼命地按讚、好棒棒喔~就是 Case by Case 的貼文賺按讚數，久了自然

連自己也都會被磨掉這些熱情啊。(因為就是寫程式，搞系統都只是原地踏步！)

----

當然，這樣子的學習成長經驗也告訴我說：系統應用開發也都會慢慢往這樣子

的生態系方式前進。你說你想研究每一項細節的底層？那你就去原廠幹工程師。

(我很慶幸我自己也在那環境待過好幾年了，可以完全體會那一種心態。)

包你每天可以竭盡心思的研究每一個環節，但如果你純粹想趕快的把終端應用

系統產品給弄出來換營收現金與獎金的話，你就順著這些生態系走就對了。

因為這已經是講求十倍速的時代了。況且大家都是這樣子玩了。

老闆找你來上班是做系統應用工程師的，不是請你來當研究員的。(同樣的道理：

你開公司是到底是開想趕快技術變現賺錢的？還是想開個技術研究院的？)

那些基礎理論的東西與技巧，對老闆或客人來說是沒有多大意義的啦，更不用說

人家哪來那麼多美國時間與耐心聽你在那邊做技術發表會啊？

(其實如果你真的有去稍微大一點公司上班過的話，你也應該也會很清楚：

在許多同事之間，如果你就三天兩頭老是拿這些技術的東西出來賣弄，你覺得

你在你的職場上，就會受到比較多的尊敬與推崇嗎？人緣比較好？😅😇😉)

以前我們在一棵MCU 周邊要接個 SRAM 、SDRAM或是一個LCD 螢幕，

我們都還要在周邊弄一大堆解碼或 Latch 電路，但現在不用了，在MCU 的

應用生態系裡都會提供相關的資源給你，所以啊~人家就會在這些生態系下，

譬如延伸出支持LCD 應用生態系的 emWin、TouchGFX 或 LVGL 的標準套件應用。

因為真的沒有人還有那麼多時間或資源可以好好的來研究這些東西的底層技術了。

只要主流市場有那些相關的系統應用需求， 他搭配的周邊的生態系就會出現。

以前你可能數位電路設計很厲害，現在這些數位邏輯電路就可能只剩下配角的

角色而已。當然也不會不見啦，我們現在偶而還是會拿出來用的。

---

再來講一個時下很熱門很夯的系統應用領域：人型機器人(Humanoid Robot)。

在這個系統應用領域裡，他們的運動關節都是採用電機伺服控制。

所以這樣的應用底層背後也當然有其支持的生態系因應而生啊：

最近朋友幫我在淘寶買了一本：(還有相關硬體套件)

這個就是這個生態系的主流。馬達電機控制應用領域很廣，

但不可能還要每一個工程師辛苦地去 K 電機基礎理論課程。所以自然就會孕育出

這些市場需求的生態系了：(ODrive 是個用 STM32F4 平台開源的電機控制項目)

我是覺得人家這套東西做得很完善，所以才吸引人家願意花時間幫他寫書、出書啊。

(只要把自己的核心技術做好做滿、根本無需還要自己去辛苦的推廣...大陸還一大堆

幫他出標準硬體平台，你想按部就班地拿來應用，都可以讓你輕鬆上手)

以下是書本內容章節：鉅細靡遺地交代所有軟硬體內容。

●第1章 探秘电机世界——转起来 1
1.1 直流电机 1
1.1.1 有刷直流电机 1
1.1.2 无刷直流电机 2
1.2 交流电机 3
1.2.1 异步电机 3
1.2.2 永磁同步电机 4
1.3 其他常用电机 4
1.3.1 步进电机 4
1.3.2 舵机 5
1.4 磁场定向控制 6
1.4.1 第一步：获取电流与位置 6
1.4.2 第二步：坐标变换 6
1.4.3 第三步：PID运算 7
1.4.4 第四步：Park逆变换 7
1.4.5 第五步：SVPWM/SPWM 7
1.4.6 总结 8
第2章 ODrive实操——黑科技 10
2.1 探秘ODrive项目 10
2.2 选购ODrive硬件 11
2.2.1 电机 11
2.2.2 编码器 13
2.2.3 刹车电阻 13
2.2.4 电源 13
2.2.5 调试器 14
2.3 实操ODrive电机 15
2.3.1 安装上位机 15
2.3.2 初始化上位机 16
2.3.3 设置电机 16
2.3.4 设置编码器 17
2.3.5 设置刹车电阻 18
2.3.6 设置电机控制环增益参数 18
2.3.7 启动电机 19
2.3.8 自动闭环 19
2.3.9 操作状态机 20
2.3.10 切换控制模式 23
2.3.11 设定输入模式 24
第3章 ODrive开发环境——搞起来 26
3.1 Linux环境折腾指南 26
3.1.1 工具：交叉工具链 26
3.1.2 工具：GDB 27
3.1.3 工具：OpenOCD 28
3.1.4 工具：VSCode 28
3.1.5 工具：odrivetool 28
3.1.6 实操： 代码 29
3.1.7 实操：编译 29
3.1.8 实操：刷机 30
3.1.9 实操：调试 31
3.2 Windows环境折腾指南 31
3.2.1 工具：Python＆Pip 31
3.2.2 工具：odrivetool 32
3.2.3 工具：交叉工具链 32
3.2.4 工具：GDB 34
3.2.5 工具：OpenOCD 34
3.2.6 工具：VSCode 35
3.2.7 工具：Git 35
3.2.8 实操： 代码 35
3.2.9 实操：编译 35
3.2.10 实操：刷机 37
3.2.11 实操：调试 38
3.2.12 Windows常见问题 38
3.3 ODrive构建系统重构 39
第4章 ODrive电路大揭秘 57
4.1 探秘原理图 57
4.1.1 第一张原理图 57
4.1.2 第二张原理图 59
4.1.3 第三张原理图 59
4.1.4 第四张原理图 59
4.2 拆解模块电路 63
4.2.1 主控芯片 63
4.2.2 调试接口 65
4.2.3 USB通信电路 66
4.2.4 CAN总线 66
4.2.5 CAN终端电阻与启动模式 67
4.2.6 电源采样 68
4.2.7 GPIO 69
4.2.8 编码器 70
4.2.9 电源 71
4.2.10 0号电机驱动模块 73
4.2.11 1号电机驱动模块 74
4.2.12 刹车电阻 76
4.3 系统模块框图 77
第5章 ODrive软件——初探宫殿 78
5.1 软件总体：骨架 78
5.1.1 main函数主线 79
5.1.2 极简框图 80
5.2 文件夹结构：抽丝剥茧 81
5.3 线程：分身术剖析 84
5.3.1 主线程main函数 84
5.3.2 UART通信线程 85
5.3.3 USB通信线程 86
5.3.4 CAN总线通信线程 86
5.3.5 ADC1采样线程 87
5.3.6 状态机线程 87
5.3.7 定时器8中断函数（非线程） 88
5.4 自动生成文件：用代码写代码 89
5.4.1 autogen/version.c 89
5.4.2 autogen/interfaces.hpp 90
5.4.3 autogen/function_stubs.hpp 91
5.4.4 autogen/endpoints.hpp 91
5.4.5 autogen/type_info.hpp 92
5.4.6 自动代码生成小结 92
5.5 接口文件odrive-interface.yaml：设备对话说明书 94
5.6 RPC模块 97
5.7 耗时测量模块 98
5.8 数据更新模块 99
5.9 ADC采样模块 101
5.10 定时器模块 103
5.10.1 电机定时器 103
5.10.2 刹车电阻定时器 104
5.10.3 编码器定时器 105
5.10.4 PWM输入捕获定时器 105
5.10.5 任务耗时定时器 106
5.10.6 系统滴答定时器 107
5.11 温度测量模块 107
5.11.1 OnboardThermistorCurrentLimiter（板载） 107
5.11.2 OffboardThermistorCurrentLimiter（外接） 108
5.12 编码器模块 108
5.13 通信接口模块 109
5.13.1 USB通信 110
5.13.2 CAN通信 110
5.13.3 UART通信 111
5.14 FOC控制模块 111
5.14.1 TIM8中断触发 112
5.14.2 相电流采样 113
5.14.3 MOS管状态检查 114
5.14.4 电流审核 114
5.14.5 电流克拉克变换 115
5.14.6 控制块更新 116
5.14.7 相电流二次采样 119
5.14.8 电流矫正 120
5.14.9 FOC算法执行 120
5.14.10 时间戳错误检测 121
5.15 三环控制：稳住系统的三重护法 122
5.15.1 位置环 122
5.15.2 速度环 123
5.15.3 电流环 127
5.16 SVPWM模块 130
第6章 ODrive软件模块——拆解宫殿 134
6.1 汇编文件初始化 134
6.2 序列号初始化 139
6.3 系统时钟初始化 141
6.4 OTP初始化 147
6.5 配置初始化 149
6.5.1 板级参数 151
6.5.2 CAN参数 152
6.5.3 编码器参数 153
6.5.4 无感参数 154
6.5.5 控制器参数 155
6.5.6 轨迹控制参数 157
6.5.7 限位开关参数 157
6.5.8 刹车参数 158
6.5.9 电机参数 159
6.5.10 板载温度参数 161
6.5.11 外接温度参数 161
6.5.12 轴参数 162
6.6 板卡资源初始化 165
6.6.1 GPIO初始化 165
6.6.2 DMA初始化 166
6.6.3 ADC初始化 167
6.6.4 TIMER初始化 167
6.6.5 SPI初始化 168
6.6.6 中断初始化 168
6.6.7 UART初始化 169
6.6.8 I2C初始化 169
6.7 板载GPIO初始化 170
6.8 USB协议栈初始化 173
6.9 ADC1二次初始化 173
6.10 UART通信线程启动 175
6.11 USB通信线程启动 178
6.12 I2C通信线程启动 180
6.13 CAN通信线程启动 181
6.14 PWM捕获初始化 182
6.15 编码器初始化 183
6.16 电机初始化 184
6.17 交流估算器初始化 186
6.18 ADC和PWM定时器启动 186
6.19 ADC1采样线程启动 187
6.20 准备进入状态机 188
6.21 状态机线程启动 189
6.21.1 开机自动执行序列分析 190
6.21.2 完整校准序列分析 206
6.21.3 其他状态机分析 206
第7章 ODrive上位机——幕后大BOSS 209
7.1 初识上位机 209
7.2 拆解上位机指挥中心 210
7.2.1 odrivetool程序分析 210
7.2.2 子命令分析 214
第8章 ODrive定制项目——DIY你的轿跑 219
8.1 硬件模块 219
8.2 小车展示 220
8.3 原理解析 221
8.4 操作步骤 221
8.5 程序添加 221
8.6 实战验货 223
附录A 224

-----

而這些也都只是純粹一本書本內容而已，你只要在 Google 搜尋一下 ODrive 

關鍵字，滿滿的所有相關開發解說、經驗資料與教學影片都是，要不然你以

為人家滿街搞人形機器人還要找電機工程師整天在那邊研究馬達電機控制嗎？

一旦基礎應用的生態系形成，系統應用自然就蓬勃發展，所以人家自然就會往下

前進到 AI 智能學習那一塊領域了。你真的要想想：你到底在每一項的基礎

技術領域要蹲多久才要往前進？我自己是很慶幸地從門外漢，經由園區科技

公司的洗禮，快速的學習成長與經驗累積。也可以很快地認識體會到：

要做系統應用，就得要快速的利用資源，否則會很快被現實市場給拋棄了。

---

你再回頭想想我稍早提到的我自己的學習成長經驗裡的那一段話嗎：

"這一切也都是因為需求創造的學習成長的機會，

也因為不斷的踏出原來的領域與環境，給自己創造一個不同的成長機會。

你說：如果我還停留在原來八位元的MCU 開發環境中，我可能還在用組合語言

在那邊慢慢地刻出每一個系統應用。"。 也未必能變現賺生活所需啊。

所以啦，不是我們忽略這些基礎不重要，但在市場需求的優先條件下，

你認為你老闆要你搞個無刷馬達控制時，你說：你還要買一片MCU 原廠的

驗證開發版回來慢慢地研究馬達電機的基礎控制的每一項信號嗎？

還要跟老闆請款添購馬達控制的解析設備嗎？每一台無人機至少有四棵

無刷馬達電機，你覺得你還要去研究這些基礎的無刷馬達電機嗎？

這些基礎控制理論對你很重要嗎？不是我們工程師"文人相輕"。

而是環境條件已經由不得我們得要想更遠一點的目標了。

在這 AI 引領技術突飛猛進時，你我真的沒辦法坐下來好好地把一些

系統市場中相關應用已經成熟形成一個完整生態系時，我還要整天跟

別人吹這些基礎理論很重要，我好好蹲下來搞個五、十年的基礎技術開發...

物競天擇，適者生存：你真的不要以為只要我累積雄厚的基礎理論就可以了，

諸不知：你心中所謂的原本想擁有的競爭優勢，在市場時機(Timing)的掌握度下，

反而成為你被市場潮流所淘汰的主要因素啊。

這一點我個人體會很深，也是肺腑之言：如果我在沒有資源奧援下，還在堅持

那些甚麼引擎控制系統開發、車用電子系統應用的話。現在的我可能很慘啊。

所以如果：你還是存著這些甚麼技術都得自己從底層走一遍傳統的想法的話，

也只能說：你是越活越回到以前的時代了啊。連我這個年紀的老工程師也都

很擔心焦慮了，你沒有？那就是你沒有真正的受到市場殘酷的考驗啊。

好好加油吧。祝福大家~