The diagram is meant to illustrate the question and is not necessarily a real-world circuit.
If pin2 is set up as an interrupt input to make pin5 go HIGH and stay high while another process is running, will this scheme work to reject further interrupt signals and prevent them from pausing or otherwise interfering with the running process?
I've used the principle in hardwired digital circuits but I'm very new to the world of MCUs. What I'm not sure about is whether an output pin can be used to condition an input pin as in this scheme.
I tried to simulate it in Wokwi but it doesn't work with any resistance in series with the input, not even 1 ohm.
Thanks for the reply. Please keep in mind that I'm just an infant as far as programming and MCUs are concerned.
My sketch accepts an interrupt while - and only while - a process is running. At least I know how to do that. How do I reject further interrupt signals after the first (with software)?
This is the barebones of my sketch. Irrelevant parts are snipped out as they are still a work in progress anyway.
void Interrupt ()
{
if (digitalRead(2) == LOW)
{
digitalWrite(5, HIGH); //this serves another purpose besides
//being fed back to lock the input
}
}
void setup()
{
pinMode(2, INPUT); //interrupt2 input
//other pin assignments
attachInterrupt(digitalPinToInterrupt(2), Interrupt, LOW);
}
void loop()
{
noInterrupts();
if (digitalRead(4) == LOW) //Starts process
interrupts(); //Interrupt effective only after start of process
//process during which an interrupt may occur
}
I'm going to take an educated guess here, based on the partial picture you have shared so far.
All that stuff you think you want/need to do: you don't want or need any of it.
You don't need to use interrupts. You don't need any of those resistors or diode. You don't need to use a second pin to control the other pin.
What I think you need to do is share a more complete picture of what you want to achieve and your reasons for it.
I suspect all you need to do is connect the button been a single pin and ground, make sure your code is not blocking, so that is possible to monitor the button while your process is running. If you don't want to monitor the button at other times, control that with a flag variable.
void Interrupt ()
{
digitalWrite(5, HIGH);
detachInterrupt(digitalPinToInterrupt(2));
}
void setup()
{
pinMode(2, INPUT); //interrupt2 input
//other pin assignments
attachInterrupt(digitalPinToInterrupt(2), Interrupt, LOW);
}
void loop()
{
noInterrupts();
if (digitalRead(4) == LOW) //Starts process
{
interrupts(); //Interrupt effective only after start of process
//process during which an interrupt may occur
}
}
I agree with @PaulRB that you should better explain what you want to do, because the logic of the program doesn't seem right.
Thanks. That looks helpful.
The point of this thread is less about one specific project and more about learning how to do things in software. I probably should have made that clearer before.
The interrupt source is not necessarily a button switch. That's just a representation of a high-low input.
So far you're telling me what I don't need to do. Better alternatives are welcome.
As explained in the comment in the partial sketch, that output pin has another job.
This is not about one particular project. I want to learn how to disable an interrupt after it's done its job once. I know that there's more than one way to insert interrupts but so far this is the only one I know for now.
I've been designing electronic circuits for well over 50 years. They range from simple gadgets to highly complex ones in various fields. I'm far more comfortable with hardware than with software. Why I'm just starting to get into software at this late date is a long story.
Perhaps I should have made it clearer that this is not about one particular design. The button switch is just representative of a high/low input.
That's still a bit above my head but I get the drift.
@Pimpom - you may not detect it, but there is healthy skepticism here around the use of interrupts.
You will paint the entire wall however you manage, but you are filling in up to down when instead going left to right might make more sense.
Leave interrupts for when you have a good grasp of the language, and a fair amount of experience coding stuff like we get around to making this little machines do, all without interrupts.
Aside from inadvertently or unwittingly using interrupts because some library uses them, I rarely to almost being able to say never use interrupts.
If you go into interrupts and continue to be creative, you will be off in your own world. Which can work fine but will cause some head shaking on our parts and poss some headaches on yours.
Or after some time you will know how and when to use interrupts, and when to not. That's the time to see how they are used in this context.
Which bit? You seem to have inserted your own words between my words, making it look like I said your words too
If you mean "non-blocking code", this means code that does not hog the CPU for a long period (meaning more than a fraction of a second). When you have only one CPU and no multi-tasking/multi-threading, it's important.
To be non-blocking, your code needs to divide up the processing task into many small steps, each of which takes only a fraction of a second, and also remember what step it got to, so that it can carry on from where it left off. This gives the CPU the chance to do other things, like checking inputs, between the processing steps.
Thanks. Somehow I missed reading your sample code before. Sorry about that. That's exactly the kind of answer I was looking for.
Yes, I'm aware from my experience in other fields that there's almost always a better way to do something. It's just that, when someone replies in a negatively cryptic manner, it's a bit off-putting.
What follows is what it's all about. But I want to stress that it's not just about one project.
About 15 years ago, I built a drag racing "Christmas Tree" for a motorsports association. After carefully researching what was needed, I designed it to comply with FIA and NHRA standards. It was all done with analog and fixed logic hardware. No software. I even added a winner detection system and a circuit racing controller.
It's still going strong. But a recent chat - face-to-face, not online - with some racing enthusiasts makes me want to build another one, this time with a microcontroller. There are plenty of simple countdown systems on the internet but these are more like toys. A full-fledged Christmas Tree system is a bit more complex.
This is the part that's relevant to this thread: Sensors monitor a rider's position at the starting line. It's indicated by lights at the top of the "Tree". Once the countdown starts, if a rider moves even slightly out of position before the GO signal, the sensors detect it, a red light turns on and the rider is disqualified.
And that's where the interrupt (or an alternative) comes in. The foul start (jump start) indication becomes active only after the countdown has started. Once turned on, the red light stays on even if the rider moves back into position.
If an interrupt is used, sustained and repeated sensor signals must be ignored to prevent them from interfering with the countdown. Timings in my 15-year-old design, including the winner detection, were accurate to a fraction of a millisecond.
