中断处理

学习是一个迎接挑战和解决困难的过程，人生中没有目标，无法挑战，就失去了人生的乐趣。下面我们就以 MSP430系列单片机为例，说明单片机的学习过程。 　　(1)获取资料 　　以我们的课本为依托，以下面四个网址为参考，基本所有的资料就全了。 　　参考网址：http://www.ti.com.cn/zh-cn/microcontrollers/msp430-ultra-low-power-mcus/overview.html 　　　　　　　http://www.21ic.com/jszt/msp430.htm 　　　　　　　http://www.eepw.com.cn/tech/s/k/MSP430 　　　　　　　http://www.elecfans.com/tags/msp430/ 　　在网上可以找到FET使用指导、MSP430 F1xx系列使用说明和具体单片机芯片的数据说明，可以找到仿真器FET的电路图、实验板电路图、芯片封装知识等大量的实际应用参考电路。有可能找到的资料是英文的，看英文资料是个难点，也是必须要过的坎儿，无论过没过英语4、6都要学会看英文资料的。建议先看完官方的user guide，加上一些其他相关资料，入门就够了。 　　(2)购买仿真器FET和实验电路板，这个我们学校已经有了 　　如果经济条件不错，可以直接购买。自制仿真器FET和实验电路板，这个是个挑战

这里面见到的同步和互斥的概念非常清晰，转载自： http://www.cnblogs.com/King-Gentleman/p/4311582.html 一、进程间通信机制 rt-thread操作系统的IPC（Inter-Process Communication，进程间同步与通信）包含有中断锁、调度器锁、信号量、互斥锁、事件、邮箱、消息队列。其中前5个主要表现为线程间同步，邮箱与消息队列表现为线程间通信。本文主要介绍它们的一些特性及使用场合。 1、中断锁 关闭中断也叫中断锁，是禁止多任务访问临界区最简单的一种方式，即使是在分时操作系统中也是如此。当中断关闭的时候，就意味着当前任务不会被其他事件打断（因为整个系统已经不再响应那些可以触发线程重新调度的外部事件），也就是当前线程不会被抢占，除非这个任务主动放弃了处理器控制权。关闭中断/恢复中断API接口由BSP实现，根据平台的不同其实现方式也大不相同。比如在stm32平台中中断锁机制通过关闭中断函数（rt_base_t rt_hw_interrupt_disable(void)，这个函数用于关闭中断并返回关闭中断前的中断状态。）以及恢复中断函数（void rt_hw_interrupt_enable(rt_base_t level)，恢复调用rt_hw_interrupt_disable()函数前的中断状态）实现。 警告:

