SylixOS 中是否支持中断底半部，如何使用？

SylixOS 中是否支持中断底半部，如何使用？

1. 适用范围

      本文档适用于对中断底半部有了解需求的开发人员。 

2. 原理概述

      在发生中断时，内核会记录哪个中断产生并把中断相应的处理函数加入一个处理队列里， 直到把所有同一时间发生的中断全部记录好后，
处理队列里的函数才会逐一得到调用。所以当一个中断处理函数处理过久时，就有可能影响它后面的中断处函数的执行时机。我们用的中断处
理函数是可以被中断信号打断的。
 
      内核在处理中断请求时，要求在单位时间内可以处理尽可能多的中断，也就是系统要求处理中断的吞吐率要尽可能地大。这就要求中断处
理程序要尽可能地短小精悍，并且不能有耗时操作。但是大多数的中断处理程序是很复杂的，很难在短时间内处理完毕。为了提高系统的响应
能力和并发能力，需要解决平衡中断处理程序时间要求短和工作量要大的问题，SylixOS 将中断处理分为两个阶段，也就是顶半部和底半部。

3. 准备工作

3.1 环境准备

      1) SylixOS 操作系统；
      2) RealEvo-IDE。

3.2 资源准备

1) 中断底半部测试代码。


4. 技术实现

4.1 顶半部与底半部

      SylixOS 将中断处理分为两个阶段，也就是顶半部和底半部：
      ● 顶半部完成的一般是紧急的硬件操作，一般包括读取寄存器中的中断状态，清除中断标志，将底半部处理程序挂到底半部的执行队列中去；
      ● 底半部完成大部分的耗时操作，并且可以被新的中断打断。
 
      也就是说把中断处理中实时性要求高的工作放在顶半部处理，实时性要求不高的工作放在底半部来处理。因底半部是在所有的顶半部全部处
理完后才会得到调用处理，所以这种处理方式会提高中断的响应速度。
      
      如果中断处理是非常简单的工作，也可以不用分成顶半部和底半部的方式来处理。

4.2 底半部种类

      顶半部完成尽可能少的比较紧急的功能，它往往只是简单地读取寄存器中的中断状态并清除中断标志后就进行“登记中断”的工作。“登记中断”
意味着将底半部处理程序挂到该设备的底半部执行队列中去。这样，顶半部执行的速度就会很快，可以服务更多的中断请求。

      现在，中断处理工作的重心就落在了底半部的头上，它来完成中断事件的绝大多数任务。底半部几乎做了中断处理程序所有的事情，而且可以
被新的中断打断，这也是底半部和顶半部的最大不同，因为顶半部往往被设计成不可中断。底半部则相对来说并不是非常紧急的，而且相对比较耗
时，不在硬件中断服务程序中执行。

      ● 底半部可以被新的中断事件打断，这是和顶半部最大的不同，顶半部通常被设计成不可被打断。
      ● 底半部相对来说不是非常紧急的，而且相对比较耗时，不在硬件中断服务程序中执行。
      ● 如果中断要处理的工作本身很少，所有的工作可在顶半部全部完成。

      尽管顶半部、底半部的结合能够改善系统的响应能力，但是，僵化地认为 SylixOS 设备驱动中的中断处理一定要分两个半部则是不对的。如果中
断要处理的工作本身很少，则完全可以直接在顶半部全部完成。

      中断底半部的实现有三种：
      ● 软中断（softirq）：基本的底半部机制，现在很少使用；
      ● 微线程（tasklet）：微线程通过软中断机制来调度；
      ● 工作队列（workqueue）：工作队列将工作交由一个内核线程处理。

 

4.2.1 软中断（softirq）

      软中断（softirq）也是一种传统的底半部处理机制，它的执行时机通常是顶半部返回的时候，tasklet的基于软中断实现的，因此也运行于软中断上
下文。
 
      软中断支持 SMP，同一个 softirq 可以在不同的 CPU 上同时运行，softirq 必须是可重入的。软中断是在编译期间静态分配的，它不像 tasklet 那样
能被动态的注册或去除。
 
      软中断和 tasklet 都是运行在中断上下文中，它们与任一进程无关，没有支持的进程完成重新调度。所以软中断和 tasklet 不能睡眠、不能阻塞，它们
