從riscv底層原理分析gd32vf103的中斷行為

1.概述

2.中斷向量表初始化

3.詳細分析一下irq_entry

4.關于gd32vf103中斷編程模型的理解

1.概述在處理riscv處理器中斷的時候，需要弄清楚兩個概念：

1.向量中斷

2.非向量中斷

對于向量中斷，其中斷發(fā)生后，pc指針會根據(jù)中斷的類型跳轉到基地址+中斷號*4的地址處去執(zhí)行中斷處理程序，做過stm32的，應該比較清楚向量中斷的大概樣子。當然，riscv也是支持這種向量中斷，這樣每個地址處會安排一個特定的中斷處理函數(shù)，當中斷發(fā)生后，跳轉到特定的函數(shù)去執(zhí)行即可。

對于非向量中斷，則表示中斷發(fā)生后只有一個入口，需要在這一個中斷中去判斷具體中斷號，這種行為可以在常見的mips處理器、sparc處理器中看到。

既然riscv支持這兩種中斷處理方式，正好gd32vf103的庫函數(shù)也實現(xiàn)了這兩種機制，那么就徹底的分析一下實現(xiàn)的策略。

2.中斷向量表初始化任何代碼在最初的匯編級別的初始化時，都會指定向量的基地址。當然riscv也不例外。

對于向量中斷來說

/*

* Intialize ECLIC vector interrupt

* base address mtvt to vector_base

*/

la t0， vector_base

csrw CSR_MTVT， t0

這里的理解就向mtvt寄存器中存放vector_base，該處存放向量地址入口，每個向量中斷發(fā)生，則根據(jù)偏移執(zhí)行對應的函數(shù)。

.globl vector_base

.type vector_base， @object

vector_base：

#if defined（DOWNLOAD_MODE） && （DOWNLOAD_MODE ！= DOWNLOAD_MODE_FLASH）

j _start /* 0： Reserved， Jump to _start when reset for ILM/FlashXIP mode.*/

.align LOG_REGBYTES /* Need to align 4 byte for RV32， 8 Byte for RV64 */

#else

DECLARE_INT_HANDLER default_intexc_handler /* 0： Reserved， default handler for Flash download mode */

#endif

DECLARE_INT_HANDLER default_intexc_handler /* 1： Reserved */

DECLARE_INT_HANDLER default_intexc_handler /* 2： Reserved */

DECLARE_INT_HANDLER eclic_msip_handler /* 3： Machine software interrupt */

DECLARE_INT_HANDLER default_intexc_handler /* 4： Reserved */

DECLARE_INT_HANDLER default_intexc_handler /* 5： Reserved */

。

。

。

對于向量函數(shù)的處理，不用過多介紹。

下面非向量中斷的入口

/*

* Set ECLIC non-vector entry to be controlled

* by mtvt2 CSR register.

* Intialize ECLIC non-vector interrupt

* base address mtvt2 to irq_entry.

*/

la t0， irq_entry

csrw CSR_MTVT2， t0

csrs CSR_MTVT2， 0x1

其中irq_entry表示了非向量的處理過程。csrs CSR_MTVT2， 0x1該指令的解析如下：

mtvt2［0］ = 1 mtvt2［0］為0時，中斷入口使用mtvec寄存器，mtvt2［0］為1時，中斷入口為mtvt2［31:2］。

3.詳細分析一下irq_entry分析非向量中斷的行為，可以更好的理解riscv的中斷底層的處理機制。

.global irq_entry

/* This label will be set to MTVT2 register */

irq_entry：

/* Save the caller saving registers （context） */

SAVE_CONTEXT

/* Save the necessary CSR registers */

SAVE_CSR_CONTEXT

/* This special CSR read/write operation， which is actually

* claim the CLIC to find its pending highest ID， if the ID

* is not 0， then automatically enable the mstatus.MIE， and

* jump to its vector-entry-label， and update the link register

*/

csrrw ra， CSR_JALMNXTI， ra

/* Critical section with interrupts disabled */

DISABLE_MIE

/* Restore the necessary CSR registers */

RESTORE_CSR_CONTEXT

/* Restore the caller saving registers （context） */

RESTORE_CONTEXT

/* Return to regular code */

mret

從中斷處理的原理上來講，中斷處理分三部分：

1.保存當前現(xiàn)場

2.進入中斷處理函數(shù)

3.恢復現(xiàn)場

