• RT-Thread 中断管理(学习二)


    中断的底半处理

    RT-Thread不对中断服务程序所需要的处理时间做任何假设、限制,但如同其它实时操作系统或非实时操作系统一样,用户需要保证所有的中断服务程序在尽可能短的时间内完成。这样在发生中断嵌套,或屏蔽了相应中断源的过程中,不会耽误嵌套的其它中断处理过程,或自身中断源的下一次中断信号。

    当一个中断发生时,中断服务程序需要取得相应的硬件状态或者数据。
    如果中断服务程序接下来需要对状态或者数据进行简单处理,比如CPU时钟中断,中断服务程序只需对一个系统时钟变量进行加一操作,然后就结束中断服务程序。这类中断所需要的运行时间往往都比较短。

    但对于另外一些中断,中断服务程序在取得硬件状态或数据以后,还需要进行一系列更耗时的处理过程,通常需要将该中断分割为两部分,即上半部分(Top Half)和底半部分(Bottom Half)。
    在上半部分中,取得硬件状态和数据后,打开被屏蔽的中断,给相关线程发送一条通知,然后结束中断服务程序;而接下来,相关的线程在接收到通知后,接着对状态或数据进行进一步的处理,这一过程称之为底半处理。

    为了详细描述底半处理在RT-Thread中的实现,以一个虚拟的网络设备接收网络数据包作为范例,假设接收到数据报文后,系统对报文的分析、处理是一个相对耗时的,比外部中断源信号重要性小许多的,而且在不屏蔽中断源信号情况下也能处理的过程。

    这个例子的程序创建了一个nwt线程,这个线程在启动运行后,将阻塞在nw_bh_sem信号上,一旦这个信号量被释放,将执行接下来nw_packet_parser过程,开始Bottom Half的事件处理。

    /* 用于唤醒线程的信号量 */
    rt_sem_t nw_bh_sem;
    
    /* 数据读取、分析的线程 */
    void demo_nw_thread(void *param)
    {
    	//首先对设备进行必要的初始化工作
    	device_init_setting();
    
    	/* 创建一个semaphore 来响应 Bottom Half的事件*/
    	nw_bh_sem = rt_sem_create("bh_sem", 0, RT_IPC_FLAG_PRIO);
    
    	while(1)
    	{
    		rt_sem_take(nw_bh_sem,RT_WAITING_FOREVER);
    		nw_packet_parser(packet_buffer);
    		nw_packet_process(packet_buffer);
    	}
    }
    
    int main(void)
    {
        rt_thread_t thread;
    
        /* 创建处理线程 */
        thread = rt_thread_create("nwt",demo_nw_thread, RT_NULL, 1024, 20, 5);
    
        if (thread != RT_NULL)
            rt_thread_startup(thread);
    }
    
    void demo_nw_isr(int vector, void *param)
    {
    	nw_device_status_read();
    	rt_sem_release(nw_bh_sem);
    }
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36

    中断服务程序通过对一个信号量对象的等待和释放,来完成中断Bottom Half的起始和终结。
    由于将中断处理划分为Top和Bottom两个部分后,使得中断处理过程变为异步过程。
    必须认真考虑中断服务的处理时间是否大于给Bottom Half发送通知并处理的时间。

    RT-Thread中断管理接口

    为了把操作系统和系统底层的异常、中断硬件隔离开来,RT-Thread把中断和异常封装为一组抽象接口,如下图所示:
    在这里插入图片描述

    中断服务程序挂接

    系统把用户的中断服务程序(handler)和指定的中断号关联起来,可调用如下的接口挂载一个新的中断服务程序:

    rt_isr_handler_t rt_hw_interrupt_install(int vector,rt_isr_handler_t handler, void *param,char *name);
    
    • 1

    调用rt_hw_interrupt_install()后,当这个中断源产生中断时,系统将自动调用装载的中断服务程序。

    • vector:是挂载的中断号。
    • handler:新挂载的中断服务程序
    • param:作为参数传递给中断服务程序
    • name:中断的名称
    • 返回:挂载这个中断服务程序之前挂载的中断服务程序的句柄

    注:这个 API 并不会出现在每一个移植分支中,例如通常 Cortex-M0/M3/M4 的移植分支中就没有这个 API。

    中断服务程序是一种需要特别注意的运行环境,它运行在非线程的执行环境下(一般为芯片的一种特殊运行模式(特权模式)),在这个运行环境中不能使用挂起当前线程的操作,因为当前线程并不存在。

    中断源管理

    通常在ISR准备处理某个中断信号之前,我们需要先屏蔽改中断源,在ISR处理完状态或数据以后,及时的打开之前屏蔽的中断源。

    屏蔽中断源可以保证在接下来的处理过程中硬件状态或者数据不会收到干扰。

    void rt_hw_interrupt_mask(int vector);
    
    • 1

    调用rt_hw_interrupt_mask函数接口后,相应的中断将会被屏蔽(这个中断触发时,中断状态寄存器会有相应的变化,但并不送达到处理器进行处理)。

    打开屏蔽的中断源:

    void rt_hw_interrupt_umask(int vector);
    
    • 1

    全局中断开关

    全局中断开关也称为中断锁,是禁止多线程访问临界区的最简单的一种方式,即通过关闭中断的方式,来保证当前线程不会被其它事件打断(整个系统已经不再响应那些可以触发重新调度的外部事件),当前线程不会被抢占,除非这个线程主动放弃了CPU控制权。

    rt_base_t rt_hw_interrupt_disable(void);
    
    • 1
    • 返回:中断状态,函数运行前的中断状态。

    恢复中断也称为开中断。
    rt_hw_interrupt_enable()这个函数用于“使能”中断,它恢复了调用中断使能函数前的中断状态。

    如果调用rt_hw_disable()函数前是关中断状态,调用此函数后仍然是关中断状态。

    使用中断锁来操作临界区的方法可以应用于任何场合,且其他几类同步方式都是依赖于中断锁而实现的,可以说中断锁是最强大的和最高效的同步方法。

    只是使用中断锁最主要的问题在于,在中断关闭期间系统将不再响应任何中断,也就不能响应外部的事件。所以中断锁对系统的实时性影响巨大,当使用不当的时候会导致系统完全无实时性可言。

    为了保证一行代码的互斥运行,最快速的方法是使用中断锁而不是信号量或互斥量

        /* 关闭中断 */
        level = rt_hw_interrupt_disable();
        a = a + value;
        /* 恢复中断 */
        rt_hw_interrupt_enable(level);
    
    • 1
    • 2
    • 3
    • 4
    • 5
        /* 获得信号量锁 */
        rt_sem_take(sem_lock, RT_WAITING_FOREVER);
        a = a + value;
        /* 释放信号量锁 */
        rt_sem_release(sem_lock);
    
    • 1
    • 2
    • 3
    • 4
    • 5

    函数 rt_base_t rt_hw_interrupt_disable(void) 和函数 void rt_hw_interrupt_enable(rt_base_t level) 一般需要配对使用,从而保证正确的中断状态。

    在RTT中,开关全局中断的API支持多级嵌套使用。

    中断通知

    当整个系统被中断打断,进入中断处理函数时,需要通知内核当前已经进入到中断状态。
    针对这种情况,可通过以下接口:

    void rt_interrupt_enter(void);
    void rt_interrupt_leave(void);
    
    • 1
    • 2

    这两个接口分别用在中断前导程序和中断后续程序中,均会对rt_interrupt_nest(中断嵌套深度)的值进行修改。

    每当进入中断时,可以调用rt_interrupt_enter()函数,用于通知内核,当前已经进入了中断状态,并增加中断嵌套深度(执行rt_interrupt_nest++);

    每当退出中断时,可以调用rt_interrupt_leave()函数,用于通知内核,当前已经离开了中断状态,并减少中断嵌套深度。

    注意不要在应用程序中调用这两个接口函数。

    使用rt_interrupt_enter/leave()的作用是,在中断服务程序中,如果调用了内核相关的函数(如释放信号量等操作),则可以通过判断当前中断状态,让内核及时调整相应的行为。

    例如,在中断中释放了一个信号量,唤醒了某线程,但通过判断发现当前系统处于中断上下文环境中,那么在进行线程切换时应该采取中断中线程切换的策略,而不是立即进行切换。

    在上层应用中,在内核需要指定当前已经进入到中断状态或当前嵌套的中断深度时,可调用rt_interrupt_get_nest()接口,它会返回rt_interrupt_nest。

    • 0:当前系统不处于中断上下文环境中。
    • 1:当前系统处于中断上下文环境中。
    • 大于1:当前中断嵌套层次。
  • 相关阅读:
    stm32cubemx hal学习记录:FreeRTOS事件
    【草料】uni-app ts vue 小程序 如何如何通过草料生成对应的模块化二维码
    【K哥爬虫普法】网盘用的好,“艳照门”跑不了
    (题目练习)条件概率+权值线段树+FWT+后缀数组
    原型模式 创建型模式之二
    基于SpringBoot+Vue+uniapp的家政服务预约系统的详细设计和实现(源码+lw+部署文档+讲解等)
    一文读懂SQL中的Aggregate(聚合) 函数和Scalar(标准)函数
    netty系列之:netty中的核心MessageToByte编码器
    networkx使用draw画图报错:TypeError: ‘_AxesStack‘ object is not callable
    银行业务测试
  • 原文地址:https://blog.csdn.net/Caramel_biscuit/article/details/133679655