标签: interrupt

完整版链接：http://www.hongketest.com/portal.php?mod=view&aid=59 1. 概要 本篇文章主要介绍在 FPGA 设计中如何使用本 GXFPGA 驱动创建一个中断事件 / 请求 。 2. 简介 中断作为硬件与软件握手和同步的手段而被广泛使用，可用于表示硬件进程的完成或软件执行过程中的请求。 Gx3500 & GX3700/GX3700e 用户可编程 FPGA 板卡都支持这一特性，并向 FPGA 设计者开放专用的硬件中断引脚；软件方面，三个 API 函数用于中断管理和设置。 在开始编程设计之前，请进行以下准备： l 检查并更新 Gx3500 & GX3700/GX3700e 最新固件。 FPGA 包含设备的核心固件， FPGA 版本必须为 B003 及其以上。使用 虚拟软面板 （ GxFpgaPanel.exe ）对 GX3500 进行初始化后，点击 About 按钮，点击 Upgrade Firmware 按钮，然后浏览选择用于更新的固件文件（ .RPD 文件）。 l 检查并安装最新的 GXFPGA （ .exe ） 驱动 （ 1.2 或更高版本）。 3. 软件 用户可以 以下两种方式中选择一种方式处理硬件中断： l 无论中断事件 / 请求何时发生，都调用回调（ callback ）函数（ GxFpgaSetEvent ）。 l 等待，直到中断事件 / 请求发生或超时（ GxFpgaWaitOnEvent ） 3.1 GxFpgaSetEvent GxFpgaSetEvent(SHORT nHandle, SHORT nEventType, BOOL bEnable, Gt_EventCallback procCallback, PVOID pvUserData, PSHORT pnStatus) 此函数用于控制是否捕捉中断事件 / 请求，并设置用于处理中断事件 / 请求的回调函数。 nEventType ：捕捉的事件 / 请求类型。通常此值必须设置为 GT_EVENT_INTERRUPT 。 bEnable ：布尔量，控制启用或关闭中断事件 / 请求的创建。 procCallBack ：一个回调函数（函数指针）。 pvUserData ：一个指向用户数据（标量或结构体）的指针，在中断事件 / 请求发生时，会传递给回调函数。 注意： 回调函数原型必须符合以下形式，函数名可以任意。 GxFpgaCallBack(SHORT nHandle, SHORT nEventType, PVOID pvUserData) 3.2 GxFpgaWaitOnEvent GxFpgaWaitOnEvent(SHORT nHandle, SHORT nEventType, LONG lTimeout, PSHORT pnStatus) 此函数会阻止程序的执行，并等待中断事件 / 请求的发生。 nEventType ：捕捉的事件 / 请求类型。通常此值必须设置为 GT_EVENT_INTERRUPT 。 lTimeout ：超时（ ms ），用于设置等待中断事件 / 请求的时间，若在此时间内中断事件 / 请求没有发生则继续执行程序。 3.3 GxFpgaDiscardEvents GxFpgaDiscardEvents(SHORT nHandle, SHORT nEventType, PSHORT pnStatus) 此函数用于清除所有挂起的中断请求。 nEventType ：捕捉的事件 / 请求类型。通常此值必须设置为 GT_EVENT_INTERRUPT 。 4. 硬件 在进行 FPGA 设计时，可使用 IRQ （见 GX3500 用户手册 或 GX3700/GX3700e 用户手册 的 Pin Assignment Table ）引脚创建一个硬件中断事件 / 请求。 IRQ 引脚输入信号为上升沿时，创建中断事件 / 请求 5. 例程 / 范例 GXFPGA 驱动包含一个例程，演示如何进行中断事件 / 请求编程。参阅 …\GxFpga\Examples\C 文件夹内的 GxFpgaExampleC.cpp 与 GxFpgaExampleIRQx250ms.rpd （ FPGA 设计文件） 。 在例程中，每 250ms 创建一个中断事件 / 请求。

Building predictably reliable systems is the point of engineering. However, most firmware engineers ignore the role of determinism in real-time systems. Few can answer questions like "how can you guarantee that the system won't fail when stressed?" Today's hardware is often cursed with all sorts of nifty speed-enhancers like cache, pipelines, and speculative execution. All of these contribute to execution time uncertainty. The system's performance can vary wildly depending on a lot of hard-to-predict events. An interrupt may occur at any time, and will require at least a partial cache flush. Resuming execution flow means rereading instructions from L2 or memory, which can take a surprisingly long time. A system that is running fine but close to the edge may suddenly crumble in meeting its hard real-time deadlines. Can you really guarantee the highest priority task will complete on time? What if there's a perfect storm of interrupts? Or of bus activity ( DMA or having to yield the bus to another master )? In big systems a task may depend in very complex ways on externalities ( other computers, systems, I/O ) that aren't ready in time. Preemptive multitasking is itself inherently non-deterministic, though techniques like rate-monotonic analysis can mitigate the problem. But RMA requires more analysis than most developers will ever do. Even extremely simple systems that have none of these speed-enhancing features can suffer from serious timing problems. A little bit of C code that looks quite deterministic probably makes calls to the black hole that is the runtime library, which is generally uncharacterized ( in the time domain ) by the vendor. Does that call take a microsecond or a week? No one knows. It's my belief that too many systems "work" due only to divine intervention. Developers chase down the usual procedural bugs and then breathe a sigh of relief that, once again, a miracle has occurred. But all too often that gift from heaven is merely a reprieve, an indulgence, with damnation still possible or even likely when the system experiences unexpected stresses. Or when luck runs out and interrupts bunch up. Unlike most other engineered systems our real-time devices don't have fuses that blow when something goes wrong. Instead of a controlled shutdown or fallback to a less-capable mode, firmware completely collapses in an unpredictable way. What do you do to convince yourself ( at least ) that the system will be reliable in the time domain?