I have to receive & analyse 2 different pulse signals using the Mega.
Is it ok to split each pulse to two inputs and use attachInterrupt() to recognize rises & falls by increasing the related counters?
This means:
int.0 - Pulse 1 rise
int.1 - Pulse 1 fall
int.2 - Pulse 2 rise
int.3 - Pulse 2 fall
In case the two rises or two falls happen at the same time, will they be queued up & processed just fine?
The inputs could be either high or low state before pulsing happens depends on the controller.
Do I need to use pull down resistor here or just leave them all floating?
In case the two rises or two falls happen at the same time, will they be queued up & processed just fine?
Both the events will be latched, you won't lose them as long as you handle them before the next edge. But you can of course only service one at a time. The first to be serviced will be the one with the highest priority, immediately (well almost) upon leaving the ISR for that one the ISR for the second one will be called.
Nick, the input state could be preset high or low depends on the ICs (that generates the pulses) before or after the pulses happens.
At one stage, after all pulses are received, the ICs decides the leave all pins High right after the last rise.
What happens to the input if I grounded it by a 10K resistor? Will the pin remains high and no extra interrupt recognized?
Where should I use the code you provided Nick? Once, in setup?
void setup()
{
EIFR = bit (INTF0); // clear flag for interrupt 0
EIFR = bit (INTF1); // clear flag for interrupt 1
attachInterrupt(0, isrA, CHANGE); //Pin D2, enable the interrupt of Phase A detected
attachInterrupt(1, isrB, CHANGE); //Pin D3, enable the interrupt of Phase B detected
Serial.begin(115200);
}
To answer your question, expected results:
A13 B12
A13 B13
if both counters A and B return 13 then this phase is passed, and the counters are reset for next phase.
at fault the counters are increased not as expected here, it's kind of random:
A12 B13
A12 B14
A13 B14
I suspect either the flow of the program is not right or the interrupt routine is interrupted but yet to debug it successfully.
Yes, it is for fault diagnosis even though I did not code in yet.
But by monitoring the oscilloscope, I can confirm the inputs are normal when that wrong reading happens
The fact that you are overshooting 13 makes it clear that your counters are going higher than you expect, quite possibly while you output the messages. Try testing for >= rather than ==.