在 ISR 中，编写要执行的代码。ISR 可以执行任何类型的数据操作或控制任务。例如，ISR 可以更新显示器或控制电机。(在is lm模型中is曲线上的每一点所对应的是)

ISR 是在发生中断时被调用的特定类型的程序。中断是由硬件事件触发的，例如外部设备发出中断信号或发生故障。当发生中断时，CPU 会停止执行当前程序，并跳到 ISR。

ISR 中执行的代码

ISR 可以执行任何类型的数据操作或控制任务。以下是 ISR 常用的一些任务示例：

更新显示器控制电机读写 I/O 设备处理数据响应错误条件

ISR 的组成部分

ISR 通常包含以下组成部分：

中断请求 (IRQ)：中断的唯一标识符。ISR 入口点：ISR 执行的入口点地址。ISR 代码：ISR 执行的实际代码。ISR 退出点：ISR 执行完成并返回到主程序的地址。

ISR 的执行

当发生中断时，以下步骤将发生：

1. CPU 停止执行当前程序。 2. CPU 将当前程序计数器 (PC) 和程序状态字 (PSW) 压入栈中。 3. CPU 将 IRQ 加载到 PC 中。 4. CPU 开始执行 ISR。 5. ISR 执行其任务。 6. ISR 将 IRQ 从 PC 中弹出。 7. CPU 从栈中弹出 PC 和 PSW。 8. CPU 继续执行当前程序。

ISR 的优先级

ISR 通常具有不同的优先级。高优先级 ISR 将比低优先级 ISR 先执行。ISR 的优先级通常由硬件或操作系统决定。

ISR 的优化

ISR 性能对于实时系统至关重要。以下是一些优化 ISR 的技巧：

保持 ISR 简短：ISR 应该尽可能短，以减少中断延迟。避免使用阻塞调用：ISR 中不应包含任何阻塞调用，因为它们会延迟 ISR 的执行。使用汇编语言：汇编语言可以提供比高级语言更高的性能，这对于时间关键的 ISR 非常重要。

总结

ISR 在实时系统中扮演着至关重要的角色，它们允许响应外部事件并执行必要的任务。通过了解 ISR 的组成部分、执行和优化技术，您可以创建高效的 ISR，从而提高系统的整体性能和可靠性。

附加资源

编写中断服务例程 用 ARM Cortex-M 微控制器编写高效的中断服务例程

---

在经过一些测试之后，研究了一个解决方案。 考虑如下文件输入流的代码，FileInputStream fis =null;InputStreamReader isr =null;BufferedReader br =null;File f =newFile(fn);fis =newFileInputStream(f);isr =newInputStreamReader(fis, UTF-8);br =newBufferedReader(isr);推测执行原理如下，（都是根据测试结果的猜测）1。 fis 根据文件的保存编码来采用不同的编码读取文件。 读取结果为byte[]设定的话，那么根据isr设定的编码来读取文件，如果不设定，那么编码采用系统默认编码 ansi(window-31j,shift_jis)3。 ，将isr的结果组合为String,如果isr没有设定编码，那么组合String时采用的编码为系统默认编码 ansi(window-31j,shift_jis)，如果isr设定了编码，那么采用isr设定好的编码。 4。 new string(byte[],encode) 根据指定编码生成string,如果不指定，采用系统默认编码。 系统默认编码 ansi5。 (encode) 从String根据特定的编码取得byte[]问题出在第1步，第一步fis因为读取文件的时候，调用的是native，也就是系统（windows系统）的东西，他用了系统的东西，系统的这个东西作了编码判断，但是因为他调用的是native的东西，这个判定结果没有返回给java，导致java里面isr,br没有办法跟fis协调一致，isr,br只能采用系统默认编码 ansi(window-31j,shift_jis)，而不是采用fis的判定结果来读取文件。 这导致了，当文件使用ansi编码保存的时候，默认编码跟fis判定结果一致，不会出任何问题。 当文件使用了utf-8编码的时候，默认编码ansi,跟fis判定结果utf-8不一致，fis采用uft-8编码读取出文件内容，而后，采用系统默认编码把UTF-8编码对应的byte[]组合成了ansi编码对应的字符串，就产生了乱码。 我在网络以及java api里面查找了一下，没有找到判定文件保存编码的方法。 推论：因为java是调用了native的方法来实际读取文件的，判定在native里面完成，但是没有把判定结果公开给我们程序员。 另有一个测试结果的推论，英文字符在任何编码下面读取出来的byte[]都是一样的。 因为我们才用任何编码都不会出现英文字符乱码的问题，所以大多数时候这个判定对我们没有影响，这里不讨论特殊情况下因为这个原因造成的影响。 根据以上推论，考虑如下解决问题的思路，1。 通过fis来读取文件，这个时候读取来的byte[]根据文件的保存格式是不同的。 fis会自动判断处理。 2。 通过br来读取文件。 代码示例如下：privatestaticvoidreadTest(String fn){BufferedReader br =null;InputStreamReader isr =null;FileInputStream fis =null;try{File f =newFile(fn);fis =newFileInputStream(f);isr =newInputStreamReader(fis, UTF-8);br =newBufferedReader(isr);String s =null;while((s = ()) !=null) {byte[] buf = (UTF-8);for(intj=0; j<; j++){(buf[j]);}}}catch(Exception e){();}finally{try{();();}catch(Exception e){();}}}3。 1，2的读取结果byte[]进行比较，如果相同，那么可以认为文件的保存格式为UTF-8（虽然存在全英文ansi保存的可能，但是这种状况认为是utf-8保存不会有影响）,如果不同则不是UTF-8,考虑我们目前状况，那么不是UTF-8可以认为文件保存编码就是ANSI，如果不可以这么认为，其他编码类型也要做这个判断。 因为英文字符在任何编码下面读取出来的byte[]都是一样的。 所以这里有一个效率问题，必须文件内容全部比较，不能只比较一部分。 以上推测经测试有效，没有问题。 如果使用第三方开源代码的话，可以将以上思路简化为如下代码。 publicbooleanisUTF8(File file){try{byte[] buf = (file);String filecCntent = (file,UTF-8);if((newString(buf,UTF-8))){returntrue;}}catch(IOException e) {//TODO動生成された catch ブロック这个判定有一个效率问题，在这个文章中采用的是读取整个文件，如果我们文件太大，会比较花时间。 这种情况可以考虑按行来读取判定，某一行不一致就可以退出了。 这样可以提高一些效率。