I am using an external hardware interrupt in a program. Also in my program is a frequent call to a subroutine to read a sensor. Initially the subroutine was very short and I had no problems with the program. But later I had to make changes to the subroutine so I could use remote control. The new sub was much longer and the program failed. I am pretty sure it is due to the interrupt failing in the longer subroutine. Not working in the subroutine.
Is it possible to make the interrupt work locally in the subroutine? The only other alternative I have is to put the subroutine into my main program each time I wanted to read the sensor which is going to make a very long program because of the frequent calls to read the sensor.
What does that mean?
Would be a lot easier to help if we could actually see your code.
Yes
Make the ISR as short as possible and set a flag only to indicate an interreupt request has been received.
it means the program does not work as the author intended it to and all the signs are suggesting it should work as intended.
Still no idea what the problem is in the code that we can't see...
Why don't you post the code?
The ISR is very short. The length of the subroutine is obviously the problem as the shorter version made the program work as I intended. This flag you are talking about do I set it up in the subroutine and how do I do that?
After an interrupt you are supposed to be returned to the point in the program where you were before the interrupt. This is not happening. The programming was part way through a 'for' statement and I keep getting returned to the start of the 'for' statement. In other words something is stopping the 'for' statement from completing and it must be the interrupt?
Do you seriously think that anyone can help you without seeing your code?
you set a volatile global variable in your ISR:
flag = true;and you check it in your loop or runtime routine and reset it so it can be fired the next time.
if (flag == true)
{
doSomething();
flag = false;
}The sketch is TOP SECRET currently 
A lot of petercl14's questions seem to be like that. Probably again something that is (going to be) patented.
I would need to explain too much about the code if I posted it. Then the replies to explain the code would go on indefinitely and the thread would never end. No one wants that.
Nothing to do with being top secret. If I posted the whole code I would be getting endless questions to explain the code. The thread would go on for ever. Nobody wants that. One problem at a time is the way to go.
Write something you can share that demonstrates the problem.
If you think your functions (no subroutines in C/++) is taking too much time, make fake ones that waste time.
If you think they are too large, make fake large ones.
TBH at this moment I have no idea what you talking about.
a7
Not necessarily, especially if the interrupt does not change any variables that are used in the 'for' statement. Problems like this tend to be either running short of ram, or writing past the end of an array, where the problem can go completely unnoticed until something is changed in the code, which results in a variable being stored in a different location, so that it is now in the particular area in memory that is getting overwritten.
What does that mean? Interrupts run asynchronous to the "normal" code. When the interrupt condition occurs, normal code is paused and the ISR is invoked. Upon proper return from the ISR, normal code is resumed where it left off.
That's the way it works and I'm quite sure that's what is happening (assuming your ISR actually exits properly).
Agreed, nobody wants to look at a bunch of messy, unrelated code. So, you should post an MRE. This is the shortest possible complete code that compiles and demonstrates the problem at hand. Leave out anything extraneous or unrelated to the problem.
Perhaps you can break the seeming deadlock here in your thread by just showing us your complete ISR function code.
Much better to provide zero information so no one can provide any help at all... genius.