STM32網絡之中斷的示例分析

這篇文章主要為大家展示了“STM32網絡之中斷的示例分析”，內容簡而易懂，條理清晰，希望能夠幫助大家解決疑惑，下面讓小編帶領大家一起研究并學習一下“STM32網絡之中斷的示例分析”這篇文章吧。

01、簡介

網絡中斷向量：一個用于正常的網絡操作，另一個當它映射到EXIT線路19的時候，用于以太網喚醒事件（帶有喚醒幀或魔術數據包檢測）

第一個網絡中斷保留為MAC和DMA產生的中斷，正如在MAC中斷和DMA中斷部分。

第二個中斷保留為喚醒事件時PMT產生的中斷。喚醒事件對EXIT線路19的映射是造成STM32F20X和STM32F21X退出低功耗模式，并且產生中斷。

當映射到EXIT線路19的以太網喚醒事件發生和，MACPMT中斷使能并且有一個上升沿的EXIT線路19中斷也被使能，他們都能喚醒中斷。

可使用看門狗定時器（請參見ETH_DMARSWTR 寄存器）靈活控制RS 位（ETH_DMASR寄存器）。當此看門狗定時器使用非零值編程時，看門狗定時器激活，只要RXDMA完成發送一個接收的數據幀到系統存儲，在沒有觸發接收狀態，因為它不是使能的在相應的接收描述符（RDES1[31]）（也就是：未在相應接收描述符(RDES1[31])使能接收狀態）。當定時器按照編程值運行時，RS位被置1并且中斷發生，如果ETH_DMAIER寄存器中相應位使能。看門狗定時失效在運行前，當數據幀被發送到內存，并且RS置1，因為定時器被使能為描述符。

注意：

讀取PMT 控制和狀態寄存器會自動將接收的喚醒幀和接收的魔術數據包PMT 中斷標志清零。但是，由于用于這些標志的寄存器位于 CLK_RX域，因此在固件能發現此更新前可能有顯著的延遲。當 RX 時鐘很慢（在10 Mbit 模式）和當AHB 總線為高頻時，該延遲會特別長。

由于從PMT 到CPU 的中斷請求基于CLK_RX 域中的相同寄存器，所以即使在讀取PMT_CSR 之后，CPU也可能錯誤地第二次調用中斷例程。因此，可能需要固件輪詢接收的喚醒幀和接收的魔術數據包位，并僅在發現它們都為‘0’時退出中斷服務程序。

02、代碼

STM32的網絡中斷，其實準確來說應該是網絡專用的DMA的中斷，網絡中的數據包符合1518規則，也就是說是1460字節，MAC接收的數據包是2K字節，網絡上每一個數據包MAC接收完都會產生中斷。

官方代碼是這樣的

明顯是使用查詢的方式，沒有使用到中斷。

中斷的使用方式如下：

配置網絡中斷

注釋掉官方提供的查詢部分的代碼。

我們使用中斷形式之后，代碼是

這樣的代碼，我們在接收小于一個DMA描述符數據大小的數據沒有問題，很流暢。

在接收大量數據的時候就會出現錯誤，接收的會緩慢，接收的過多會死機

解決辦法是：

把if修改成while

這樣就把整個數據包接收完之后再跳出中斷，這樣就解決了這個問題。

以上是“STM32網絡之中斷的示例分析”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！