ADC
ADC(Analog-to-Digital Converter), 即模擬信號 - 數字信號轉換器
在STM32F103C8T6中, 同樣具有ADC功能.
以我們的芯片為例, 也存在2個片上外設ADC, 即ADC1和ADC2, 這兩個ADC片上外設都掛載在APB2總線上.
我們的ADC片上外設, 是一種具有12位逐次逼近型ADC,ADC轉換的本質是不斷的電壓比較
如何把0~4095映射到0~3.3?
把3.3分成4096份,每份3.3/4095=8.06e-4,2000的離散值對應的電壓是1.61
2v對應的離散值是4095/3.3*2=2481,對應的二進制是1001 1011 0.001
下面就是實現了4095/3.3*2這個過程,想一想二進制除法的實現
初始化:SAR 從最高位(MSB,即第11位)開始試探,其余位清零。
例如,首次試探值:
1000 0000 0000
(即 2048,對應中間電壓)。
比較判斷:
若?VIN≥VDACVIN?≥VDAC?,保留該位為?
1
,否則置?0
。
逐位逼近:
移至下一位(如第10位),重復比較,直到最低位(LSB)。
完成轉換:
經過?12次比較?后,SAR 中的值即為最終數字輸出。
在配置使用ADC時, 通道是一個重要數據, 而ADC的通道和固定的引腳綁定.
// 在每次AD轉換前配置規則組,這樣可以靈活更改AD轉換的通道
// 第一個參數: 采用ADC1還是ADC2
// 第二個參數: 使用那個通道, 比如ADC_Channel_1表示PA1通道; ADC_Channel_4表示PA4通道
// 第三個參數: 規則組可以有最多16個通道,可以指定該通道在規則組中的采樣順序
// 第四個參數: 對輸入電壓采樣的時間長短; ADC_SampleTime_55Cycles5表示采樣55.5個ADC時鐘節拍ADC_RegularChannelConfig(ADC1, ADC_Channel_4, 1, ADC_SampleTime_55Cycles5);// 軟件觸發一次ADC1采樣ADC_SoftwareStartConvCmd(ADC1, ENABLE);
// 等待采樣結束: 采樣是否結束, 高根據寄存器EOC標志位來判斷while (ADC_GetFlagStatus(ADC1, ADC_FLAG_EOC) == RESET);
規則組 和 注入組:在ADC中我們可以把采樣分組, 無論是規則組還是注入組, 它的本質都是去記錄采樣的通道(要依次采樣那幾個通道, 以組劃分)
注意: 注入組的優先級要比規則組高,注入組最多可以配置同時采集4個通道, 并且每個通道的采集數據分別用一個寄存器存儲。而規則組最多可以同時采集16個通道, 但是16個通道的采集數據, 共用一個寄存器存儲, 有可能產生數據覆蓋
連續轉化:?上一次采集完畢, 立馬進行下一次采集(完全不需要額外的軟件觸發或者硬件觸發)
掃描模式:每次觸發, 就把組內的配置的所有通道的數據都采集一遍
// ADC初始化ADC_InitTypeDef ADC_InitStructure;
// ADC模式選擇: 暫時選擇默認獨立工作模式(即只使用ADC1)ADC_InitStructure.ADC_Mode = ADC_Mode_Independent;
// 數據對齊(和采樣數據精度相關)ADC_InitStructure.ADC_DataAlign = ADC_DataAlign_Right;
// 選擇觸發采集模式(不用外部硬件觸發, 使用軟件觸發)ADC_InitStructure.ADC_ExternalTrigConv = ADC_ExternalTrigConv_None;
// 不進行連續轉化, 不開啟, 必須觸發過來, 才進行采樣ADC_InitStructure.ADC_ContinuousConvMode = DISABLE;
// 不開啟掃描模式, 因為我們準備每個組設置一個采樣通道(通過設置, 采樣, 修改設置, 采樣的方式)ADC_InitStructure.ADC_ScanConvMode = DISABLE;
// 開啟的通道數(給掃描模式指明掃描幾個通過個數用的)ADC_InitStructure.ADC_NbrOfChannel = 1;
// 初始化ADC_Init(ADC1, &ADC_InitStructure);// 啟動ADC
Flash
?主存儲器: 用來存放程序代碼和一些不可變數據(特點是斷電不丟失)
起始地址0x08000000??當前默認64KB(0x08000000~0x0800FFFF)
信息塊: 是STM32內部Flash額外劃分的一部分, 主要用于存放設備的用戶配置數據或校準數據.該區域通常是只讀的, 不能隨意修改.
接口寄存器: 用于控制和配置STM32的外設(如GPIO、USART、SPI、I2C、ADC等)
// addr: 頁首地址
void erasePage(uint32_t addr) {FLASH_Unlock(); //解鎖FLASH_ErasePage(addr); //頁擦除FLASH_Lock(); //加鎖
}
看門狗
看門狗(Watchdog Timer, WDT)是一種硬件定時器, 用于防止系統死機或者長時間運行異常代碼, 避免程序跑飛.
獨立看門狗
?假設今天預分頻設為4分頻, 重裝值設置為111111111111 -> 4095,求超時時間是多少?
40kHz/4=10kHz,所以0.1ms一個時鐘節拍,所以超時時間是409.5ms
IWDG_ReloadCounter(); ?// 喂狗喂狗的本質, 就是通過鍵寄存器的修改(IWDG_KR), 要求遞減計數器進行計數值的重裝.避免計數值減為0.
窗口看門狗
窗口看門狗(WWDG)是一種?基于時間窗口?的看門狗定時器,主要用于?高可靠性嵌入式系統(如汽車電子、工業控制),確保程序在?嚴格的時間范圍內?進行喂狗(刷新),避免?過早或過晚?喂狗導致的系統異常。
?窗口看門狗 vs 獨立看門狗(IWDG)
特性 | 窗口看門狗(WWDG) | 獨立看門狗(IWDG) |
---|---|---|
時鐘源 | 來自 APB1(PCLK1) | 獨立低速時鐘(LSI,~32kHz) |
復位條件 | 喂狗時間?不在窗口內 | 超時未喂狗 |
時間精度 | 較高(依賴系統時鐘) | 較低(依賴 LSI) |
窗口約束 | 必須?在最小和最大時間之間?喂狗 | 只需?在超時前?喂狗 |
應用場景 | 對?時序嚴格?的任務(如安全控制) | 防?程序跑飛(通用看門狗) |
36MHz/4096/4=2197Hz第一次4096分頻,第二次4分頻
一個節拍0.46ms,WWDG_CR64個節拍復位64*0.46=29.44ms,最晚的時間
假設WWDG_CFR的值是112,并且一旦,它的數值小和喂狗時就會復位
計數器(WWDG_CR):
- 7 位遞減計數器(T6~T0),當?
T6
?從 1→0 時觸發復位(即?0x40
?→?0x3F
)。 - 喂狗通過寫入?
WWDG_CR
?重置計數器值。
配置寄存器(WWDG_CFR):
- 設置?窗口值(W6~W0),定義喂狗的?允許時間窗口。
- 設置?預分頻器(WDGTB)?調整時鐘頻率。
時間窗口
最小時間(上窗口?→?“喂狗允許的起始點”):由?
WWDG_CFR
?的窗口值(W)決定,喂狗?不能早于?計數器值 > W。最大時間(下窗口?→?“喂狗截止點”):計數器值從初始值遞減到?
0x3F
(即 T6=0)時復位,喂狗?不能晚于?此點。
SPI
SPI協議的核心特性包括高位優先(MSB First)的數據傳輸方式、可配置的時鐘極性(CPOL)和相位(CPHA), 以及靈活的時鐘速率調整能力. 時鐘極性(CPOL)決定了時鐘信號在空閑狀態下的電平(高或低), 而時鐘相位(CPHA)則定義了數據采樣相對于時鐘邊沿的位置. 通過組合CPOL和CPHA, SPI支持四種不同的工作模式(Mode0至Mode3),以適應不同設備的需求.此外,SPI協議允許主機通過軟件或硬件方式控制片選信號(NSS/CS)從而實現對多個從機的靈活管理.
MISO:Master Input Slave Output/主設備數據輸入,從設備數據輸出
MOSI:Master Output Slave Input/主設備數據輸出,從設備數據輸入
SCK:Serial Clock/時鐘信號,由主設備產生
CS:Chip Select/片選信號,由主設備控制
提問兩臺從機可以同時給,主機發消息嗎?
不可以,會產生沖突
?需要注意的是:?
以W25Q64為例, 其總共占用64Mbit即8M字節
在其內部又以"塊"->"扇區"->"頁"來劃分 :一個塊=64K字節=16扇區、一個扇區=4K字節=16頁
一個頁=256字節
并且在對其進行操作的時候要求先擦除, 再寫入
擦除要以扇區為單位
?對W25Q64進行操作的時候:
讀取數據過程: 發送讀取命令->發送地址->發送數據(是為了讀數據)
寫入數據過程: 發送寫入命令->發送地址->發送寫入內容
SPI 通過?時鐘極性(CPOL)?和?時鐘相位(CPHA)?定義數據傳輸時序,共有?4 種模式:
模式 | CPOL | CPHA | 時鐘空閑狀態 | 數據采樣邊沿 |
---|---|---|---|---|
0 | 0 | 0 | 低電平 | 上升沿 |
1 | 0 | 1 | 低電平 | 下降沿 |
2 | 1 | 0 | 高電平 | 下降沿 |
3 | 1 | 1 | 高電平 | 上升沿 |
MQTT
MQTT(Message Queuing Telemetry Transport)是一種輕量級的?發布/訂閱(Pub-Sub)?消息協議,專為?低帶寬、高延遲或不可靠網絡?環境設計。
正常來講,HTTP頭部很大,這樣就會導致許多問題,MQTT的輕量級,就體現在頭部輕量
MQTT vs HTTP 對比
特性 | MQTT?(消息隊列遙測傳輸) | HTTP?(超文本傳輸協議) |
---|---|---|
協議類型 | 發布/訂閱(Pub-Sub)模型 | 請求/響應(Request-Response)模型 |
設計目標 | 低帶寬、高延遲、不可靠網絡(IoT 優化) | 通用 Web 通信(文檔傳輸) |
連接方式 | 長連接(基于 TCP + 可選 TLS) | 短連接(默認無狀態,HTTP/2 支持長連接) |
消息大小 | 極輕量(頭部僅 2 字節起) | 較大(HTTP 頭部通常幾百字節) |
通信模式 | 異步(Broker 中轉消息) | 同步(客戶端主動請求,服務端響應) |
QoS 支持 | ? 3 個級別(0/1/2) | ? 無原生 QoS(依賴 TCP 重傳) |
實時性 | ? 高(低延遲推送) | ? 較低(需輪詢或 WebSocket) |
適用場景 | IoT、傳感器數據、實時控制 | Web 頁面、REST API、文件傳輸 |
典型端口 | 1883(明文)、8883(TLS) | 80(HTTP)、443(HTTPS) |
廣播/多播支持 | ?(Topic 訂閱) | ?(需額外協議如 WebSocket) |
消息保留 | ?(Broker 可存儲最后一條消息) | ?(無狀態,需額外實現) |
連接開銷 | ? 極低(適合嵌入式設備) | ?? 較高(HTTP 頭部 + Cookie 等) |