dkulinski:
The reason to keep the ISRs short is that other interrupts are disabled until the current one completes. So if you had both shooters hit at almost the same time you may miss the second hit. Also, the reason A displays junk in the older code could be due to the A_hits not being initialized. Really if you worked around that in single shooter mode you are good.Dan
I forgot that the millis() function might get sidelined by the ISRs. Still the (potential) loss of a few msecs over the course should be inconsequential given the display resolution of 10 msec. The ISR now is :
void ISR_A()
{
// store the hit time
A_Times[A_count] = millis() - StartTime;
// increment the hit count and array index
++A_count;
// set the Hit flag so other stuff will update
AupDtFlag = 1;
}
If I remove the start time subtraction, it’s pretty minimal. Then as you proposed I could put a hit count comparison in the background processing (to detect that a hit has occured) and remove the update flag. Then it’s a minimized as possible.
The last version of the project detached and attached the interrupts based on the timer state (running/stopped) and timer mode (only A is attached in single shooter mode), so B hits shouldn’t do anything bad now. That said the ClearData() function should have zero’ed all the A (and B) hits so the A display should have read 0 hits and a blank time. This should also be the case for the AvsB hit-by-hit display. Afterall one hit, A or B, is going to happen first in this mode and the resulting display will have that 1’st hit time and the “zero” hit display for the other channel. I guess I’ll wait for sspbass to post a vid of some AvsB trial(s).
EDIT: Hmmm, seems I will need to change the AvsB hit-by-hit display. Because arrays are zero indexed, the A_Times[A_count-1] goes off the reservation with 0 hits. This explains the odd display in the last vid.