How can I use interrupts and start/stop for a program?

Hello, I've just recently started trying to work with the Arduino nano, and was wondering if anyone had any advice for a better solution of my start and stop. The idea is I want the stop to work immediately, so I wanted it to be an interrupt, the start interrupt may be unnecessary, but I've just added it aswell for now.

basically the main program is in the while(RUN==true) loop, and I wanted the stop to stop it and also change some outputs.

Currently now, I have two problems with the way I did it. first of, from what I undertsand about the while function, this one will after the interrupt complete its last loop before checking RUN. So I risk it being in a position where it will set the outputs off from the desired stop states again. Could the interrupt force the Arduino unit to start from the top of "void loop()" after trigger instead of returning to where it was?

Second, from a programmings point of view, I've had several people telling me to never have anything but constants as global values, so is there a way I could use pointers instead, and keep the RUN a local variable of the loop() function?

const int Start = 2;
const int Stop = 3;
//....
boolean RUN;

void setup(){

analogReference(DEFAULT);
pinMode(Start, INPUT);
pinMode(Stop, INPUT);
//....

attachInterrupt(0, StartUp , RISING);
attachInterrupt(1, ShutDown , RISING);

}

void loop(){

while (RUN == true){

//...... main program

}
}

// Interrupt functions:

void StartUp(){

RUN=true;

}

void ShutDown(){

RUN=false;
digitalWrite(5, 0);

}

Could the interrupt force the Arduino unit to start from the top of "void loop()" after trigger instead of returning to where it was?

No.

I've had several people telling me to never have anything but constants as global values

If it is a constant then it can't be changed. Stop hanging about with idiots.

You do need to add the volatile keyword to the definition. Otherwise, the compiler might not realize that the variable can be changed and stash the value of RUN in a register and never re-load it from memory. Meanwhile the poor intterrupt routines keep changing the memory location in a futile attempt to get noticed.

If it is a constant then it can't be changed. Stop hanging about with idiots.

Well that's the exact point though, to not have changing variables as globals to make the program more comprehensible and easily debugged etc. When going to larger scales (which I guess a micro processor doesn't have the same issues with as larger computer based software). A bit the same reason why they don't want goto.

Which was why I wondered if it could be done by pointers instead, maybe its the best way to do it like this, but I thought I'd hear around first so I don't learn myself bad habbits.

KeithRB:
You do need to add the volatile keyword to the definition. Otherwise, the compiler might not realize that the variable can be changed and stash the value of RUN in a register and never re-load it from memory. Meanwhile the poor intterrupt routines keep changing the memory location in a futile attempt to get noticed.

Thank you, I've added volatile, it doesn't seem to be recognized by the compiler though ( as in changing color or anything ) That's normal?

Well that's the exact point though, to not have changing variables as globals to make the program more comprehensible and easily debugged etc.

OK so my advice has changed to "stop hanging about with software idiots" Yes I know certain situations would call for a minimum of global variables but on an embedded system with only one person doing the coding then it really is not an issue. Some software types would rather have the code "correct" than have it actually work. I have had one or two work for me and they are total idiots.

Which was why I wondered if it could be done by pointers instead,

What exactly do you mean by pointers? There is no point if you just want to implement a global variable, just use one.

it doesn't seem to be recognized by the compiler though ( as in changing color or anything ) That's normal?

Yes that is normal.

Unless your start and stop interrupts are being triggered by pulses that are much shorter than your loop execution time, I don't see why you're using interrupts at all. What is generating the signal changes that are triggering the interrupts?

Grumpy_Mike:

Could the interrupt force the Arduino unit to start from the top of "void loop()" after trigger instead of returning to where it was?

No.

Couldn't he just put the whole damn code into a for-loop, and break it "after trigger"?

Global variables can be mis-used or over-used, but they exist for a reason. Don't be afraid to use them. My general rule of thumb is that if a given function will always be called with the exact same parameters, then it is probably okay to just go ahead and use a global. For example, let's say I have a boolean variable that tracks a certain state in my program, and I have a function that depends on the state of that specific variable. If the function is 100% specific to that variable and never checks any other variables, then what's the point of passing the variable in as a parameter? The global still has to exist, to hold the state between loops. Just access it.

If you really want to go bonkers with scoping, write object-oriented programming. But for projects on the scale of an Arduino, it's probably a waste of time.

There is just a button that triggers the interrupts, but due to some delays and such in the program, you can in some situations possibly manage to get a keypress done before it reacts to it. In any case I wanted to make sure.

it doesn't seem to be recognized by the compiler though ( as in changing color or anything )

The compiler has got nothing to do with test highlighting.
The compiler does recognise the keyword "volatile".

nedover:
There is just a button that triggers the interrupts, but due to some delays and such in the program, you can in some situations possibly manage to get a keypress done before it reacts to it. In any case I wanted to make sure.

No to make sure you code in such a way as to never use delays.
However, if something is so quick you might miss it the. An interrupt with just the ISR setting a flag or global variable and the. An program clearing it when it sees it will do the job.