的代码中不能含有导致睡眠的动作，如减少信号量、从用户空间拷贝数据或手工分配内存等。也正是由于它们运行在中断上下文中，所以它们在同一个
CPU 上的执行是串行的，这样就不利于实时多媒体任务的优先处理。

      软中断的特性：
      1) 一个软中断不会抢占另外一个软中断；
      2) 唯一可以抢占软中断的是中断处理程序；
      3) 其他软中断(包括相同类型的)可以在其他的处理其上同时执行；
      4) 一个注册的软中断必须在被标记后才能执行；
      5) 软中断不可以自己休眠(即调用可阻塞的函数或 sleep 等)；
      6) 索引号小的软中断在索引号大的软中断之前执行。

 

4.2.2 软中断（tasklet）

      他的执行上下文是软中断，执行时机通常是顶半部返回的时候。
 
      tasklet 是一种特殊的软中断，同一时刻一个 tasklet 只能在一个 CPU 执行，不同的 tasklet 可以在不同的 CPU 上执行。这和软中断不同，软中断同一时刻
可以在不同的 CPU 并行执行，因此软中断必须考虑重入的问题。
 
      引入 tasklet，最主要的是考虑支持 SMP，提高 SMP 多个 CPU 的利用率；两个相同的 tasklet 决不会同时执行。tasklet 可以理解为 softirq 的派生，所以它的
调度时机和软中断一样。对于内核中需要延迟执行的多数任务都可以用 tasklet 来完成，由于同类 tasklet 本身已经进行了同步保护，所以使用 tasklet 比软中断
要简单的多，而且效率也不错。tasklet 把任务延迟到安全时间执行的一种方式，在中断期间运行，即使被调度多次，tasklet 也只运行一次，不过 tasklet 可以
在 SMP 系统上和其他不同的 tasklet 并行运行。在 SMP 系统上，tasklet 还被确保在第一个调度它的 CPU 上运行，因为这样可以提供更好的高速缓存行为，从而
提高性能。
 
      tasklet 的特性：
      不允许两个两个相同类型的 tasklet 同时执行，即使在不同的处理器上。

4.2.3 工作队列（workqueue）

      工作队列的执行上下文是内核线程，因此可以调度和睡眠。
 
      如果推后执行的任务需要睡眠，那么就选择工作队列。另外，如果需要用一个可以重新调度的实体来执行你的下半部处理，也应该使用工作队列。它是唯
一能在进程上下文运行的下半部实现的机制，也只有它才可以睡眠。这意味着在需要获得大量的内存时、在需要获取信号量时，在需要执行阻塞式的 I/O 操作
时，它都会非常有用。

      work queue 造成的开销最大，因为它要涉及到内核线程甚至是上下文切换。这并不是说 work queue 的低效，但每秒钟有数千次中断，就像网络子系统时常
经历的那样，那么采用其他的机制可能更合适一些。尽管如此，针对大部分情况工作队列都能提供足够的支持。
 
      工作队列特性：
      1) 工作队列会在进程上下文中执行；
      2) 可以阻塞。(前两种机制是不可以阻塞的)；
      3) 可以被重新调度。(前两种只可以被中断处理程序打断)；
      4) 使用工作队列的两种形式：
            a. 缺省工作者线程 (works threads)；
            b. 自建的工作者线程。
      5) 在工作队列和内核其他部分之间使用锁机制就像在其他的进程上下文一样；
      6) 默认允许响应中断。        


4.3 工作队列及使用

      SylixOS系统中使用的中断底半部处理机制是工作队列。