其中SAVE_CONTEXT確實是保存上下文現(xiàn)場的方式。

.macro SAVE_CONTEXT

csrrw sp， CSR_MSCRATCHCSWL， sp

/* Allocate stack space for context saving */

#ifndef __riscv_32e

addi sp， sp， -20*REGBYTES

#else

addi sp， sp， -14*REGBYTES

#endif /* __riscv_32e */

STORE x1， 0*REGBYTES（sp）

STORE x4， 1*REGBYTES（sp）

STORE x5， 2*REGBYTES（sp）

STORE x6， 3*REGBYTES（sp）

STORE x7， 4*REGBYTES（sp）

STORE x10， 5*REGBYTES（sp）

STORE x11， 6*REGBYTES（sp）

STORE x12， 7*REGBYTES（sp）

STORE x13， 8*REGBYTES（sp）

STORE x14， 9*REGBYTES（sp）

STORE x15， 10*REGBYTES（sp）

#ifndef __riscv_32e

STORE x16， 14*REGBYTES（sp）

STORE x17， 15*REGBYTES（sp）

STORE x28， 16*REGBYTES（sp）

STORE x29， 17*REGBYTES（sp）

STORE x30， 18*REGBYTES（sp）

STORE x31， 19*REGBYTES（sp）

#endif /* __riscv_32e */

.endm

按照riscv的數(shù)據(jù)模型，又分為I數(shù)據(jù)模型和E數(shù)據(jù)模型，這部分在riscv的MISA寄存器中有描述。簡而言之，E數(shù)據(jù)模型會比I數(shù)據(jù)模型少一半的寄存器，E數(shù)據(jù)模型是專門針對嵌入式應用場景的，更少的寄存器意味著更快速的壓棧和出棧，實時性相應會更加優(yōu)秀。

I數(shù)據(jù)模型一共有32個寄存器，而E數(shù)據(jù)模型是16個寄存器。

所以在進行中斷入棧的時候，E數(shù)據(jù)模型會壓入10個寄存器。

caller代表中斷上層函數(shù)可以使用的寄存器，所以

x1，x5，x6，x7，x10，x11，x12，x13，x14，x15

這10個寄存器會保存，上述程序多保存了x4。

下面理解一下中斷的處理，通過csrrw ra， CSR_JALMNXTI， ra該指令進行分析。

不難發(fā)現(xiàn)，這個是個芯來自定義擴展指令，CSR_JALMNXTI寄存器通過gdb解析可以看到如下的數(shù)據(jù)

其中0x7ed則是該寄存器的地址。

那么一條指令是如何實現(xiàn)中斷的處理的呢？

實際上該指令首先會判斷當前eclic中是否有掛起未處理的中斷，如果沒有，那這條指令向下執(zhí)行，并不會處理任何事情，一旦存在，那么會跳轉到eclic的中斷向量的入口，這里便是關鍵的地方了。

另外需要注意的是，默認進入中斷時，保存現(xiàn)場時，此處是關閉中斷的，當執(zhí)行這條語句，中斷便會開啟，然后判斷是否還有中斷未響應，這樣可以達到中斷咬尾的效果。

并且當中斷處理函數(shù)執(zhí)行完成后，又會回到該指令執(zhí)行一次，判斷是否還需要處理中斷。這一切的行為都是由硬件完成，大大提高中斷處理的效率。

現(xiàn)場恢復則是中斷處理的逆過程，這里不贅述。

4.關于gd32vf103中斷編程模型的理解對于cortex-m3等處理器來說，riscv的底層模型似乎更加復雜一些，但是實際上弄清楚riscv中斷處理模型，eclic中斷處理機制，以及向量中斷，非向量中斷和一條中斷處理指令csrrw ra， CSR_JALMNXTI， ra后，也不會覺得十分的難以理解。

玩gd32vf103，其riscv底層匯編級別的中斷處理一般都不會太多需要修改的，理解就可以。需要使用好的是eclic配置，還有相關的gpio的中斷引腳的配置即可。將中斷線、eclic配置完成，具體中斷處理函數(shù)中實現(xiàn)自己的業(yè)務邏輯即可，不需要有許多學習成本。

原文標題：從riscv底層原理分析gd32vf103的中斷行為

文章出處：【微信公眾號：嵌入式IoT】歡迎添加關注！文章轉載請注明出處。

責任編輯：haq