How to properly use an interupt in my project

Hi everyone
I am currently working on a 4 man, 90 hour school project, the basic idea is to improve the school cafeteria but i'll not go into too much detail because it's not very interesting...
My part in all this is to put in place a personal RFID badge system, (that is my one and only task, the rest the others are taking care of)
What i wish to accomplish here is a personal card per user, is read by a sensor, which reads the cards ID, sends it to a data base, (i use the term loosly) and allows access to the grub or not via a small motorized tripod.
Here is what i have at my disposal

1- Arduino uno
2- Adafruit PN532 RFID/NFC shield (13.56Mhz)
3- 3x Mifare 1k cards (125khz)

This is my main question, i connot understand why i need to use, or how to use, an interupt function in all this, but i have been told time and time again by my profs that it is the only way to create an effective program. Any tips on using an interupt correctly ?
Any help would be appreciated,

here are some references:

i have been told time and time again by my profs that it is the only way to create an effective program

Tell your profs that they're idiots.
(Loire-Atlantique translation "ce sont des idiots")

the basic idea is to improve the school cafeteria but i'll not go into too much detail because it's not very interesting

I disagree - I've eaten very well in some French school cafeterias. I was even served wine in one!

I second that.

The proper way to use an interrupt, is where it is necessary.

To do that, you must know why it is necessary.

My thoughts.

Ok so here is the advantage of an interupt in my program as far as i can see,
The sensor is always waiting for a tag to come into range, so the best thing would be to interupt the main program when it does so that it can read / send the card UID to the data base,
Please correct me if i am wrong.
That being said, i do really know the best way to implement this, or how it is done.

so the best thing would be to interupt the main program

And the main program is doing . . . what, exactly?

You need to use an interrupt in either of two situations - when the events to be detected happen at high frequency or if the event to be detected is very short lived and might be missed.

A RFID tag coming in range is slow and ponderous by Arduino standards. And if the person wants food they will patiently hold the tag in place for at least 1 second.

Polling to detect the presence of the tag will be more than fast enough and will make the code much easier to develop and debug.

Have a look at planning and implementing a program.

…R

use the shield to give interupt when tag is detected.
this should start up comms with the shield.
then send code to your database

shooter:
use the shield to give interrupt when tag is detected.
this should start up comms with the shield.

How?

You cannot do comms within an interrupt, so that is no use at all.

This is the all-too-common total misunderstanding of an "interrupt" that I detailed.

Paul__B:
How?

You cannot do comms within an interrupt, so that is no use at all.

Interesting. Two people read the same comment, and come to opposite conclusions.

Having a lot of experience with interrupts, I read this as having the card detected interrupt set a flag and return, so that the main loop can then start comms to read the value (a potentially lengthy operation.) This is a perfectly valid use for interrupts.

On the other hand, you read it that the comms would be performed within the interrupt handler itself, which is certainly doomed for failure.

I wonder which one of us is right? And more importantly, I wonder how the OP interpreted the suggestion?

I read this as having the card detected interrupt set a flag and return, so that the main loop can then start comms to read the value (a potentially lengthy operation.) This is a perfectly valid use for interrupts.

Given that the main loop is unlikely to be doing anything else, it's simply an example of indirect or deferred polling.

AWOL:
Given that the main loop is unlikely to be doing anything else, it's simply an example of indirect or deferred polling.

True, except if there are occasional periods of processing that might take longer than the interrupting signal is active. Although, given the limited scope of this particular project, that's not very likely.

ShapeShifter:
True, except if there are occasional periods of processing that might take longer than the interrupting signal is active. Although, given the limited scope of this particular project, that's not very likely.

Nor is it likely for the vast majority of applications unless people write really shoddy code (such as using "delay()" :astonished: ), which was and is the basis for my latter comment.

I guess we agree to disagree. I don't seem to be as afraid of interrupts as you are. Perhaps that's because I'm looking at it with 30 years of complex embedded programming in military, medical, and commercial applications: if I had to poll for everything, the code would look really ugly. I'm very thankful there are interrupts available for serial, I2C, SPI, timers, ADC conversion complete, critical signal timing detection, power failure detection, etc., I really wouldn't want to try a complex system without them.

