I'm not at all with you??? How do I read the coin validator pulses and coin hopper coin ejection pulses accurately without using the interrupts?? Confused.
Presumably the same way you do everything else
. You have a "loop" routine that executes one sub-task after another, attending to any new event
accordingly and passing by otherwise. This loop will generally cycle something of the order of a thousand times a second, it should never
be "busy waiting" for some associated event to happen.
One of the tasks it performs, is de-bouncing - if it detects a change in an input, it makes a note of it in a counter and on each successive pass (though the main
loop), tests whether the change is sustained and if it is for a certain number of passes (advancing the counter) or a certain time elapsed (more accurate), it determines that input (change) to be meaningful. This can
be performed - and must
be performed if the input is a mechanical contact - in a similar fashion if you are using an interrupt routine, but then you still have to use a flag (semaphore) of some sort to communicate with the consequential actions in the main loop.
Interrupts should be reserved for events that are genuinely time--critical. A coin taking tens of milliseconds to fall through a chute is in computer terms
, anything but
I am curious as to whether this coin hopper mechanism is providing the de-bouncing for you, or whether you are in fact employing de-bounce code?
I'm also confused how this working function of the machine is having any impact on this coin fall count we are discussing.
Perhaps, perhaps not, but is likely to be an unnecessary complication as you add more functionality and a potential source of conflicts if for example, on the rare and unpredictable situation that two interrupts just happen
to occur simultaneously and inter-react. This becomes all the more likely when interrupt routines are unnecessarily responding to repeated contact bounce events.