4.3.1 接口函数

      ● 创建工作队列 API_WorkQueueCreate
  1. 原型 : PVOID  API_WorkQueueCreate (CPCHAR                  pcName,
  2.                                    UINT                    uiQSize, 
  3.                                    BOOL                    bDelayEn, 
  4.                                    ULONG                   ulScanPeriod, 
  5.                                    PLW_CLASS_THREADATTR    pthreadattr)
  6. 输入 :  pcName            队列名称
  7.         uiQSize           队列大小
  8.         bDelayEn          是否创建带有延迟执行功能的工作队列
  9.         ulScanPeriod      如果带有延迟选项, 此参数指定服务线程扫描周期.
  10.         pthreadattr       队列服务线程选项
  11. 返回 :  工作队列句柄
  12. 说明 :  创建一个工作队列
  13. 注意 :  如果不需要延迟执行功能, 则系统自动创建为简单工作队列, 内存占用量小, 执行效率高.
      ● 删除一个工作队列 API_WorkQueueDelete
  1. 原型 : ULONG  API_WorkQueueDelete (PVOID  pvWQ)
  2. 输入 : pvWQ      工作队列句柄
  3. 返回 : ERROR_CODE
  4. 说明 : 删除一个工作队列
      ● 加入一个工作到工作队列 API_WorkQueueInsert
  1. 原型 :ULONG  API_WorkQueueInsert (PVOID           pvWQ, 
  2.                                   ULONG           ulDelay,
  3.                                   VOIDFUNCPTR     pfunc, 
  4.                                   PVOID           pvArg0,
  5.                                   PVOID           pvArg1,
  6.                                   PVOID           pvArg2,
  7.                                   PVOID           pvArg3,
  8.                                   PVOID           pvArg4,
  9.                                   PVOID           pvArg5)
  10. 输入 : pvWQ         工作队列句柄
  11.        ulDelay      最小延迟执行时间
  12.        pfunc        执行函数
  13.        pvArg0 ~ 5   执行参数
  14. 返回 : ERROR_CODE
  15. 说明 : 将一个工作插入到工作队列
      ● 清空工作队列 API_WorkQueueFlush
  1. 原型 : ULONG  API_WorkQueueFlush (PVOID  pvWQ)
  2. 输入 : pvWQ         工作队列句柄
  3. 返回 : ERROR_CODE
  4. 说明 : 清空工作队列
      ● 获取工作队列状态 API_WorkQueueStatus
  1. 原型 : ULONG  API_WorkQueueStatus (PVOID  pvWQ, UINT  *puiCount)
  2. 输入 : pvWQ         工作队列句柄
  3.    puiCount     当前队列中作业数量
  4. 返回 : ERROR_CODE
  5. 说明 : 获取工作队列状态

4.3.2 中断底半部实例

      以下为测试实例，内核模块在装载时创建了一个不带有延迟执行功能的 SylixOS 工作队列和一个线程，线程用于设置某个 GPIO 的中断处理函数并使能中断，