But I will agree that these systems I develop, which are many thousands of lines of code and can fill a MB of program memory and 128 MB of RAM, are not in the same class as the typical Arduino sketches that are discussed on this forum. While lots of interrupts are already used behind the scenes (Serial, SoftwareSerial pin change, timers) and most applications here don't need additional interrupts, I don't believe it is a sign of shoddy programming if someone wants to use one. Yes, it's an advanced topic, and not something a rank beginner programmer should attempt. But the Arduino is a learning platform, and I think it's a disservice to jump on everybody who wants to learn the more advanced topics. It's good to suggest other ways to do it, but just because someone wants to implement something in a different manner than you would do it, doesn't inherently make it wrong. (It doesn't make it right, either!)

While not required for an application such as is being discussed, I can see the benefit of using them here as a learning exercise: a simpler application is a great time to learn a more advanced concept. Would you rather that they get in a complex situation where they need an interrupt, and then try to figure it out while they're in over their head? I think it's better to play with those concepts in a simpler controlled environment.

You, sir, are free to disagree. I'm OK with that.

ShapeShifter:
'm looking at it with 30 years of complex embedded programming in military, medical, and commercial applications: if I had to poll for everything, the code would look really ugly.

Hey, the OP isn't trying to build a vending machine for surgeons operating inside a Navy submarine, right? He just wants to read a couple of tags. If his teachers/instructors/whatever wanted him to learn about interrupts, they should have come up with a scenario where interrupts are needed to begin with.

ShapeShifter:
Yes, it’s an advanced topic, and not something a rank beginner programmer should attempt. But the Arduino is a learning platform, and I think it’s a disservice to jump on everybody who wants to learn the more advanced topics.

For me, these sentences cover all the bases.

Of course, if someone wishes to learn how to use interrupts s/he should be (and will be) assisted. But IMHO it would be better to do that in a short program that has no other purpose.

However the reason for discouraging their use is because most questions come from beginners who have no experience of debugging simple code, never mind code that uses interrupts. They are more likely to complete a project successfully and more quickly if they don’t use interrupts and they are much less likely to need pages of assitance from people here.

Separately from all of that is the fact that polling can use less CPU cycles because it does not have the overhead of an interrupt.

…R

330R:
If his teachers/instructors/whatever wanted him to learn about interrupts, they should have come up with a scenario where interrupts are needed to begin with.

And that’s the gist of it right there: his teachers want him to learn about and apply interrupts. Why is everyone second guessing his teacher’s motives and intellect? (Recall, the very first reply called the teacher an idiot.) The teacher has come up with an interesting project that brings in a variety of techniques: communications, interrupts, team development, etc. Is it possible to develop such an application without interrupts? Sure! Is it ludicrous to use interrupts in this application as a teaching tool? Not at all. Just because the application doesn’t fit your narrow definition of a situation that requires interrupts, it doesn’t make the assignment invalid. If the teacher had come up with a sophisticated enough application that could only be accomplished with interrupts, it could easily be far too complicated for a student project and serve to accomplish nothing but cause them to be frustrated and loose interest in programming. When learning, it’s best to start out simple, and then get more complicated as the student’s competency increases.

This sentence bears repeating:

330R:
If his teachers/instructors/whatever wanted him to learn about interrupts, they should have come up with a scenario where interrupts are needed to begin with.

AWOL and Paul__B (and others) have such an aversion to interrupts that I wonder if the teacher could’ve come up with a practical project that requires interrupts, and meets their standards for a worthy project? It would have to be something that could be accomplished by students in a reasonable amount of time, and hold their interest through the whole project without making them feel overwhelmed. What would’ve made you guys happy?

There are multiple valid ways to accomplish programming tasks. Not everything has to be derived from BlinkWithoutDelay.

Robin2:
Of course, if someone wishes to learn how to use interrupts s/he should be (and will be) assisted. But IMHO it would be better to do that in a short program that has no other purpose.

But that’s the whole point! The OP needs to learn about interrupts, and so many people are telling him to forget about it. Where is the help? A short program with no other purpose? Come on, this project is already being ridiculed as being too simple to justify interrupts, and you want it to be even simpler?

However the reason for discouraging their use is because most questions come from beginners who have no experience of debugging simple code, never mind code that uses interrupts. They are more likely to complete a project successfully and more quickly if they don’t use interrupts and they are much less likely to need pages of assitance from people here.

True: if interrupts are not needed, they shouldn’t be used by a rank beginner. But the point of the OP’s assignment is to learn interrupts, and nobody here is willing to help: they would rather question the teacher’s motives.

Separately from all of that is the fact that polling can use less CPU cycles because it does not have the overhead of an interrupt.

Now you’re really clutching at straws to try to justify your point. You previously stated that polling would be more than fast enough, implying that the application isn’t doing anything else at the time, or that a fast response time isn’t important. And now you are saying that efficiently using CPU cycles is important? There are plenty of cycles to spare in this case!

Sitting in a spin loop does not use less CPU cycles than an interrupt routine. It may save a few cycles of response latency over an ISR if it is in a tight spin loop doing nothing else. But as soon as that polling loop is checking whether it’s time to do several things, any latency reduction is out the window once that overall loop takes more cycle than an ISR context save/recall.

And some times, like when running under battery power, it’s actually necessary to minimize the number of clock cycles consumed, since each clock cycle draws a small amount of charge from the battery. In that case, the solution is not to use spin loops to poll a signal, but instead to put that signal on an interrupt so that the processor can be put to sleep between interrupts and save all of those clock cycles.

But all of this bickering back and forth is completely off topic: the assignment is to use interrupts in the project! We should be giving him advice on how to accomplish that goal, not question the teacher’s motives and drive away the student. Has anybody noticed that the OP hasn’t responded in four days? Of course he hasn’t, there isn’t anything helpful here for him!

AWOL and Paul__B (and others) have such an aversion to interrupts

Hell, no.
I love 'em.

I just don't enjoy fishing noobs out of holes they've dug for themselves.

AWOL:
I just don't enjoy fishing noobs out of holes they've dug for themselves.

OK, so if someone is in over their head and is trying to use an interrupt in an inappropriate manner, it makes sense to show him alternatives.

But this is different, and the OP needs to use interrupts as part of the assignment. But you disagree, and instead of helping, you just denigrate the teacher for giving such an assignment? Nice job. :frowning:

AWOL:
Tell your profs that they're idiots.

I would give useful guidance myself, but while I have lots of experience with interrupts on lots of processors, I'm new to Arduino and have never implemented an interrupt on this platform. Rather than say something wrong, I'm not going to say anything, and leave it for those who do have experience on this platform. But those experienced people seem like they would rather bicker than help. In my opinion, it's really rather shameful.

ShapeShifter:
But this is different, and the OP needs to use interrupts as part of the assignment.

Or does he? Interrupts in this case are unnecessary, whataver that particular teacher may think. If our friend there comes up with a solution to the problem that doesn't use interrupts but still works as intended and nonetheless the teacher nags him because "No, no, young man, you were supposed to use interrupts", then that fellow is pretty close to what my definition of an idiot is, too.

Robin2:
Of course, if someone wishes to learn how to use interrupts s/he should be (and will be) assisted. But IMHO it would be better to do that in a short program that has no other purpose.

330R:
Interrupts in this case are unnecessary, whataver that particular teacher may think.

You guys are unreal. Should he learn in a short program with no other purpose? Or should he learn in a complex program that absolutely requires them and he will be in over his head? Is there no middle ground?

330R:
If our friend there comes up with a solution to the problem that doesn't use interrupts but still works as intended and nonetheless the teacher nags him because "No, no, young man, you were supposed to use interrupts", then that fellow is pretty close to what my definition of an idiot is, too.

No, he's not an idiot, he's someone trying to teach a concept. And I actually applaud him for wrapping it up in an interesting assignment, and not some silly minimalist example that fields an interrupt and serves no other purpose.

Suppose you're learning calculus, and you have to integrate a function for an assignment. You could get the answer by printing the function on a piece of paper, cutting out the area under the function, and weighing the piece of paper. You could get the right answer, but would not have learned how to integrate the function. If the teacher gave you a hard time and failed you on the assignment, you would really call him an idiot? What you are proposing is essentially the same scenario.

You are all starting to sound like a bunch of stubborn old fools who snapped to a judgement, and are now back-pedaling trying to defend your position. Ridiculous.

This is out of hand. Someone let me know when ANYBODY on this thread is starting to help the OP. Other than that, this bickering is serving no useful purpose, and I have work that needs to get done...