1469_TC275串口字符串输出例程中的中断功能分析
全部学习汇总： GreyZhang/g_TC275: happy hacking for TC275! (github.com)
前面调试hello world的程序以及实现printf的功能的时候，我看到了基础的工程中有个中断配置。接下来，尝试看看这两个中断的功能。因为，一个比较方便的调试工程中最好是带着一个定时器中断，这会是我接下来的hack目标。正好，这里看到的两个中断如果是分析清楚了后面我要是尝试实现定时器中断的时候会比较容易。
这个是我现在的软件工程中的中断声明以及定义，其实还是比较简单的。接下来，应找一下这两个ISR是如何注册实现的。
目前的工程中竟然是没有找到类似的注册接口实现的，那么，这样的中断ISR会能够驱动起来吗？接下来，我得尝试去测试一下了。
现在的软件工程中已经集成了printf，接下来，先利用循环计数器做一个简单的周期调度。
在这个Core0的主函数中的死循环中，加入了这段测试代码，接下来调整这个宏定义看看什么数值可以大概调整出来一个1S左右的周期。
现在，1S左右的输出基本调试出来了，MAIN_LOOP_CNT_MAX的数值最后调整到了6000000。这样看，这个MCU的处理能力的确是非常强劲的。
接下来的测试也简单了，加一个计数器到ISR中，看看是否有变化。
之前做ISR的代码分析的时候，发送中断中已经增加了一个这样的计数器，接下来只需要输出一下即可。
前面的测试代码去掉，在这里换成相关的计数器的数值输出。
这个结果有点让我感到惊奇，因为这个计数器看起来数值增加了。而且，从增加的次数看也并不符合输出字符数目的规律。这么看，中断时发生了，应该是什么地方的注册信息在前面被忽略掉了。检查下来，最大的可能性应该是前面的ISR的定义方式解析出现了问题。
其实，这个定义的展开跟选择的编译器有关。我们现在的编译器是tasking，应该是根据这个编译器的信息进行展开。为了确认编译器是否是按照tasking进行的处理，对相关的文件做一个测试。
Compilers.h中增加上面的信息，然后做一个信息打印。
输出点额数值是3，这说明编译器的确是设置成了tasking，接下来对中断ISR做进一步的分析。
这么看，大概率是按照光标所在的121行进行了定义，进而被展开成了127行的模式。只需要加一个测试就可以判断出来。
对上面的定义进行打印。
通过打印结果可以看得出来判断是准确的。这样，再回到上面的代码看，应该能够看得出来这个中断ISR的定义其实是加了一些属性的。而这样的属性，应该会让ISR生效。
进一步的信息从编译器的手册说明中找到了说明。由此可以看得出来，其实这个中断时默认生效了的。至于具体的实现方式，看起来需要结合工具的手册进一步了解分析一下。
整合了上面的信息之后，多少有些了解了这个ISR的开启实现模式了。
首先，这样的一个声明以及定义会把这个函数与Core0的中断向量表联系起来，而联系的一个绑定信息是中断优先级。那么，中断优先级又如何能够跟ASCLIN的发送动作绑定在一起呢？
答案在这里，驱动的功能中其实也会绑定中断的信息，这两个优先级应该是需要对应起来才能够发挥作用。至于为什么计数器的增加跟字符不相符，其实根据代码的设计也能够分析出来。主要的原因是这个中断的功能，这个工作的意义是FIFO level的中断并不是发送成功的中断，因此这里看不到一个跟字符个数完全匹配的信息。不过，如何添加中断甚至说部分AURIX的中断信息结构算是弄清楚了。