当产生对应的按键中断时，中断处理函数会清除中断，并将耗时操作插入到工作队列中，卸载内核模块时清除该 GPIO 的相关设置并删除工作队列。
  1. #define __SYLIXOS_STDIO
  2. #define __SYLIXOS_KERNEL
  3. #include <SylixOS.h>
  4. #include <module.h>

  6. #define KEY_NUM 36

  8. PVOID _G_pvWorkQueue;
  9. static INT _G_iIrqNum;

  11. static VOID __workHandler(VOID)
  12. {
  13.     printk("work handler function start.\n");
  14.     API_TimeSSleep(5);
  15.     printk("work handler function stop.\n");
  16. }

  18. static irqreturn_t GpioIsr (INT iGpioNum, ULONG ulVector)
  19. {
  20.     API_GpioClearIrq(iGpioNum);

  22.     API_WorkQueueInsert(_G_pvWorkQueue,
  23.                         0,
  24.                         __workHandler,
  25.                         LW_NULL,
  26.                         LW_NULL,
  27.                         LW_NULL,
  28.                         LW_NULL,
  29.                         LW_NULL,
  30.                         LW_NULL);

  32.     return (ERROR_NONE);
  33. }

  35. static PVOID __keyThread (PVOID pvArg)
  36. {
  37.     INT iError;

  39.     iError = API_GpioRequestOne(KEY_NUM, LW_GPIOF_IN, "KEY");
  40.     if (iError != ERROR_NONE) {
  41.         printk("failed to request gpio %d!\n", KEY_NUM);
  42.         return (NULL);
  43.     }

  45.     _G_iIrqNum = API_GpioSetupIrq(KEY_NUM, LW_FALSE, 0);
  46.     if (_G_iIrqNum == PX_ERROR) {
  47.         printk("failed to setup gpio %d irq!\n", KEY_NUM);
  48.         return (NULL);
  49.     }

  51.     iError = API_InterVectorConnect((ULONG)_G_iIrqNum,
  52.                                     (PINT_SVR_ROUTINE)GpioIsr,
  53.                                     (PVOID)KEY_NUM,
  54.                                     "GpioIsr");
  55.     if (iError != ERROR_NONE) {
  56.         printk("failed to connect GpioIsr!\n");
  57.         return (NULL);
  58.     }

  60.     API_InterVectorEnable(_G_iIrqNum);

  62.     return (NULL);
  63. }
  64. void module_init (void)
  65. {
  66.     LW_CLASS_THREADATTR threadattr;

  68.     printk("interrupt_module init!\n");
  69.     API_ThreadAttrBuild(&threadattr,
  70.                         4 * LW_CFG_KB_SIZE,
  71.                         LW_PRIO_NORMAL,
  72.                         LW_OPTION_THREAD_STK_CHK,
  73.                         LW_NULL);
  74.                         _G_pvWorkQueue = API_WorkQueueCreate("t_workqueue",
  75.                         10,
  76.                         FALSE,
  77.                         0,
  78.                         &threadattr);
  79.     if (_G_pvWorkQueue == LW_NULL) {
  80.         printk("WorkQueue create failed.\n");
  81.         return;
  82.     }

  84.     API_ThreadCreate("t_key",
  85.                     (PTHREAD_START_ROUTINE)__keyThread,
  86.                     LW_NULL,
  87.                     LW_NULL);
  88. }

  90. void module_exit (void)
  91. {
  92.     API_InterVectorDisconnect((ULONG)_G_iIrqNum,
  93.                               (PINT_SVR_ROUTINE)GpioIsr,
  94.                               (PVOID)KEY_NUM);
  95.     API_GpioFree(KEY_NUM);

  97.     API_WorkQueueDelete(_G_pvWorkQueue);

  99.     printk("interrupt_module exit!\n");
  100. }


    • Related Articles

    • SylixOS 串口中断

      问：SylixOS 的串口在收到几个字节后就能给出中断？如，串口收到一个字符，这个时候会立即给出中断吗还是像龙芯手册中写的，得等4个空闲周期后再给出中断？ 答：这个和处理器及中断控制器相关， 默认1字节就会触发中断； 这个要看CPU的串口是怎么处理的， 龙芯芯片手册说的要等空闲周期那就是要等空闲时间 。

    • 用户 GPIO 中断实现

      Q：用户 GPIO 中断实现应用 1. 应用场景 经常有用户会提到这样的使用方式：定义一个周期性的 GPIO 中断，应用层收到该中断信号后做出相应的动作，按照目前的情况来看，这种使用方式不外乎两种，一是直接使用片内或者外扩的具备中断功能的 GPIO 去实现该项功能，二是 GPIO 这一侧的功能使用 FPGA 来实现，定期的去发送某个电平或者上升沿/下降沿，某些用户更习惯将这种方式称之为“秒脉冲”或者“同步中断”。 2. 问题 ...

    • SylixOS 下如何测量中断服务耗时

      功能概要 SylixOS 下可以测量中断服务耗时，分析各中断服务耗时对分析系统实时性和驱动故障等有很大帮助。 操作步骤 1、该功能通过中断中执行钩子函数来实现，会略微增加中断执行时间，所以默认是关闭的。需要使用时，编译前需修改base文件，主要修改为将 /libsylixos/SylixOS/config/ kernel/kernel_cfg.h 中 LW_CFG_INTER_MEASURE_HOOK_EN 宏使能（即置为1） ...

    • SylixOS下的GIC中断实现（基于T3）

      GIC常用寄存器介绍 GICD_CTLR GICv2控制器将中断分为两组。配置对应寄存器可以控制这两组中断的使能与禁能。 GICD_ISENABLERn 中断向量使能寄存器，写入1使能对应的中断向量号，写0没有影响。读取数据表示对应中断向量号的使能状态。每32个中断向量使用一个寄存器位，后续中断向量放在接下来的寄存器地址上。 GICD_ICENABLERn ...

    • 如何使用 QtSerialPort 类库

      Q：如何使用 QtSerialPort 类库 需要修改项目文件（如 HelloWorld 项目的 HelloWorld.pro 文件），加入如如下程序所示的内容。 更多扩展知识见： 参考文章：如何在 Qt5 中使用 SylixOS 串口通信 注：从Qt 5.1开始，Qt 串行端口现在正式成为 Qt 的一部分； ​关于 QtSerialPort 类的进一步使用， 请参考 Qt 官方的 wiki： http://wiki.qt.io/QtSerialPort