2020-02-12 关键字： 在 Linux 内核当中，处理一个中断事件需要知道两件事： 1、中断号码 2、中断处理函数 而在 ARM 中处理中断则需要知道以下四件事： 1、中断源号码 2、初始化中断控制器 3、初始化 CPU 中断功能 4、中断处理函数 获取中断号有以下两种方式： 1、宏定义 通过查询芯片手册上记载的相应中断编号，再经过系统预置的 IRQ_EINT(编号) 来得到中断号。 2、设备树文件 首先查询相应设备树头文件 dtsi，找到我们要用的那个中断组的描述，形如下所示： gpx1: gpx1{ 　　gpio-controller; 　　#gpio-cells = <2>; 　　interrupt-controller; 　　interrupt-parent = <&gic>; 　　interrupts = <0 24 0>, <0 25 0>, <0 26 0>, <0 27 0>, <0 28 0>; 　　#interrupt-cells = <2> }; 上面的 interrupt-controller; 表示以下描述的是和中断控制器相关的信息。 interrupts 描述的是 gpx1 这个节点所要控制或者说使用的中断号列表。 #interrupt-cells 描述的是长度，记住是长度就好了。 其次再在我们自己的 dts 里添加上我们想要的中断信息节点：

修饰静态方法、实例方法、代码块 Synchronized修饰静态方法，对类对象进行加锁，是类锁。 Synchronized修饰实例方法，对方法所属对象进行加锁，是对象锁。 Synchronized修饰代码块时，对一段代码块进行加锁，是对象锁。 /** * synchronized示例 * 1、修饰静态方法 * 2、修饰实例方法 * 3、修饰代码块 */ public class SyncDemo2 { private static int num = 0; /** * 修饰静态方法 */ public static synchronized void count1() { for (int i = 0; i < 100000000; i++) { num++; } } /** * 修饰实例方法 */ public synchronized void count2() { for (int i = 0; i < 100000000; i++) { num++; } } /** * 修饰代码块 * 效果与修饰静态方法相同 */ public void count3() { synchronized(SyncDemo2.class) { for (int i = 0; i < 100000000; i++) { num++; } } } /** * 修饰代码块 * 效果与修饰实例方法相同

文大篇幅引用自HongJie大佬的 一行一行源码分析清楚AbstractQueuedSynchronizer ，这只是一篇简单的个人整理思路和总结（倒垃圾），如果觉得有些难懂的话，不要犹豫也不要疑惑，很明显是我这篇文章的问题，不是你的问题，这时你最好直接转去看HongJie大佬的原文，那个会好懂很多。还是看不懂的话建议隔一段时间再看，然后像我一样写（复制）一篇总结捋一下思路，加油！ AQS 结构 属性 private transient volatile Node head; private transient volatile Node tail; // 这个是最重要的，代表当前锁的状态，0代表没有被占用，大于 0 代表有线程持有当前锁 // 这个值可以大于 1，是因为锁可以重入，每次重入都加上 1 private volatile int state; // 代表当前持有独占锁的线程，举个最重要的使用例子，因为锁可以重入 // reentrantLock.lock()可以嵌套调用多次，所以每次用这个来判断当前线程是否已经拥有了锁 // if (currentThread == getExclusiveOwnerThread()) {state++} private transient Thread exclusiveOwnerThread; 内部类 Node static

前言 Java SDK并发包通过 Lock 和 Condition 两个接口来实现管程，其中Lock用于解决互斥问题，Condition用于解决同步问题。我们需要知道，Java语言本身使用 synchronized 实现了管程的，那么为什么还在SDK中提供另外一种实现呢？欲知为何请看下文。 下面将先阐述再造管程的理由，然后详细介绍Lock和Condition，最后再看实现同步机制时是选择synchronized还是SDK中的管程。 再造管程的理由 Java本就从语言层面实现了管程，然而后面又在SDK中再次现实，这只能说明语言层面的实现的管程有所不足。要说谈synchronized的不足，我们就要要回顾一下 破坏死锁的不可抢占问题 ： 破坏不可抢占条件，需要线程在获取不到锁的情况下主动释放它拥有的资源。当我们使用synchronized的时候，线程是没有办法主动释放它占有的资源的。因为，synchronized在申请不到资源时，会使线程直接进入阻塞状态，而线程进入了阻塞状态就不能主动释放占有的资源。 所以，有没有一种办法可以使得线程处于阻塞状态时也能够响应中断主动释放资源或者获取不到资源的时候不阻塞呢？答案是有的，使用SDK中的管程。 SDK中管程的实现 java.util.concurrent 中的 Lock 接口，提供了如下三种设计思想都可以解决死锁的不可抢占条件： 能够响应中断

（一）中断唤醒 一、实验内容 通过中断唤醒在睡眠模式下的CC2540 二、实验原理 1、系统电源管理（工作方式） （1）全功能模式： 高频晶振（16M或者32M）和低频晶振（32.768K RCOSC/XOSC）全部工作，数字梳理模块正常工作 （2）PM1： 高频晶振（16或者32M）关闭，低频晶振（32.768K RCOSC/XOSC)工作，数字核心模块正常工作。 （3）PM2： 低频晶振（32.768K RCOSC/XOSC)工作，数字核心模块关闭，系统通过 RESET，外部中断或者睡眠计时器溢出 唤醒 （3）PM3： 晶振全部关闭，数字处理核心模块关闭，系统只能通过 RESET或外部中断 唤醒。此模式的功耗最低。 2、LED硬件原理图 3、寄存器配置 PCON(0X87) 系统电源模式控制寄存器 BIT0 置1将强制系统进入SLEEPCMD所指定的电源模式，所有中断信号都可以清除此置位 SLEEPCMD（0XBE) 系统电源模式设定 BIT1：BIT0 00：全功能模式 01：PM1模式 10：PM2模式 11：PM3模式 三、实验代码 #include<ioCC2540.h> //宏定义声明 #define uint unsigned int #define uchar unsigned char #define LED2 P1_1 #define KEY1 P0_0 /

arm对异常(中断)处理过程 1 初始化: :: a 设置中断源，让它可以产生中断 :: b 设置中断控制器(可以屏蔽某个中断，优先级) :: c 设置CPU总开关，(使能中断) 2 执行其他程序:正常程序 3 产生中断:按下按键--->中断控制器--->CPU 4 cpu每执行完一条指令都会检查有无中断/异常产生 5 发现有中断/异常产生，开始处理。对于不同的异常，跳去不同的地址执行程序。这地址上，只是一条跳转指令，跳去执行某个函数(地址)，这个就是异常向量。如下就是异常向量表,对于不同的异常都有一条跳转指令。 (3-5都是硬件强制做的) 6 这些函数做什么事情? :: 软件做的: :: a 保存现场(各种寄存器) :: b 处理异常(中断): :::: 分辨中断源 :::: 再调用不同的处理函数 :: c 恢复现场 --------------------------------------异常向量表------------------------------------- .globl _start _start: b reset ldr pc, _undefined_instruction ldr pc, _software_interrupt ldr pc, _prefetch_abort ldr pc, _data_abort ldr pc, _not_used ldr

https://zhuanlan.zhihu.com/p/58669088 最近做了一些系统和网络调优相关的测试，达到了期望的效果，有些感悟。同时，我也发现知乎上对Linux服务器低延迟技术的讨论比较欠缺（满嘴高并发现象）；或者对现今cpu + 网卡的低延迟潜力认识不足（动辄FPGA现象），比如一篇知乎高赞的介绍FPGA的文章写到“从延迟上讲，网卡把数据包收到 CPU，CPU 再发给网卡，即使使用 DPDK 这样高性能的数据包处理框架，延迟也有 4~5 微秒。更严重的问题是，通用 CPU 的延迟不够稳定。例如当负载较高时，转发延迟可能升到几十微秒甚至更高”，刚好我前几天做过类似的性能测试，发现一个tcp或udp的echo server可以把网卡到网卡的延迟稳定在1微秒以内，不会比FPGA方案慢很多吧？ 因此，我觉得有必要分享下自己的见解。总的来说，我打算分两篇文章讨论相关低延迟技术： 1）系统调优（本文）：一些低延迟相关的Linux系统设置，和一些原则。 2）网络调优： 使用solarflare网卡降低网络IO延迟 。 这里不打算介绍用户空间的延迟优化，因为太广泛了，另外我之前的文章也分享一些解决某类问题的低延迟类库。 说到低延迟，关键点不在低，而在稳定，稳定即可预期，可掌控，其对于诸如高频交易领域来说尤为重要。 而说到Linux的低延迟技术，一个不能不提的词是"kernel

内核态与用户态的理解： 2）特权级 熟悉Unix/Linux系统的人都知道，fork的工作实际上是以系统调用的方式完成相应功能的，具体的工作是由sys_fork负责实施。其实无论是不是Unix或者Linux，对于任何操作系统来说，创建一个新的进程都是属于核心功能，因为它要做很多底层细致地工作，消耗系统的物理资源，比如分配物理内存，从父进程拷贝相关信息，拷贝设置页目录页表等等，这些显然不能随便让哪个程序就能去做，于是就自然引出特权级别的概念，显然，最关键性的权力必须由高特权级的程序来执行，这样才可以做到集中管理，减少有限资源的访问和使用冲突。 特权级显然是非常有效的管理和控制程序执行的手段，因此在硬件上对特权级做了很多支持，就Intel x86架构的CPU来说一共有0~3四个特权级，0级最高，3级最低，硬件上在执行每条指令时都会对指令所具有的特权级做相应的检查，相关的概念有CPL、DPL和RPL，这里不再过多阐述。硬件已经提供了一套特权级使用的相关机制，软件自然就是好好利用的问题，这属于操作系统要做的事情，对于Unix/Linux来说，只使用了0级特权级和3级特权级。也就是说在Unix/Linux系统中，一条工作在0级特权级的指令具有了CPU能提供的最高权力，而一条工作在3级特权级的指令具有CPU提供的最低或者说最基本权力。 3）用户态和内核态