You would have to have a separate flow chart for the interrupt processing. Flowcharts are meant for showing flow of control, and interrupts, by their very nature, are a break in control flow.
通常，中断通过在基于 C 的嵌入式系统中使用“共享”全局变量与“主”函数（或与此相关的其他中断）进行通信。我认为在流程图中表示这一点的明智方法是在处理块之间使用虚线，其中此类“通信”影响程序流程。
Typically interrupts communicate with your "main" function (or other interrupts for that matter) through the use of "shared" global variables in C-based embedded systems. I think a sensible way to represent this in a flow chart is to use a dashed line between processing blocks where such "communications" impact program flow.
I would set up a finite state diagram that represents the normal states of control and the interrupt states; each state would be a block-level element that contained a flowcharty kind of diagram.
Depending on flowchart structure, it would probably make most sense to have the interrupt originate from a node/box that doesn't derive from another, since, by definition, an interrupt doesn't spring from normal software flow (unless it's a software-triggered interrupt). It might make sense to have it on a separate flow chart, or to show it with the rest of the flowchart depending on whether it might trigger behavior in the main flow of the chart.
发布评论
评论（5）
您必须有一个单独的中断处理流程图。流程图用于显示控制流，而中断，就其本质而言，是控制流中的中断。
You would have to have a separate flow chart for the interrupt processing. Flowcharts are meant for showing flow of control, and interrupts, by their very nature, are a break in control flow.
通常，中断通过在基于 C 的嵌入式系统中使用“共享”全局变量与“主”函数（或与此相关的其他中断）进行通信。我认为在流程图中表示这一点的明智方法是在处理块之间使用虚线，其中此类“通信”影响程序流程。
Typically interrupts communicate with your "main" function (or other interrupts for that matter) through the use of "shared" global variables in C-based embedded systems. I think a sensible way to represent this in a flow chart is to use a dashed line between processing blocks where such "communications" impact program flow.
我会建立一个有限状态图来表示控制的正常状态和中断状态；每个状态都是一个包含流程图类型的块级元素。
I would set up a finite state diagram that represents the normal states of control and the interrupt states; each state would be a block-level element that contained a flowcharty kind of diagram.
根据流程图结构，让中断源自一个节点/盒而不是派生自另一个节点/盒可能是最有意义的，因为根据定义，中断不是从正常的软件流中产生的（除非它是一个软件流）触发中断）。将其放在单独的流程图上，或者将其与流程图的其余部分一起显示可能是有意义的，具体取决于它是否可能触发图表主流程中的行为。
Depending on flowchart structure, it would probably make most sense to have the interrupt originate from a node/box that doesn't derive from another, since, by definition, an interrupt doesn't spring from normal software flow (unless it's a software-triggered interrupt). It might make sense to have it on a separate flow chart, or to show it with the rest of the flowchart depending on whether it might trigger behavior in the main flow of the chart.
通常，在没有任务操作系统或库的情况下，中断只是标记一个变量，然后影响流程。我认为@JustJeff 说得对。
Usually, without a tasking OS or library, the interrupts just flag a variable that then effects the flow. I think @JustJeff has it right.