做嵌入式的小伙伴肯定都有過這種經(jīng)歷板子快畫完了發(fā)現(xiàn)IO口不夠用。我這陣子調試一個帶4檔旋轉開關的小設備就撞上了這個問題。傳統(tǒng)接法一個檔位一根IO四個檔位要占掉4個輸入口剩下的引腳還得留給通信、指示燈和按鍵根本不夠分。最后我把4檔旋轉開關改成了電阻分壓加一路ADC采集硬生生省下3個IO口。同一臺設備還要通過Modbus RTU把采集數(shù)據(jù)上報給上位機結果float在16位寄存器里拆來拆去又出了亂碼前后折騰了大半天才把字節(jié)序理順。這篇筆記就把這兩件事的完整方案、計算過程和踩坑記錄寫清楚給正在折騰IO規(guī)劃或者Modbus浮點通訊的朋友做個參考。1. IO不夠用4檔旋轉開關的一路ADC采集方案1.1 場景分析與方案選型先說說我遇到的實際場景。設備面板上有一個4檔旋轉開關用來切換工作模式手動、半自動、全自動、校準四個狀態(tài)必須能被MCU實時識別。最開始畫原理圖的時候我習慣性給每個檔位分配一個IO開關撥到哪一檔對應的引腳就被拉低或者拉高。電路設計很簡單邏輯判斷也直觀調試時一根線一根線測過去就行。問題出在IO預算上。主控用的是STM32F103系列總共就那么幾十個引腳除了旋轉開關還要接485收發(fā)、狀態(tài)指示燈、按鍵、調試串口以及幾個傳感器輸入。等我把所有外設分配完發(fā)現(xiàn)手頭只剩下一兩個空余IO根本不夠4個檔位的輸入。這時候就得換思路。常見替代方案有三個一是用撥碼開關加編碼器把4個狀態(tài)編碼成2位二進制只需要2個IO但撥碼開關手感差、體積大而且4檔旋轉開關已經(jīng)定了改硬件不現(xiàn)實。二是用專門的IO擴展芯片比如PCF8574通過I2C讀狀態(tài)占2個IOSDA/SCL但加片子要改板子、加代碼殺雞用牛刀。三就是這次用的方案把檔位開關接成電阻分壓網(wǎng)絡用一路ADC讀取不同電壓值來反推檔位。第三種方案的優(yōu)勢非常明顯只占用1個ADC引腳不需要改結構、不需要加芯片成本幾乎為零只要在開關引腳上多焊幾個電阻就行。它的代價是軟件上要做ADC采樣、濾波和閾值判斷比單純讀IO稍微繞一點但這個復雜度完全可控。我現(xiàn)在做這類產(chǎn)品凡是遇到“多選一”的開關類輸入只要不是高速切換場景優(yōu)先考慮ADC分壓IO省下來還能干別的。1.2 電阻分壓電路與參數(shù)計算電路結構其實就三樣東西一個固定上拉電阻、一個ADC采樣點、四個檔位各自的電阻。公共端接ADC引腳通過一個上拉電阻接到VCC旋轉開關的四個檔位分別接四顆不同阻值的電阻到GND。開關撥到不同的檔位就相當于把對應阻值的電阻接入分壓回路ADC引腳讀到的電壓自然不同。選阻值的時候有兩個目標檔位之間壓差要足夠大、便于穩(wěn)定判斷同時電流不能太大、免得白白耗電。我用的參考電壓是3.3V上拉電阻選了10kΩ四個檔位分別接10kΩ、20kΩ、33kΩ、100kΩ。這些都是E24標準系列采購方便價格便宜。分壓計算公式是Vout VCC × R檔 / (R上拉 R檔)逐檔算下來檔位接地電阻分壓輸出12位ADC讀數(shù)110kΩ1.65V2048220kΩ2.20V2731333kΩ2.53V31424100kΩ3.00V3724相鄰檔位之間的電壓差分別是0.55V、0.33V、0.47V換算成ADC讀數(shù)相差683、411、582。STM32F103的ADC是12位分辨率這個區(qū)分度非常充足即使電阻精度差一點、電源有紋波也不會誤判。如果板子空間的功耗敏感可以把上拉電阻加大到47kΩ檔位電阻同步放大分壓關系不變但電流能降下來代價是ADC引腳輸入阻抗對采樣穩(wěn)定性的要求更高采樣時間要相應加長。這里有個容易忽略的坑旋轉開關從一檔撥到另一檔的過程中觸點會經(jīng)過短暫的開路或抖動狀態(tài)ADC會讀到一個不穩(wěn)定的跳變值。軟件里必須處理這個瞬態(tài)不能讀一次就下結論。另外如果MCU的ADC參考電壓引腳VREF和供電不是同一個電源分壓計算要以VREF的實際電壓為基準而不是想當然用3.3V。2. 軟件實現(xiàn)采樣濾波、檔位判斷與防抖2.1 ADC初始化與多次采樣預處理硬件電路只能保證分壓關系正確真正的可靠性要靠軟件。我首先把ADC配置成單通道、軟件觸發(fā)、12位精度采樣時間拉長到55.5個周期。為什么采樣時間很重要因為分壓網(wǎng)絡等效于一個電阻源驅動ADC內部采樣電容采樣時間太短會導致電容充電不完全低阻檔位還好高阻檔位尤其是100kΩ那一路讀數(shù)會偏低。讀取的時候不能直接拿一次轉換結果當檔位依據(jù)至少要連續(xù)采樣16次。我用的方法是16次采樣里去掉一個最大值、去掉一個最小值剩下的14次求和取平均。這樣能把毛刺和偶發(fā)異常值過濾掉得到的值比較平滑。代碼大致長這樣#define ADC_SAMPLE_TIMES 16 static uint16_t adc_read_single(void) { ADC_SoftwareStartConvCmd(ADC1, ENABLE); while (!ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC)) { } return ADC_GetConversionValue(ADC1); } static uint16_t adc_read_filtered(void) { uint32_t sum 0; uint16_t max_val 0; uint16_t min_val 4095; for (uint8_t i 0; i ADC_SAMPLE_TIMES; i) { uint16_t v adc_read_single(); sum v; if (v max_val) max_val v; if (v min_val) min_val v; } return (uint16_t)((sum - max_val - min_val) / (ADC_SAMPLE_TIMES - 2)); }這個函數(shù)每次返回一個經(jīng)過預處理的ADC讀數(shù)后續(xù)檔位判斷就基于這個值。采樣周期可以根據(jù)實際速度調整我這里是每秒判斷一次功耗和響應速度都能接受。2.2 檔位判定閾值、滯回與連續(xù)確認ADC讀數(shù)算出來了怎么映射回檔位最簡單的方法是設三個閾值小于2390認為是1檔小于2936認為是2檔小于3433認為是3檔其余是4檔。閾值取的是相鄰兩檔ADC讀數(shù)中點比如1檔和2檔的中點是(20482731)/22389.5取整2390。但只用單閾值判斷有個問題如果讀數(shù)正好在閾值附近波動檔位會來回跳。比如檔位2的實際分壓恰好因為電阻偏差偏低了一點讀數(shù)在2385到2395之間跳系統(tǒng)就會在1檔和2檔之間反復橫跳。解決方法是加滯回區(qū)間也就是“上去”和“下來”用不同的閾值。更簡單的土辦法是連續(xù)確認連續(xù)5次采樣都在同一個檔位才認為檔位真正切換了。我實際用的是連續(xù)確認加基礎閾值的組合#define GEAR_TH_1_2 2390 #define GEAR_TH_2_3 2936 #define GEAR_TH_3_4 3433 #define GEAR_CONFIRM_CNT 5 typedef enum { GEAR_UNKNOWN 0, GEAR_1, GEAR_2, GEAR_3, GEAR_4 } gear_t; static gear_t gear_now GEAR_UNKNOWN; static gear_t gear_from_adc(uint16_t adc) { if (adc GEAR_TH_1_2) return GEAR_1; if (adc GEAR_TH_2_3) return GEAR_2; if (adc GEAR_TH_3_4) return GEAR_3; return GEAR_4; } gear_t gear_update(void) { uint16_t adc adc_read_filtered(); gear_t candidate gear_from_adc(adc); static uint8_t confirm_cnt 0; static gear_t last_candidate GEAR_UNKNOWN; if (candidate last_candidate) { if (confirm_cnt GEAR_CONFIRM_CNT) { confirm_cnt 0; if (gear_now ! candidate) { gear_now candidate; /* 檔位已變化在這里做狀態(tài)上報 */ } } } else { last_candidate candidate; confirm_cnt 0; } return gear_now; }這套邏輯跑下來機械抖動的毛刺會被過濾得一干二凈。實測中即使我用手快速來回撥開關輸出檔位也只會按順序變化不會出現(xiàn)跳變或者卡死。核心思想是模擬量采集永遠不要直接映射狀態(tài)一定要經(jīng)過濾波和時間上的確認這是搞ADC輸入的基本功。2.3 檔位狀態(tài)上報與Modbus聯(lián)動檔位判出來了怎么用如果只是板子上點個燈那直接查一下變量就行。但我的需求是要通過Modbus把檔位狀態(tài)上報給上位機所以我在保持寄存器里專門劃了一個地址存放當前檔位值就是1到4。這只占一個寄存器非常省空間。這里有一個細節(jié)不要每個判斷周期都把檔位寫入寄存器最好只在檔位變化的時候寫。一方面減少對寄存器區(qū)的無意義寫入另一方面也方便上位機做事件檢測。我在gear_update函數(shù)里已經(jīng)預留了“if (gear_now ! candidate)”這個分支實際工程里就是在這個位置更新Modbus寄存器同時置一個標志位通知主循環(huán)需要發(fā)送數(shù)據(jù)或者更新顯示。如果后續(xù)想把檔位信息和浮點參數(shù)聯(lián)動上報比如不同檔位對應不同的量程系數(shù)這個系數(shù)本身是個float那就引出了第二部分的問題float怎么在Modbus里傳。3. Modbus里的float為什么總亂碼從IEEE 754到字節(jié)序3.1 為什么一個float要占兩個寄存器Modbus協(xié)議的基礎單位是寄存器一個寄存器16位。而C語言里的float是32位的按IEEE 754標準存儲正好等于兩個寄存器。所以要在Modbus里傳一個浮點數(shù)必須把它拆成兩個16位分別放進兩個連續(xù)的保持寄存器接收方再把兩個寄存器拼回去。IEEE 754單精度浮點數(shù)的32位結構是1位符號位、8位指數(shù)位、23位尾數(shù)位。一個數(shù)比如100.5在內存里對應的32位十六進制是0x42C90000。實際換算是這樣100.5的二進制是1100100.1科學計數(shù)法是1.1001001×2^6指數(shù)為6加上偏移量127得到133即0x85尾數(shù)是10010010000000000000000拼起來就是0 10000101 10010010000000000000000也就是0x42C90000。這個編碼規(guī)則搞清楚了后面字節(jié)序問題就很好理解了。很多新手第一次遇到Modbus浮點亂碼第一反應是懷疑485接線、波特率、CRC校驗之類的問題折騰一圈發(fā)現(xiàn)通訊完全正常問題出在數(shù)據(jù)解釋上。這就是因為float本身是32位而Modbus寄存器是16位中間的拆分和組合規(guī)則沒對上。3.2 字節(jié)序才是最大的坑拆分組合的規(guī)則就是字節(jié)序最常見的排列模式有ABCD、CDAB、BADC、DCBA四種。假設一個float變量在內存中的4個字節(jié)從高位到低位依次是b3、b2、b1、b0b3是最高字節(jié)那么模式寄存器0的內容寄存器1的內容備注ABCDb3 b2b1 b0高字在前高字節(jié)在前CDABb1 b0b3 b2低字在前高字節(jié)在前BADCb2 b3b0 b1高字在前低字節(jié)在前DCBAb0 b1b2 b3低字在前低字節(jié)在前Modbus協(xié)議標準本身是偏向大端的寄存器內部的字節(jié)序通常默認高字節(jié)在前所以ABCD模式被認為是“標準”模式。但是現(xiàn)實中很多PLC、儀表、傳感器廠商有自己的內部約定特別是歐洲一些設備喜歡用CDAB模式也就是把低16位放在第一個寄存器高16位放在第二個寄存器。加上一些上位機組態(tài)軟件自己還有額外的字節(jié)序設置多一層排列組合亂碼概率直線上升。用100.5這個數(shù)舉例它的IEEE 754編碼是0x42C90000最高字節(jié)b30x42b20xC9b10x00b00x00。如果是ABCD模式兩個寄存器讀出來是0x42C9和0x0000。如果是CDAB模式讀出來就是0x0000和0x42C9。所以只要看Modbus Poll讀出來的寄存器原始值立刻就能判斷當前設備是哪種排列。3.3 用Modbus Poll快速確認字節(jié)序判斷字節(jié)序的辦法很簡單根本不需要猜。我在從機寄存器區(qū)里專門留了兩個測試寄存器初始化的時候把一個已知浮點數(shù)比如100.5拆好放進去。聯(lián)調的時候打開Modbus Poll讀取這兩個寄存器的原始值方法如下在從機代碼里把保持寄存器地址0x1000和0x1001寫死為100.5拆分后的兩個16位值先按ABCD模式填。打開Modbus Poll連接從機功能碼03起始地址0x1000數(shù)量2。觀察寄存器值如果顯示0x42C9和0x0000說明主站按ABCD解釋完美。如果顯示0x0000和0x42C9說明數(shù)據(jù)其實是CDAB排列主站和從機有一邊需要調整。如果看到0xC942或0x0042這種奇怪的組合說明寄存器地址錯位、讀寫長度不對或者從機代碼里float拆分時字節(jié)本身已經(jīng)打亂了。我后來在工程里一直保留這個測試寄存器不只是調試時用產(chǎn)品出廠自檢時也能跑一遍確認通訊鏈路的數(shù)據(jù)解釋一致。網(wǎng)上那些“16進制轉float在線工具”很多也支持四種字節(jié)序切換配合Modbus Poll的原始值幾步就能定位問題。Modbus Poll沒注冊也能讀數(shù)據(jù)只是功能受限調試基本夠用。4. 浮點收發(fā)代碼聯(lián)合體、memcpy與位運算的取舍4.1 聯(lián)合體的直觀寫法與隱患C語言里把float拆成兩個uint16_t很多老工程師第一反應是用聯(lián)合體typedef union { float f; uint16_t u16[2]; uint8_t u8[4]; } float_map_t;用起來確實簡單賦值給f然后讀u16[1]和u16[0]就行。但是這種寫法有一個平臺相關的問題聯(lián)合體成員的字節(jié)布局取決于主機的字節(jié)序。在x86和ARM小端模式下u8[0]存的是float的最低字節(jié)在大端模式下u8[0]存的是最高字節(jié)。如果只在STM32上跑小端模式是固定的代碼沒問題。可一旦代碼被移植到其他平臺或者編譯器做了特殊的結構體對齊優(yōu)化聯(lián)合體成員的對齊和填充可能和預期不一致浮點數(shù)據(jù)就會悄悄出錯。更重要的是嚴格別名規(guī)則。C標準里通過聯(lián)合體的另一個成員來讀取當前活動成員的值在不同編譯器下的行為并不完全一致。GCC和Keil實際支持這種用法也跑得好好的但這屬于“知道坑在哪才能用”的寫法。產(chǎn)品代碼里我傾向用更保守、可移植性更強的方式。4.2 推薦memcpy加位運算的可移植寫法我推薦的方案是先用memcpy把float按字節(jié)拷貝到一個uint32_t變量里然后對這個uint32_t做位運算按需要的字節(jié)序拆成兩個16位寄存器值。memcpy不關心主機的字節(jié)序它做的就是純字節(jié)搬運真正的字節(jié)序控制完全由后面的移位和掩碼操作決定邏輯清晰換平臺也不會翻車。#include string.h /* 以AB-CD模式為例寄存器0存高16位寄存器1存低16位 */ void float_to_modbus(float value, uint16_t regs[2]) { uint32_t bits 0; memcpy(bits, value, sizeof(bits)); regs[0] (uint16_t)(bits 16); regs[1] (uint16_t)(bits 0xFFFFu); } float modbus_to_float(const uint16_t regs[2]) { uint32_t bits ((uint32_t)regs[0] 16) | regs[1]; float value 0.0f; memcpy(value, bits, sizeof(value)); return value; }這段代碼在STM32上跑起來把100.5傳進去regs[0]得到0x42C9regs[1]得到0x0000和前面表格對得上。如果設備的字節(jié)序是CDAB只要把兩個寄存器的賦值順序調換一下也就是regs[0]存低16位、regs[1]存高16位其余邏輯完全一樣。如果一臺設備需要適配不同上位機或者不同協(xié)議版本可以把字節(jié)序抽成枚舉參數(shù)typedef enum { FLOAT_ORDER_ABCD 0, FLOAT_ORDER_CDAB, FLOAT_ORDER_BADC, FLOAT_ORDER_DCBA } float_order_t; void float_to_modbus_ex(float value, uint16_t regs[2], float_order_t order) { uint32_t bits 0; memcpy(bits, value, 4); switch (order) { case FLOAT_ORDER_ABCD: regs[0] (uint16_t)(bits 16); regs[1] (uint16_t)(bits 0xFFFFu); break; case FLOAT_ORDER_CDAB: regs[0] (uint16_t)(bits 0xFFFFu); regs[1] (uint16_t)(bits 16); break; default: /* BADC和DCBA需要再做字節(jié)交換不常用這里不展開 */ break; } }實際項目里BADC和DCBA出現(xiàn)概率很低遇到也是先懷疑設備手冊看錯了。我通常在代碼注釋里寫清楚當前使用的模式免得過幾個月自己回來看代碼一臉懵。4.3 在FreeModbus工程中的掛載方式常見的基于FreeModbus v1.6移植的STM32工程里寄存器讀寫是通過一個uint16_t數(shù)組模擬的比如usRegHoldingBuf應用層所有數(shù)據(jù)都映射到這個數(shù)組。這時候float和寄存器的交互就是簡單調用關系上報時先調用float_to_modbus把float拆進兩個數(shù)組元素接收時調用modbus_to_float從兩個數(shù)組元素還原出float。需要注意地址對齊寫入float時起始寄存器地址如果是奇數(shù)按寄存器編號算要小心后續(xù)區(qū)域的數(shù)據(jù)錯位。比如float占了寄存器0和1下一個變量就應該從寄存器2開始放不能從1開始。雖然不會崩但數(shù)據(jù)會互相覆蓋而且是那種特別難查的隱蔽bug。我還習慣在代碼里把寄存器地址定義成宏浮點參數(shù)的起始地址、長度、字節(jié)序模式都集中在一個頭文件里。這樣上位機聯(lián)調時一旦發(fā)現(xiàn)字節(jié)序不匹配改一處宏定義就能全局切換不用到處改代碼。這個習慣在維護老設備兼容性時特別有用。5. 實測踩坑記錄與排查速查表5.1 檔位誤判與ADC讀數(shù)跳變第一次聯(lián)調時旋轉開關撥到3檔上位機顯示成了2檔而且偶爾還會跳回3檔。排查下來發(fā)現(xiàn)不是閾值算錯了而是我ADC采樣時間設得太短。用示波器看ADC引腳的波形發(fā)現(xiàn)100kΩ那一路的電壓建立過程很慢每次切換檔位后大約有幾十毫秒的充放電過程采樣早了就讀到舊電壓的余值。解決方法有兩個一是把ADC采樣時間拉長到最大檔位二是切換檔位后延遲一點再進行下一次判斷。我兩個都做了問題徹底消失。還有一次是檔位4附近讀數(shù)漂移查了半天發(fā)現(xiàn)是板子上一顆電阻虛焊。所以這里也提醒一句分壓電阻的焊點質量直接影響結果出廠前最好做一次全檔位校準測試每個檔位的ADC讀數(shù)落在哪個區(qū)間、和理論值差多少記錄下來作為出廠參數(shù)。5.2 Cortex-M0上強轉導致HardFault有次在Cortex-M0內核的芯片上跑代碼程序沒跑多久就進了HardFault。查反匯編發(fā)現(xiàn)是float指針強轉成uint16_t指針后直接解引用導致的。Cortex-M0對未對齊訪問支持很差float變量在內存里的地址如果不是2字節(jié)對齊強轉指針后讀一個16位值就可能觸發(fā)硬件異常。解決辦法很簡單不要做這種強轉統(tǒng)一用memcpy。這也是我為什么在浮點收發(fā)部分強調用memcpy加位運算而不是指針強轉或者聯(lián)合體。踩過一次坑之后我寫嵌入式代碼基本不碰指針強轉處理多字節(jié)數(shù)據(jù)。5.3 Modbus浮點亂碼排查流程如果上位機讀出來的浮點數(shù)明顯不對我建議按下面這個順序排查不要直接改代碼瞎試第一步用Modbus Poll讀原始寄存器值。不要看浮點解釋結果把兩個寄存器的值切到十六進制顯示記下來。第二步和目標浮點數(shù)的IEEE 754編碼對照。比如期望是100.5編碼就是0x42C90000。第三步比較兩個寄存器和0x42C90000四個字節(jié)的對應關系看到0x42C9在第一個、0x0000在第二個是ABCD反過來則是CDAB。第四步確認主站那邊的“數(shù)據(jù)類型”設置和“字節(jié)序/字序”設置是否與從機實際發(fā)送一致。很多組態(tài)軟件里這兩項是分開配置的單獨改對某一項還不能解決。第五步如果原始寄存器值本身就和預期對不上說明問題在從機代碼里去查float拆分函數(shù)。5.4 常見問題速查表現(xiàn)象可能原因排查方向檔位讀數(shù)跳變、誤判旋轉開關抖動、ADC采樣時間短加濾波、連續(xù)確認、延長采樣時間檔位讀數(shù)整體偏移分壓電阻精度低、VREF不準確換1%精度電阻核對參考電壓Modbus浮點亂碼字節(jié)序不匹配用測試寄存器配合Modbus Poll對比IEEE 754編碼Cortex-M0運行異常指針強轉導致未對齊訪問改用memcpy拷貝數(shù)據(jù)浮點數(shù)據(jù)錯位但值能對上寄存器起始地址沒有對齊檢查參數(shù)放置地址統(tǒng)一按寄存器編號規(guī)劃最后分享一個我自己堅持了很久的習慣凡是Modbus從機工程我一定在寄存器表里預留兩個專用的測試寄存器初始值就放100.5這個數(shù)。聯(lián)調時先讀這兩個寄存器字節(jié)序對不對、地址對不對、讀寫長度對不對一眼就能看出來。旋轉開關那邊阻值能選E24標準系列就不要用非標阻值采購好買Debug也好查。這兩條經(jīng)驗幫我少加了不少班也希望能幫正在看這篇筆記的你省點時間。