前幾天幫朋友弄一個恒溫箱控制器他手上正好有一塊STM32F103最小系統(tǒng)板和一個TM1637四位數(shù)碼管模塊讓我?guī)退由巷@示溫度。說實話這類屏幕方案我平時用OLED比較多但TM1637在工業(yè)小儀表、桌面時鐘、溫控器、充電器顯示面板這些場景里實在太常見了成本低、驅動簡單、占用引腳少非常適合STM32F103這種資源不算富裕的MCU。我用了大概十分鐘就把硬件接好二十分鐘把驅動代碼寫完調通整個過程比想象中順很多。這篇東西我把思路從頭到尾整理一遍包括TM1637模塊的通信協(xié)議、STM32F103的GPIO模擬時序、如何在main函數(shù)里封裝出實用的顯示接口以及我實測中踩過的幾個坑。不管你是剛入門單片機還是想快速搭一個數(shù)碼管顯示功能照著做都能跑起來。1. 項目背景與模塊選型思路1.1 為什么用TM1637而不是直接驅動數(shù)碼管很多初學者看到數(shù)碼管第一反應是“直接用單片機引腳點亮不就行了”。確實單個一位數(shù)碼管要顯示0到9至少需要8個段選引腳如果帶小數(shù)點就是8段再加上位選總引腳數(shù)一下就上去了。STM32F103雖然引腳多但如果你同時要接按鍵、傳感器、串口、PWM引腳根本不夠分而且動態(tài)掃描還需要CPU不斷刷新處理其他事情時很容易導致顯示閃爍。TM1637這顆芯片最聰明的地方在于它把數(shù)碼管的段選和位選全部接管了單片機只需要兩根IO線——一個時鐘CLK一個數(shù)據(jù)DIO——就能控制4位甚至6位數(shù)碼管。內部自帶顯存和譯碼電路你告訴它“第一位顯示5第二位顯示8”它自己完成動態(tài)掃描CPU完全不用操心刷新頻率。對STM32F103來說GPIO模擬兩根線的時序毫無壓力比用硬件I2C還省事。這顆芯片還有個細節(jié)值得說它內部集成了鍵盤掃描功能最多可以接8個按鍵。很多溫控器產(chǎn)品就是用一個TM1637同時搞定數(shù)碼管顯示和按鍵輸入PCB布線和單片機資源開銷都省到極致。1.2 TM1637、74HC595、直接驅動的取舍我做過的項目里數(shù)碼管驅動方案基本跑不出下面這幾種這里直接給結論方案占用引腳顯示位數(shù)CPU負擔成本適用場景單片機直接驅動動態(tài)掃描12~16個4~8位高需頻繁刷新最低引腳充裕、簡單實驗74HC595串轉并3個8位以上中仍需動態(tài)掃描很低數(shù)碼管位數(shù)多、要求低成本TM1637驅動芯片2個4~6位極低芯片自動掃描低4位數(shù)碼管、溫控器、桌面時鐘MAX7219驅動芯片3個SPI接口8位極低較高8位以上顯示、需要亮度調節(jié)我的建議很明確如果只顯示4位數(shù)字TM1637是綜合體驗最好的選擇模塊價格幾塊錢代碼量也不大。如果是做8位以上的大屏顯示或者需要精確控制某一位的單獨開關那老老實實上74HC595或者MAX7219。2. TM1637模塊工作原理與通信協(xié)議2.1 硬件結構與時序基礎TM1637外觀上是個SOP20封裝的芯片市面上常見的四位數(shù)碼管模塊大多直接把芯片貼在一小塊PCB背面正面是共陰數(shù)碼管留出4個引腳VCC、GND、CLK、DIO。VCC我實測3.3V和5V都能正常工作STM32F103的IO輸出高電平是3.3VTM1637的邏輯高電平閾值大約2.0V所以直接用3.3V供電、用GPIO直連CLK和DIO沒有任何電平匹配問題。這里有個非常關鍵的細節(jié)TM1637的DIO引腳不是純粹的雙向IO它是開漏輸出結構芯片內部有上拉電阻但上拉能力比較弱。所以我們在STM32F103初始化GPIO時DIO必須配置為開漏輸出模式而且必須開啟內部上拉。提示如果你把DIO配置成推挽輸出通信大概率仍然能工作但一旦TM1637拉低DIO表示應答時兩邊就會發(fā)生電平?jīng)_突輕則數(shù)據(jù)錯亂重則長期工作后GPIO口損壞。開漏加外部上拉才是最穩(wěn)妥的做法。時序上TM1637是一種類I2C但不完全兼容I2C的協(xié)議。它的基本單位是8位數(shù)據(jù)從最低位開始傳輸。CLK為高時DIO上的電平就是有效數(shù)據(jù)CLK下降沿寫入數(shù)據(jù)。每次傳輸8位之后第9個CLK時鐘周期用于應答——注意這里的應答是DIO被從機拉低跟I2C的應答方向一致但電平極性稍有差異實際用的時候直接模擬“發(fā)完8位后釋放DIO檢測它是否為低電平”就能通過。我把完整時序歸納成下面幾個環(huán)節(jié)起始信號CLK高電平時DIO由高變低數(shù)據(jù)寫入每個CLK下降沿前先設置好DIO電平然后拉低CLK應答檢測在第8個數(shù)據(jù)位之后釋放DIO產(chǎn)生第9個下降沿讀DIO是否被拉低停止信號CLK高電平時DIO由低變高2.2 命令格式與顯存映射TM1637的命令按其功能分成三類每一條都是單獨發(fā)送的一字節(jié)數(shù)據(jù)命令設置比如“寫數(shù)據(jù)到顯示寄存器”“讀按鍵掃描值”最常用的是0x40含義是自動地址遞增方式寫顯存地址命令設置指定接下來從哪一位顯存開始寫地址范圍是0xC0到0xC5對應從左邊數(shù)第1位到第6位顯示控制命令高四位是固定1000接下來是亮度等級最低位是開關控制。比如0x8F表示開顯示且亮度最大0x88表示關顯示0x8A是亮度最低但保持顯示這里要注意一下很多模塊背面標注的是4位數(shù)碼管這時有效地址只有0xC0到0xC3四個。但TM1637芯片最多支持6位所以如果你手上是6位模塊地址就可以寫到0xC5。數(shù)據(jù)寫入的流程是這樣的發(fā)送起始信號發(fā)送0x40告訴芯片“我要寫顯存”發(fā)送停止信號再次發(fā)送起始信號發(fā)送地址0xC0連續(xù)發(fā)送N個字節(jié)的段碼數(shù)據(jù)芯片內部地址自動遞增發(fā)送停止信號發(fā)送起始信號發(fā)送顯示控制命令比如0x8F發(fā)送停止信號很多人第一次寫代碼容易漏掉第8到第10步結果是數(shù)據(jù)全部寫進顯存了但芯片顯示控制位還處于關閉狀態(tài)數(shù)碼管就是死活不亮。這個問題我后面還會在問題排查里專門提。3. STM32F103驅動程序設計3.1 引腳分配與GPIO初始化我的接線方案非常直接選用PA0和PA1這兩個引腳理由是它們默認就是普通GPIO不涉及JTAG、串口下載、ADC等復用功能改起來不會影響調試器的連接。模塊引腳STM32F103引腳備注VCC3.3V模塊內部邏輯供電與MCU同電源GNDGND共地必須保證CLKPA0推挽輸出DIOPA1開漏輸出并啟用內部上拉這里說明一下為什么CLK用推挽而DIO用開漏。CLK始終由單片機主動驅動方向不會變推挽輸出能提供更強的驅動能力上升沿更陡峭在長線連接時抗干擾性更好。DIO需要雙向傳輸必須開漏加外部上拉這是硬件層面決定的不是代碼習慣問題。GPIO初始化代碼直接用標準外設庫寫void TM1637_GPIO_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE); // CLK 推挽輸出 GPIO_InitStructure.GPIO_Pin GPIO_Pin_0; GPIO_InitStructure.GPIO_Mode GPIO_Mode_Out_PP; GPIO_InitStructure.GPIO_Speed GPIO_Speed_50MHz; GPIO_Init(GPIOA, GPIO_InitStructure); // DIO 開漏輸出內部上拉 GPIO_InitStructure.GPIO_Pin GPIO_Pin_1; GPIO_InitStructure.GPIO_Mode GPIO_Mode_Out_OD; GPIO_InitStructure.GPIO_Speed GPIO_Speed_50MHz; GPIO_Init(GPIOA, GPIO_InitStructure); GPIO_SetBits(GPIOA, GPIO_Pin_0); // CLK 默認高 GPIO_SetBits(GPIOA, GPIO_Pin_1); // DIO 默認高釋放總線 }初始化完成之后DIO默認狀態(tài)是高電平等于釋放了總線。接下來就可以寫底層時序函數(shù)了。我建議把時鐘延時放在GPIO翻轉之間而不是用死循環(huán)的delay()這樣代碼在不同主頻下都有更好的可移植性。我用的是SysTick微秒級延時函數(shù)STM32F103跑72MHz時每翻轉一次引腳之后延時5微秒就非常穩(wěn)定。這個速度不算快但絕對夠用數(shù)碼管刷新不需要高頻操作。3.2 用模擬時序實現(xiàn)通信底層核心函數(shù)就四個起始信號、停止信號、寫一個字節(jié)并讀應答、發(fā)送命令。我先把代碼放出來然后逐行解釋。#define TM1637_CLK_HIGH() GPIO_SetBits(GPIOA, GPIO_Pin_0) #define TM1637_CLK_LOW() GPIO_ResetBits(GPIOA, GPIO_Pin_0) #define TM1637_DIO_HIGH() GPIO_SetBits(GPIOA, GPIO_Pin_1) #define TM1637_DIO_LOW() GPIO_ResetBits(GPIOA, GPIO_Pin_1) static void TM1637_Delay(void) { delay_us(5); } void TM1637_Start(void) { TM1637_DIO_HIGH(); TM1637_CLK_HIGH(); TM1637_Delay(); TM1637_DIO_LOW(); TM1637_Delay(); TM1637_CLK_LOW(); TM1637_Delay(); } void TM1637_Stop(void) { TM1637_CLK_LOW(); TM1637_DIO_LOW(); TM1637_Delay(); TM1637_CLK_HIGH(); TM1637_Delay(); TM1637_DIO_HIGH(); TM1637_Delay(); } uint8_t TM1637_WriteByte(uint8_t data) { uint8_t i; uint8_t ack 0; for (i 0; i 8; i) { // 先拉低CLK再改變DIO避免數(shù)據(jù)在時鐘高電平時跳變 TM1637_CLK_LOW(); if (data 0x01) { TM1637_DIO_HIGH(); } else { TM1637_DIO_LOW(); } TM1637_Delay(); TM1637_CLK_HIGH(); TM1637_Delay(); data 1; } // 第9個時鐘釋放DIO讀取應答 TM1637_CLK_LOW(); TM1637_Delay(); TM1637_DIO_HIGH(); // 釋放總線切換為輸入態(tài) TM1637_Delay(); TM1637_CLK_HIGH(); TM1637_Delay(); if (GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_1) 0) { ack 1; } else { ack 0; } TM1637_CLK_LOW(); TM1637_Delay(); return ack; }這個代碼里有幾個地方必須強調。第一寫數(shù)據(jù)之前必須先拉低CLK這時候DIO的變化不會被芯片誤判為起始信號因為起始信號的判定條件是CLK高電平時DIO由高變低。第二數(shù)據(jù)是從最低位開始發(fā)的所以if (data 0x01)然后右移這個順序千萬別反了反了顯示出來的數(shù)字完全是亂的。第三第9個時鐘采樣應答之前DIO要先釋放為高阻狀態(tài)然后才拉高CLK這樣才能在CLK高電平期間穩(wěn)定讀到DIO的電平。如果順序搞反可能在CLK上升沿瞬間DIO還沒被釋放讀到的永遠是自己的高電平。有的模塊上TM1637沒有接應答上拉電阻或者DIO開漏后上拉不夠強的時候讀應答可能不穩(wěn)定。處理方法是如果應答檢測失敗可以不理會它繼續(xù)往下發(fā)數(shù)據(jù)。因為實際工作中寫顯存很少出現(xiàn)尋址錯誤只要時序對數(shù)據(jù)就能進去。我在代碼里把應答結果返回出來但上層調用時只做打印提示不阻塞流程。3.3 段碼表與顯示函數(shù)封裝TM1637內部不負責把ASCII字符或數(shù)字轉換成段碼它只負責把顯存里的8位數(shù)據(jù)對應到數(shù)碼管的a到g段和小數(shù)點。所以我們需要自己維護一張段碼表。共陰數(shù)碼管段碼表如下位序是從最低位開始依次是a、b、c、d、e、f、g、dpconst uint8_t TM1637_SegTable[] { 0x3F, // 0 0x06, // 1 0x5B, // 2 0x4F, // 3 0x66, // 4 0x6D, // 5 0x7D, // 6 0x07, // 7 0x7F, // 8 0x6F, // 9 0x77, // A 0x7C, // b 0x39, // C 0x5E, // d 0x79, // E 0x71, // F 0x00, // 熄滅 0x80, // 小數(shù)點 };為什么0是0x3F從最低位開始a段1、b段1、c段1、d段1、e段1、f段1、g段0合起來就是0b00111111也就是0x3F。如果你手頭的數(shù)碼管是共陽或者段序引腳不一致這個表要重新推導不要直接抄。接下來寫顯示函數(shù)。我的設計思路很簡單調用方向某個位置寫入一個字符或數(shù)字底層自動更新顯存。先封裝一個單字節(jié)寫顯存接口void TM1637_WriteData(uint8_t addr, uint8_t data) { TM1637_Start(); TM1637_WriteByte(0x40); // 數(shù)據(jù)命令自動地址遞增寫顯存 TM1637_Stop(); TM1637_Start(); TM1637_WriteByte(0xC0 | addr); // 地址命令 TM1637_WriteByte(data); // 段碼數(shù)據(jù) TM1637_Stop(); TM1637_Start(); TM1637_WriteByte(0x8F); // 顯示控制開顯示最大亮度 TM1637_Stop(); }有人可能會問為什么不一次把所有位的數(shù)據(jù)連續(xù)寫完非要一位一位寫如果每次寫一位都發(fā)一遍0x40和0x8F效率確實低對數(shù)碼管這種低頻設備來說1ms和10ms的差異根本看不出來所以怎么簡潔怎么來。如果你有性能潔癖可以改成批量寫void TM1637_DisplayFull(uint8_t *seg_data, uint8_t len) { uint8_t i; TM1637_Start(); TM1637_WriteByte(0x40); TM1637_Stop(); TM1637_Start(); TM1637_WriteByte(0xC0); for (i 0; i len; i) { TM1637_WriteByte(seg_data[i]); } TM1637_Stop(); TM1637_Start(); TM1637_WriteByte(0x8F); TM1637_Stop(); }批量寫入方式的優(yōu)勢是只通過一次START和STOP就完成整段顯存更新中間地址自動遞增不會出現(xiàn)多位數(shù)據(jù)之間閃爍的問題。不過我在實際項目里更喜歡一個更直觀的接口直接傳入要顯示的4個數(shù)字和小數(shù)點標志void TM1637_DisplayNumber(int16_t num, uint8_t dot_pos) { uint8_t buf[4]; uint8_t i; if (num 0) { num -num; buf[0] TM1637_SegTable[16]; // 負號我沒放進去需要自己加 } buf[0] TM1637_SegTable[(num / 1000) % 10]; buf[1] TM1637_SegTable[(num / 100) % 10]; buf[2] TM1637_SegTable[(num / 10) % 10]; buf[3] TM1637_SegTable[num % 10]; if (dot_pos 4) { buf[dot_pos] | 0x80; // 加上小數(shù)點段 } TM1637_DisplayFull(buf, 4); }注意buf[dot_pos] | 0x80是把該位段碼的最高位置1這樣就在對應數(shù)碼管上點亮小數(shù)點。如果你的溫控器需要顯示25.6這種格式就把小數(shù)點位設為1。3.4 擴展功能時鐘顯示與按鍵掃描既然是做溫控器我順手把時鐘顯示也實現(xiàn)了。利用TM1637可以顯示4位數(shù)字的特點用HH:MM格式顯示時間冒號用一個特制的段碼點亮數(shù)碼管中間的兩個小數(shù)點。不過四位數(shù)碼管中間沒有冒號燈實際表現(xiàn)是第二位和第三位之間沒有分隔比較丑。更好的做法是直接用小數(shù)點當冒號把dot_pos設為1讓第二位的小數(shù)點常亮模擬冒號效果。這是我實測下來顏值最高的方案。TM1637的按鍵掃描功能也很實用。芯片支持最多8個按鍵通過DIO讀取。掃描時序跟寫數(shù)據(jù)類似但需要發(fā)送0x42讀按鍵命令然后連續(xù)讀取兩個字節(jié)的按鍵狀態(tài)。硬件上按鍵一端接DIO另一端接GND或VCC不同接法讀到的鍵值不同。這一塊我在本文不多展開后面如果大家有興趣我可以單獨寫一篇。4. 實測中遇到的坑與排查指南4.1 數(shù)碼管不亮或亮度異常的排查先說最常見的情況代碼燒進去了段碼也寫進去了但數(shù)碼管就是不亮。我從實踐中總結了一個排查順序一步步來基本都能解決。第一步查供電。TM1637模塊的VCC必須和STM32F103共用一個電源域我見過有人在面包板上用電腦USB單獨給模塊供電結果兩邊GND沒接在一起導致通信電平完全無效。第二步測CLK和DIO的靜態(tài)電平正常情況下空閑時兩個引腳都應該是高電平如果CLK是0V大概率是GPIO配置成開漏并且沒開上拉了。第三步量TM1637的VCC引腳如果模塊上自帶穩(wěn)壓芯片電壓應該穩(wěn)定在3.3V或者5V。如果供電都正常但還是不亮那就要懷疑是不是忘了發(fā)顯示控制命令。很多人寫完數(shù)據(jù)命令和地址命令就結束了顯存里明明有數(shù)據(jù)芯片顯示控制寄存器卻是關閉狀態(tài)。顯示控制命令0x8F的最后一位必須是1如果是0x88無論顯存怎么寫都不會亮。還有一個亮度相關的坑。TM1637的亮度調節(jié)范圍是0x88到0x8F低三位表示亮度等級。實際測試下來亮度等級0和1在室內光線下基本看不出來但功耗差別不小。如果你做低功耗設備可以把亮度等級設為1肉眼觀察依然清晰電流能省下幾百微安。4.2 顯示亂碼和數(shù)字錯位的深層原因顯示亂碼比較常見的原因有三個我分別說一下。第一個原因是段碼表不匹配。如果你手頭的數(shù)碼管段序跟我的表不一致顯示出來的字符就會亂掉。最簡單的方法是寫一個自檢程序讓每一位依次點亮a到g和dp段觀察實際發(fā)光順序再反推段碼表。這個自檢代碼非常簡單for (i 0; i 8; i) { seg 0x01 i; TM1637_WriteData(0, seg); delay_ms(300); }第二個原因是通信時序太快。很多STM32F103代碼是從Arduino移植過來的Arduino的digitalWrite本身就慢換成STM32后GPIO翻轉速度可能快了幾十倍時序余量不足就會隨機出錯。解法很簡單在兩個引腳翻轉之間加3到5微秒延時把速度降下來。TM1637芯片本身就不是高規(guī)格器件給它一點余量。第三個原因是我實際遇到的一個很詭異的現(xiàn)象明明寫的是0xC0開始的首地址但顯示內容整體偏移了一位。排查后發(fā)現(xiàn)是DIO引腳在讀取應答時切換輸入輸出狀態(tài)沒切干凈導致第9個時鐘的應答位實際影響了下一次數(shù)據(jù)寫入。解決方法是每次TM1637_WriteByte結束時顯式把DIO設置為輸出高電平確?？偩€回到確定狀態(tài)。我建一個常見問題速查表方便收藏現(xiàn)象可能原因處理辦法完全不亮未發(fā)送顯示控制命令寫入0x8F開顯示完全不亮通信線接反CLK和DIO交換檢查接線按順序單色亮測試完全不亮模塊供電電壓異常檢查VCC與GND與MCU共地數(shù)字亂碼段碼表不匹配用自檢程序反推段碼數(shù)字亂碼時序過快引腳翻轉間加延時亮度不均勻某一位接觸不良重新插拔或補焊對應位顯示內容錯位應答檢測干擾總線狀態(tài)寫完后強制DIO輸出高4.3 硬件連接上的注意事項TM1637模塊和STM32F103之間連線盡量短我測試過超過20厘米的杜邦線在72MHz主頻下會出現(xiàn)偶發(fā)通信失敗縮短到10厘米以內就穩(wěn)定了。如果你必須長距離走線可以把CLK和DIO的驅動速度降下來延時從5微秒加大到20微秒犧牲一點刷新率換穩(wěn)定性。模塊供電建議單獨對VCC腳加一個0.1微法去耦電容位置越靠近模塊越好。如果模塊和STM32F103之間還有其他大功率負載比如繼電器、電機驅動一定要在電源入口做好濾波否則數(shù)碼管顯示會出現(xiàn)亮度抖動的現(xiàn)象。我懷疑這跟TM1637內部上電時序和電源紋波有關實測加電容后問題明顯改善。還有一點STM32F103開發(fā)板上如果接到了5V的VIN引腳而模塊VCC接到了3.3V兩邊電平不一樣需要仔細確認。我上面用的方案是模塊VCC接3.3VCLK和DIO直連沒有任何電平轉換問題。如果你手頭只有5V供電的TM1637模塊那需要確認模塊上的電平轉換電路是否存在否則最好用兩個電阻分壓或者加一個電平轉換芯片。5. 實操過程與完整例程5.1 從接線到跑通的完整流程我把自己調試的完整流程記錄在這里照著做基本一次點亮。第一步準備器材。STM32F103最小系統(tǒng)板一塊、TM1637四位數(shù)碼管模塊一個、面包板一塊、杜邦線四根。我用的是國產(chǎn)最小系統(tǒng)板STM32F103C8T6主頻72MHz標準外設庫工程。第二步接線。按前面表格把模塊引腳和STM32F103連好。VCC接3.3VGND接GNDCLK接PA0DIO接PA1。建議先接電源再接信號線避免插拔信號線時產(chǎn)生瞬態(tài)電平損壞GPIO。第三步創(chuàng)建工程。新建一個標準外設庫工程把system_stm32f10x.c和TM1637.c加進去。main函數(shù)里先初始化systick再調用TM1637_GPIO_Init最后循環(huán)顯示一組數(shù)字。第四步燒錄驗證。我把完整main函數(shù)貼出來方便直接測試#include stm32f10x.h #include delay.h #include TM1637.h int main(void) { uint8_t i; uint8_t test_data[4]; Delay_Init(); TM1637_GPIO_Init(); // 開機自檢依次顯示0到9 for (i 0; i 10; i) { test_data[0] TM1637_SegTable[i]; test_data[1] TM1637_SegTable[9 - i]; test_data[2] TM1637_SegTable[i]; test_data[3] TM1637_SegTable[9 - i]; TM1637_DisplayFull(test_data, 4); Delay_Ms(200); } // 正式顯示1234 test_data[0] TM1637_SegTable[1]; test_data[1] TM1637_SegTable[2]; test_data[2] TM1637_SegTable[3]; test_data[3] TM1637_SegTable[4]; TM1637_DisplayFull(test_data, 4); while (1) { } }第五步觀察現(xiàn)象。正常情況是數(shù)碼管自檢階段依次顯示0到9的交替組合最后穩(wěn)定顯示1234。如果亂碼、偏移或者不亮參考上一節(jié)的排查表。5.2 代碼工程化的一些建議如果你不只是做個實驗而是要做正式產(chǎn)品代碼結構需要調整。我把TM1637的驅動單獨封裝成TM1637.c和TM1637.h對外只暴露四個函數(shù)TM1637_Init、TM1637_DisplayNumber、TM1637_DisplayString、TM1637_SetBrightness。上層應用完全不關心TM1637的時序細節(jié)想換顯示模塊的時候只改驅動層不用動業(yè)務邏輯。TM1637.h內容如下#ifndef __TM1637_H #define __TM1637_H #include stm32f10x.h #define TM1637_ADDR_START 0xC0 #define TM1637_CMD_DATA 0x40 #define TM1637_CMD_CTRL 0x8F void TM1637_GPIO_Init(void); void TM1637_DisplayNumber(int16_t num, uint8_t dot_pos); void TM1637_DisplayString(const char *str); void TM1637_SetBrightness(uint8_t brightness); #endifTM1637_DisplayString可以用來顯示“8888”“HELP”“OFFS”這類簡單字符我通常用它做故障提示。比如傳感器讀取異常時顯示“Err”比看串口日志直觀得多。5.3 在FreeRTOS里使用TM1637的注意點最近幫人移植了一個FreeRTOS的溫控工程里面也用了TM1637。這種情況下要特別小心一個坑模擬時序函數(shù)如果被打斷顯示數(shù)據(jù)會損壞。假設高優(yōu)先級任務正在執(zhí)行TM1637的數(shù)據(jù)寫入突然被定時器任務搶占時鐘線停在半中間等一會兒高優(yōu)先級任務回來后繼續(xù)翻轉引腳TM1637可能已經(jīng)把中間狀態(tài)誤判成停止或起始信號最終顯示亂碼。解決辦法有兩個方向。第一個是給TM1637驅動加臨界區(qū)保護在TM1637_Start和TM1637_Stop之間關中斷。代碼很簡單void TM1637_DisplayNumber(int16_t num, uint8_t dot_pos) { __disable_irq(); // 計算段碼并寫入 __enable_irq(); }但是要控制臨界區(qū)時間不能太長。我的實測值是顯示4位數(shù)字完整寫入需要大約1毫秒這個時間對絕大多數(shù)實時系統(tǒng)來說都可以接受但如果系統(tǒng)里有對時序要求極高的外設比如1ms中斷的PWM控制你就要小心了。第二個方案是做一個顯存緩沖區(qū)和刷新任務顯示刷新由低優(yōu)先級任務周期執(zhí)行其他任務只修改緩沖區(qū)不直接操作IO。這個方案更優(yōu)雅也是產(chǎn)品級的做法。底層顯示任務每次獲取緩沖區(qū)快照后用一個完整的不被打斷的時序把數(shù)據(jù)刷到TM1637。優(yōu)先級怎么設置我建議刷新任務優(yōu)先級設在中等偏下因為數(shù)碼管顯示偶爾延遲幾十毫秒用戶根本感知不到但高優(yōu)先級任務被搶占了可能導致控制邏輯抖動。實際項目中我把顯示任務放在osPriorityLow控制任務放在osPriorityHigh跑了一整晚沒出現(xiàn)顯示異常。6. 個人實操中的一些體會這段時間反復調TM1637有幾個體會特別想分享。第一很多單片機通信問題都不是協(xié)議太復雜而是電平狀態(tài)沒搞對。TM1637的DIO要求開漏加上拉和標準I2C的SDA思路一模一樣把這個細節(jié)刻在腦子里以后遇到任何開漏總線都不會犯低級錯誤。第二調試數(shù)碼管顯示時不要一上來就寫完整業(yè)務邏輯先用一個固定數(shù)據(jù)自檢確認硬件通路沒問題再往上疊代碼排錯效率高得多。另外我建議有條件的備一個邏輯分析儀哪怕是二三十塊錢的簡易版也行。看波形能直接確認起始信號、數(shù)據(jù)位、應答位是不是符合預期比人眼盯著數(shù)碼管猜亂碼原因快得多。我之前有一次通訊時好時壞用邏輯分析儀一看才發(fā)現(xiàn)是CLK下降沿之后DIO還沒穩(wěn)定時序窗口太窄加延時后立刻解決。TM1637作為一顆老芯片性能和功能談不上驚艷但穩(wěn)定、便宜、資料多在溫控器、儀表、家電面板這些對成本敏感的領域依然活躍。STM32F103驅動它代碼量很小哪怕新手跟著這篇文章操作大概一晚上也能跑通。以后再做顯示功能時我推薦你在預算和引腳都寬裕時試試OLED在追求簡單實用時直接選TM1637兩者各有各的用武之地。