一、概述
1.关于zynq7035的ARM处理器一秒能够支持多少次中断触发，需要综合来考虑。需要确定ARM处理器的参数，目前zynq7000系列，使用的双核Cortex-A9处理器。其中主频大概在500MHZ~1GHZ左右，不同的用户配置的主频可能稍微有差别。
2.ARM处理器能够接收触发次数受多个因素影响：
首先，中断处理本省需要的时间，就是中断这个事件触发后，需要保护现场，需要保存上下文，执行中断服务程序ISR,然后ISR中断服务程序完成后，恢复中断上下文等。如果ISR中断服务程序很短，可能每个中断只是需要几十到几百个clock周期即可。
3.举例：如果配置的时钟主频是667MHZ，一个周期大概就是1.5ns，如果中断处理函数执行
需要100个clock，那么处理一个中断需要150ns.那么1s/150ns=6.67百万次中断。这个值是理论上
的最大值，实际情况，由于中断之间的冲突，中断的优先级，cache hit or miss缓存击中击不中这些因素都会降低中断响应效率。
4.除了要考虑ARM中对中断的响应和中断处理函数的处理速度，还需要考虑的一个点就是中断控制器GIC本身的限制。Zynq的GIC通用中断控制器对中断频率也是有影响的，GIC在处理中断分发的时候，如果中断过于频繁，GIC会成为性能瓶颈，因为中断频繁触发，导致系统没有办法处理其他任务，造成系统不稳定。
5.在实际的工程应用中，切记不要频繁的使用中断，一般需要考虑使用DMA方式或者硬件加速方式将CPU的负载能力降下来，较少CPU的负担。
二、影响中断触发极限频率的因素
1.中断的类型
2.中断处理程序ISR的处理速度
3.中断控制器GIC的性能
4.上下文切换速度
5.保存现场，帧栈入栈和出栈的速度。
三、理论计算
1.CPU主频：ARM9-cortex的主频为667MHZ为例
2.中断处理时间：
2.1.最小中断延时，从触发中断到ISR中断服务程序入口的时间：大概为20~30clock(也是硬件自动保存上下文的时间)
2.2.ISR中断服务程序执行时间：这个取决于用户，如果只是简单的几个寄存器操作，例如，关闭中断或者清理中断，那么，这个中断服务程序可能只是需要50~100个clock;
2.3.中断需要的总时间大概为70~130clock,时钟频率以667MHZ为例，那么一次中断需要105~195ns.
3.综上，1秒/105ns,大概最大为9.5百万次中断每秒
四、实际情况计算
1.GIC中断控制器瓶颈
GIC的优先级仲裁和分发延迟增加高频下的拥堵风险；
两次中断的中断间隔需要大于GIC处理一次中断的时间，一般大概几百纳秒；
2.系统总线竞争
目前zynq系统使用AXI总线，频繁的中断，可能导致AXI总线的带宽使用竞争，这个
会对ISR中断服务函数访问外设或者内存的效率有很大的影响。
3.cache缓存或者流水线影响
高频中断可能导致cache访问的抖动，也就是不稳定，会影响hit or miss命中的效率
4.操作系统的开销
如果是linux系统，内核中断处理top-half或者bottom-half的拆分会引入额外的延迟。
五、实际测试值
1.standalone裸机环境：这种情况下编写的ISR中断服务程序（汇编优化+寄存器直接操作）可以达到1~2百万次/每秒
2.linux环境下：受到内核调度和中断屏蔽影响，通道低于50万次/秒。
六、高频中断使用建议
1.硬件辅助：使用PL端的FPGA逻辑实现多次中断合并或者事件的计数，降低CPU中断的频率；
2.使用DMA传输：使用DMA在后台搬动数据，替代CPU中断驱动频率，较少中断次数；
3.轮询模式：针对有些场景，需要权衡响应时间和CPU占用率；
4.不建议使用超高频率中断，对系统的稳定性有很大影响。