Does anyone have any visual examples?
views:
426answers:
5
+3
A:
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.
JustJeff
2010-03-27 14:21:56
Ok, the interrupt processing is a separated process. But how can I represent it in the main process, for example?
O Engenheiro
2010-03-31 16:46:38
well, that's the thing - if the main process is free running, you don't know where it will be when the interrupt occurs. With some embedded real-time applications you sometimes see 'main processing' synchronized to an interrupt, in which case your flowchart might have a 'wait for interrupt' block, but conversely you could argue that in such systems the entire system is just a sophisticated interrupt handler.
JustJeff
2010-03-31 22:23:22
A:
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.
Paul Nathan
2010-03-27 14:25:09
A:
Usually, without a tasking OS or library, the interrupts just flag a variable that then effects the flow. I think @JustJeff has it right.
kenny
2010-03-30 01:02:33
A:
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.
James Snyder
2010-05-03 04:50:09
+2
A:
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.
vicatcu
2010-05-03 18:49:37