I have some general questions about interrupts (specifically the hardware interrupts on a mega 2560).
What happens if an interrupt occurs on a pin whilst an interrupt is already being handled on another? i.e. one interrupt interrupts another.
I assume the idea behind interrupts is to do the absolute minimum of coding within the interrupt to avoid the above happening?
If interrupts do 'clash' what would be the external symptoms (as far as the rest of the code is concerned)?
I have a project that currently uses 4 of the 6 available interrupts and I'm thinking of using another two. I'm concerned that some of the interrupts may be happening very quickly and might be effecting the performance of the rest of the code. I have one interrupt that only experiences a single interrupt per second, but I have another (connected to a wind-speed meter) that has to handle about 300 interrupts per second. Could this high-frequency be causing problems (especially when the wind speed increases and the resulting interrupt frequency goes up). If it is causing a problem what would the symptoms be?
In general, most of my interrupts simply record the moment of their occurrence in an array, another function will then test the contents of that array to derive speed/frequency information.
What happens if an interrupt occurs on a pin whilst an interrupt is already being handled on another?
Interrupts are disabled while an interrupt service routine is running. An event that would trigger an interrupt is buffered (one instance only for any given interrupt type) and the interrupt happens when the current ISR ends.
I assume the idea behind interrupts is to do the absolute minimum of coding within the interrupt to avoid the above happening?
Right idea; wrong reason.
Could this high-frequency be causing problems (especially when the wind speed increases and the resulting interrupt frequency goes up).
Hard to say without seeing what your interrupt service routine looks like.
300 interrupts per second is hardly high frequency.
Ok, I had no idea what was 'normal' for an interrupt hence my question.
Here's an edited version of the sort of coding I do in my ISR...
const int ARRAY_SIZE=6; // Size of array that holds pulse timestamps
unsigned long _pulse[ARRAY_SIZE]; // array of timestamps of most recent pulses.
void recPulse()
{
// Shift the array of values one step sideways. This will discard _pulse[ARRAY_SIZE] and
// reset _pulse[0] to zero.
arrayShiftUnsignedLong(_pulse,ARRAY_SIZE);
// Load the timestamp for this pulse into the top of the array.
_pulse[0] = millis();
}
void arrayShiftUnsignedLong(unsigned long x[], int size)
{
for (int i = size-1; i >=0; i = i - 1)
{
x[i] = x[i-1];
}
// reset top of array
x[0]=0;
}
Basically, I just record the moment of the most recent interrupt in an array, and discard the oldest one.
I expect my function arrayShiftUnsignedLong() could be improved - but I fear the solution would involve pointers - which always brings me out in a rash!
I use code elsewhere (outside the scope of the ISR) to occasionally interrogate the array to process the intervals between interrupts.
// Shift the array of values one step sideways. This will discard _pulse[ARRAY_SIZE] and
// reset _pulse[0] to zero.
No, it won't. The array size might be ARRAY_SIZE, but there is no ARRAY_SIZE element in that array.
but I fear the solution would involve pointers - which always brings me out in a rash!
You really need to get over this irrational fear of pointers.
A circular array would solve the problem with shifting array elements. All you need to do is keep track of how many elements are in the array, with two index variables - one pointing to the head of the data (the oldest entry) and one pointing to the tail (where the last entry is. When the tail reaches the end of the array, it gets set to 0. Same with head. The valid data in the array is between head and tail, is head is less than tail, and between head and the end of the array and between the beginning of the array and tail, when head is greater than tail.
Re-reading your original post, nothing is actually going wrong at the moment?
Correct - my concern that when that when the windspeed increases so do the rate of interrupts and that might cause problems. Your comment that 300 interrupts wasn't a lot help put my mind at rest on that point.