I found that many tutorials do not provide correct information about the use of interrupt.

You will see in most examples a timer interrupt is used to turn on the LED or a hardware interrupt is used for the button. I'm sure turning the LED on/off or reading the button is not a time critical task's.

Maybe it's easier to do an interrupt test with a LED/button, so most examples give an example LED/button

 

hi m1,
Perhaps it is not misinformation regarding interrupts, it may be just a simple example on how to Code an interrupt routine.

An interrupt is not a time critical routine, an interrupt is an Event action call.

E

 

What alternatives would you use for those cases?

 

I found that many tutorials do not provide correct information about the use of interrupt.

You will see in most examples a timer interrupt is used to turn on the LED or a hardware interrupt is used for the button. I'm sure turning the LED on/off or reading the button is not a time critical task's.

Maybe it's easier to do an interrupt test with a LED/button, so most examples give an example LED/button

The best use of an interrupt is normally... button press or time slicing... The idea of tutorials is to show how to set them up.. What you do is totally up to you..

 

I found that many tutorials do not provide correct information about the use of interrupt.

You will see in most examples a timer interrupt is used to turn on the LED or a hardware interrupt is used for the button. I'm sure turning the LED on/off or reading the button is not a time critical task's.

Maybe it's easier to do an interrupt test with a LED/button, so most examples give an example LED/button

The entire purpose of interrupts, no matter what you use them for, is to manage _time_. Such a simple mechanism is only limited in its use by the creativity of the programmer to create incredibly powerful systems.

 

There are certain features of interrupt hardware and interrupt service routines that are common to every instance. Using what you might consider a trivial example does require that you understand the common features of all interrupt mechanisms. So when you process a receive interrupt for an incoming Ethernet packet the same principles apply to that situation as the trivial button press. You still have to do things in a prescribed way for everything to work correctly.

 

Pressing a button can be a time critical condition if the micro is doing something at the time where it can't poll the button.

 

A stepping motor activating a limit switch would be the same action as pressing a push button.
Of course such an event is time critical.

Edit: The push button could be an eStop button where someone's life could depend on an immediate abort of the machine.

 

Pressing a button can be a time critical condition

hi,
Define Time Critical, in respect to what.?

E

 

I found that many tutorials do not provide correct information about the use of interrupt.

You will see in most examples a timer interrupt is used to turn on the LED or a hardware interrupt is used for the button. I'm sure turning the LED on/off or reading the button is not a time critical task's.

Maybe it's easier to do an interrupt test with a LED/button, so most examples give an example LED/button

No, grasshopper (I mean this is a nice way). You're sure because you don't really understand interrupt driven asynchronous systems. Let's say you would need an LED to flash X time per second to show the status (state) of computation. Without a simple timer with interrupt turning the LED on/off you would need to include all the baggage of time tracking, LED state tracking, etc... in a polled loop with the computation. Maybe the button switch is a travel limit to hard-stop a motor where the position of the motor is driven by a Time Critical computation. We would need more polled loop baggage in that computation to stop the motor. With a switch button interrupt we could shutdown motor drivers and activate a brake in the time it takes for the ISR to run, not the polling time between switch checks inside some polled loop with the computation.

https://users.ece.utexas.edu/~valvano/Volume1/E-Book/C12_Interrupts.htm

 

The subsets can have code style for it's application but the language used must be compatible with processor's machine code and the hardware.
An example of a lower level language requesting CPU 0 handle an interrupt. It could be misleading if the language's library is not compatible.
https://www.qnx.com/developers/docs/6.5.0SP1.update/com.qnx.doc.neutrino_prog/inthandler.html

 

I guess that you need to ask yourself - Is this text making a real world product to be sold, or teaching me about an interrupt module?

When teaching a concept it is quite common to choose an impractical example that is very simple so that the thing being taught can be processed in isolation to all other problems.

For example: A timer interrupt can be used to drive a PWM output; but to teach a timer interrupt using PWM, it would also have be taught in conjunction (or prior) to the interrupt module.

If a student then struggles with PWM, they are not going to be able to fully absorb the original thing being taught.

Also, professional coders usually follow a development process - i.e. Get things working bit by bit and working through each bug as it arises. These trivial examples are what you would usually use.

No one would ever pay for a program that printed "Hello World" to the screen, or made an LED blink, but I bet you that they are the most replicated programs in the world...

So rather than looking for ways to criticise the practically of the examples given, maybe you should be thinking what you can learn from it

Hope that this helps