The ol'man at CPU-Central might end up spending a lot of time waiting for those signals. He might even catch a few winks!
It depends on a couple of factors...
-how large is your program (time-wise)
-how long is the pulse (time-wise)
The shorter your scan time, the more often the ol'man can check for pulses.
The longer the pulse-duration the more likely he is to catch it.
In general, the ol'man needs to be able to "look" at twice the rate that the pulses might occur, and the pulses need to be long enough to be caught.
Bear in mind, the ol'man should watch for the pulse "occurring"... not simply "existing". That is, if the ol'man looks and sees the pulse signal on during this scan and then, on the next scan, looks and sees the pulse signal again... did two pulses happen? Or was it just one long pulse?
You need to watch for the pulse signal GOING ON. As in... it was OFF, now it's ON.
And, of course, like Lefty says, if your input responds slower than the rate of the input signal, then you might...
- never see the input go ON,
- never see the input go OFF (once it goes ON),
- or you might receive what appear to be sporadic pulses.
Timing is everything!
Place yourself in a small world where you can slow time down to as low a rate as you need (rate of time???) so you can "see" whats going on and examine the extreme cases.
A High Speed Counter makes a moot (<--take note, RSD) point out of the question.