When do you think that interrupts become very important

Go To Last Post
38 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

I think We should use interrupt only when it is really needed , interrupt has its own role in any application. I do not have a specific example because I have not yet worked on any major project. I think interrupts are important when we build a large industrial application suppose there is industrial machine does many things approx 100 task and and one of them is fire detection, so when machine detect fire it will shut down automatically. This is my thinking for interrupt  

 

When do you think that interrupts become very important ? Have you worked on such a big project Where the machine was doing multiple tasks and interrupts were used for important tasks 

 

Thank you 

M

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Interrupts become important when they are the best way to achieve a desired goal. It has nothing to do with program complexity or program size. 

 

For example, I have a program for a commercial product that almost fills a Mega328 (32 K flash). This is NOT a big program. It uses a mix of interrupts and polling. Each is used in the way that is best for the application.  For example, in certain sleep modes, interrupts are the only practical way to wake up from sleep. But, in other situations in the same program, I poll external inputs, timer status bits, uart status bits, and others, each as is best for the program.

 

So, clearly, if your device needs to sleep, even if the program is not at all large or complex, you almost HAVE to use interrupts. That is the way it is.

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

ka7ehk wrote:
It has nothing to do with program complexity or program size

Absolutely.

 

Also nothing specifically to do with "industrial application" or "industrial machine"

 

muke12 wrote:
approx 100 task

At that size, you'd be using an (RT)OS - so you wouldn't be dealing directly with low-level stuff like interrupts - the (RT)OS would handle that for you ...

 

muke12 wrote:
I do not have a specific example because I have not yet worked on any major project

Perhaps if you all did start working on some real projects - rather than just idly dumping all these nebulous questions on the forum - things might make more sense:

 

https://www.avrfreaks.net/commen...

 

For some beginner's getting ideas, see: https://www.avrfreaks.net/commen...

 

And Tip #6.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Thu. Apr 16, 2020 - 07:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 3

muke12 wrote:

I think interrupts are important when we build a large industrial application suppose there is industrial machine does many things approx 100 task and and one of them is fire detection, so when machine detect fire it will shut down automatically.

 

Your example is incorrect. Interrupt use has nothing to do with how 'important' a task is but more (usually) how quickly it must happen. Whether a fire detector is serviced after 10ms or 1 second, or even 10 seconds, is irrelevant because fire does not happen that quickly.

 

A better example, using your idea of an industrial machine, would be the situation of a motor overload detector to shut down the machine if something jams inside it. But even then we are talking in the realms of 100ms or more being acceptable. In the real world, physical events do not happen quickly.

 

Things that do happen quickly, and which need interrupts, are things like serial communications where a new byte can easily arrive every 100us. I have something on the bench right now where I need to receive a byte, and transmit a byte every 44us. Plus process the received byte before I can transmit.

 

Many many programs can be written using nothing more than a few simple interrupt handlers to deal with asynchronous events, like serial ports, and buffer them, plus one overall 'tick' interrupt running at 10ms, or even 100ms, to deal with keeping things running smoothly. See Kartman's multitasking tutorial.

 

So, in summary, a blanket statement that interrupts are only needed once a program reaches a certain complexity is wrong. The correct statement is that interrupts are needed when your program design phase shows that they are needed.

 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Brian Fairchild wrote:
design phase

What is this strange sorcery of which you speak?!

 

surprise

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
rather than just idly dumping all these nebulous questions on the forum - things might make more sense:

 

Whatever I thought about interrupts, I said, It's a good thing for me that you rectified my mistake. I have got the benefit of posting my doubt on the forum

We can have interrupts With a fault, 
We can have interrupts with an UART, whenever a byte is receive or a byte is sent 
We can have interrupts with a GPIO whenever an input has changed state 

 

There are no two opinions in this, we can use interrupts as we want. My question was when does it become very important in application 

 


main(){
    while {
            do something ();
            do that ();
            do this ();
             ....
            don't do this();
 }
}

ISR ()
{
    send security alert

}

I am using interrupt for security alert because main routine is busy to complete 100 task in infinite loop   

Last Edited: Thu. Apr 16, 2020 - 08:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

 

awneil wrote:

Brian Fairchild wrote:
design phase

What is this strange sorcery of which you speak?!

 

He's a witch, burn him...

 

 

 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

muke12 wrote:

I am using interrupt for security alert because main routine is busy to complete 100 task in infinite loop   

 

Even then it might not need an interrupt. How quickly must your security alert be sent after being triggered?

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Brian Fairchild wrote:
He's a witch

That's why I had a black cat to help me:

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If it is important that your code flow smoothly forwards with consistent execution time, don't use interrupts (or turn them off).  If it is important that at some point your code must stop doing whatever it's doing to do something else, use interrupts (or turn them on).  It's sorta in the name...  S.

 

PS - If neither, then it doesn't matter.  If both, then get a cat to help you with the design - it'll need help.  wink  S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Just to be awkward... somewhere in the tutorials (I think) there is some code from me which works almost entirely contrary to the normal use of interrupts.

 

There is a common school of thought  which states that interrupts should be used with an absolute minimum of code in them. This is because, absent complex priority schemes, you usually can't do anything else if an interrupt is happening. So, if you need to respond to, say, a serial character arriving, your interrupt routine might respond to the received character and stick it in a buffer. It can then set a flag to say that data is available, and return to normal program code. Why? Because then the standard code can look to see (poll) whether there is a character waiting for it to deal with at a time which is convenient for it. The fast return from the interrupt means another character can arrive quickly, and be placed straight into the buffer.

 

But... I have a video generation program in which the vast majority of the code acts in an interrupt, and only a tiny amount runs in normal mode (and coincidentally, that code is polling a serial port...)

Why? Because generating video is incredibly timing critical. The synchronisation pulses must be of exact length and timing period; the video signal must start an exact time after the sync pulse, and there must be no jitter in the timing; jitter of nanoseconds is easily visible and visually disturbing.

 

And one issue with the AVR is that the response time of the processor to an interrupt is not constant, except in one specific case: when it wakes from sleep. So one way to generate the signals required for video generation is to ensure that the chip is put to sleep just before it must wake up: So, approximate timings here...

- a clock is set to give a timeout every 64us (it's for PAL) and that timeout wakes the chip from sleep with an interrupt

- when the chip wakes, it generates the sync pulse (cycle counting), the delay to the active video (cycle counting), and the line of video information (very careful cycle counting!)

- at the end of the active line (say 48us) the processor returns from the interrupt to the serial polling task

- a second timer times out at 63us or so and the processor goes to sleep

 

So everything happens in the interrupt, because of the tight timing constraint... the processor is either generating syncs and video (around 70% of the time), processing the background task (about 30% of the time) or asleep (about 2% of the time) (yes, that doesn't add up quite). But the interrupt is absolutely essential to maintain the timing that could not otherwise be guaranteed by the background task. It's not a requirement of the complexity, but of the hardware.

 

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

muke12 wrote:
There are no two opinions in this

Oh, there are plenty of opinions ...

 

cheeky

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

barnacle wrote:

...some code from me which works almost entirely contrary to the normal use of interrupts.

 

Same here, in the last six months I have written some code where this is main()...

 

void main(void) {
    
    init_init();
    
    #asm("sei");
    
    while (1) {
        ;
    }
}

 

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One thing not mentioned here is an IRQ can be used for increasing overall program speed (efficiency).   All the time you are not wasting time polling can be used to do actual processing, or allow those non-irq parts of the program to be more high-speed responsive.

 

If you have a power supply failure line you want to respond to within 200 us, you have to poll it at least that often (fast), so you can respond...in a few minutes of processing, millions of polls would have been wastefully executed.    But, the IRQ simply waits for it to happen & immediately triggers...no waste!!!  

 

If someone was delivering a bar of gold sometime in the next 5 days, would you open the front door every 20 seconds to check, or just wait for the doorbell to interrupt your wine drinking?

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Thu. Apr 16, 2020 - 09:16 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've done similar things, when the MCU must do many things on a regular basis, including several possible paths through the code, and EVERYTHING (everything useful, anyhow) is in the timer interrupt.  All I have to do is count cycles to make sure every possible path is short enough that they'll end before the next timer trigger (at 100kHz, so we're not talking hours here...)

 

One minor issue that I think barnacle carefully observed is that

while (1) {};

will generate an 'rjmp' instruction, and a) that's a three-cycle instruction and b) the AVR will complete the instruction before processing the interrupt.  And you don't know which cycle your rjmp is on when the interrupt fires, so you can have up to three cycles of jitter.  Sleep may be much better in that regard.  S.

 

Edited to add:  Okay, it's a 2-cycle instruction.  JMP is three.  But the same jitter applies.  S.

Last Edited: Thu. Apr 16, 2020 - 09:24 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Many large industrial machines are run by PLCs (programmable logic controllers) - many of these do not implement the concept of an interrupt - everything is polled in a sequence.

Why was the concept of an interrupt invented? (there's some research here). What was the first computer to implement interrupts?

 

Rumour has it that interrupts were strictly forbidden in the guidance system for an ICBM. See if you can find references to that.

 

Microchip became a major player in microcontrollers with a microcontroller that didn't have interrupts!

 

You might want to read up on the Therac25 where interrupts caused problems that killed people.

 

After a bit of research and history, you should have a better idea of interrupts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:
All the time you are not wasting time polling can be used to do actual processing

Or can be used to do nothing - ie, put the CPU to sleep ...

 

Kartman wrote:
a microcontroller that didn't have interrupts!

VIPER was another:

 

https://en.wikipedia.org/wiki/VIPER_microprocessor

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The Viper had it's own language - Newspeak. It was double plus good.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

just a comment to #14 :

But, the IRQ simply waits for it to happen & immediately triggers...no waste!!! 

 

In most cases what else to do? (and worst case get even worse!) (Unless you actually can sleep in between then it's an other story)

 

I normally have a timer ISR with 1KHz that is my heartbeat.

So much time does a poll take: 2000 clk a sec or 0,0125% of the time of a 16MHz AVR, and I know where in code I'm at, so some double buffering waste is avoided.

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

avrcandies wrote:

If someone was delivering a bar of gold sometime in the next 5 days, would you open the front door every 20 seconds to check, or just wait for the doorbell to interrupt your wine drinking?

 

Given that a typical government reserve bar is 70lb or so, and at $1.7k / oz...  I'd spend a lot of my time checking the door!!  laugh  S.

 

Edited to add:  Once knew a chap working on a system like that.  It turned out that his particular gas-phase chemical reaction worked a lot better if the gas passed over a 24-karat gold catalyst bed.  The nature of plumbing made the bed circular, and the heart of his machine was about three million bucks worth of carefully formed gold.  I'm told it worked just fine.  S.

Last Edited: Thu. Apr 16, 2020 - 12:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:
He's a witch, burn him...

Or dunk him and if they float, they are a witch...

if they drown, then they are not! 

 

 

Thank you Monte Python! 

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:

Brian Fairchild wrote:
design phase

What is this strange sorcery of which you speak?!

 

surprise

High falutin'  book learnin'  balderdash!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OP, I have written very tiny programs (just a screen or two of code) and they usually use one or more interrupts.  In the embedded world, anything beyond the most basic LED blinky is probably going to have interrupts because interrupts let your system be more responsive and do more useful work, and they can also keep your code much cleaner.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:
I have something on the bench right now where I need to receive a byte, and transmit a byte every 44us
DMX?

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1


joeymorin wrote:

Brian Fairchild wrote:
I have something on the bench right now where I need to receive a byte, and transmit a byte every 44us
DMX?

 

I thought the 44us bit might give it away...

 

 

Fully DMX512A spec compliant transmission working using just 2.8% of processor cycles at 16MHz.

Still to finish the receive side so that I detect proper length breaks and not just rely on framing errors.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What?! You prototype using an UNO?  Do professionals do that?  Of course they do!

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Here is a probably "classic" use for interrupts. Not sure if it rises to the OP's standard of "very important" but it certainly is "very useful".

 

Consider serial data being received with a UART. Many UARTs have only minimal receive buffering. It is common to have one register (a "buffer") for the just-received character and another for a new character that is coming in. The buffer must be read before the next character is complete because, the contents of the  buffer will be replaced by the new character, when it is complete. It is called an "over-run" error when a buffer character is replaced by a new one before it is read. 

 

A common scheme to deal with this uses an interrupt that occurs when a new character has been fully received by a UART. In the service routine, the new character is read from the  UART receive buffer and saved to a much larger one. The larger one is often arranged as a ring buffer, but that is not important, here. The service routine also sets a flag that indicates that one or more new characters is/are available. This arrangement avoids over-run errors, it is "short and sweet", almost in the extreme. And, in many cases, it really simplifies things. The host program can take its time, limited only by the external buffer size and the character rate.

 

All in all, its a very convenient technique. But, "very important"? It might be in some cases, but, in most, its just "bloody handy".

 

Me, I'll usually take it, even if it is not very important. I like handy and useful things that make my life easier. 

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Thu. Apr 16, 2020 - 07:30 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ka7ehk wrote:

Here is a probably "classic" use for interrupts. Not sure if it rises to the OP's standard of "very important" but it certainly is "very useful".

 

Consider serial data being received with a UART. Many UARTs have only minimal receive buffering. It is common to have one register (a "buffer") for the just-received character and another for a new character that is coming in. The buffer must be read before the next character is complete because, the contents of the  buffer will be replaced by the new character, when it is complete. It is called an "over-run" error when a buffer character is replaced by a new one before it is read. 

 

Jim

I have explained this in short post 6 " We can have interrupts with an UART, whenever a byte is receive or a byte is sent " It is understood that all people use it in their own way.

 

Last Edited: Thu. Apr 16, 2020 - 08:00 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My point has to do with the subject title and post #1. 

 

I assert that  "very important" is not a good standard. I say that they should be used where they (interrupts) are helpful. Any time they are helpful. Any time they make sense. And, certainly, any time they are needed. That is a pretty low standard. 

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

Last Edited: Thu. Apr 16, 2020 - 09:41 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian Fairchild wrote:

Fully DMX512A spec compliant transmission working using just 2.8% of processor cycles at 16MHz.

Still to finish the receive side so that I detect proper length breaks and not just rely on framing errors.

Neat!

 

If I ever get around to building it, I'll post my DMX monitor running on an ATtiny4.  I've built a sloppy ATmega328P test, and ported the t4 code over for proof-of-concept and debugging, but I haven't actually built or tested on the intended t4 target.  If this lockdown lasts long enough...

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Having said all this, of course, it is mostly when one is programming on the bare metal - be it microprocessors or microcontrollers - that one sees interrupts. At a higher level, you might never even need to think about them.

 

For example, an event driven program will often do almost the exact opposite of what has been discussed above: the program sits in a loop, waiting for (so effectively polling) events - the mouse has moved; a key has been pressed; a screen update is required etc - and simply won't care about how those events are generated. But hidden away in the operating system you can be pretty sure that there are lots of interrupts going on - active interrupts from a mouse port, a keyboard, or a network device, or things like a system timer that the OS is using to decide when it's time to stop your program running and multitask something else.

 

Neil

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

(oops)

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

barnacle wrote:
At a higher level, you might never even need to think about them.

Absolutely!

 

That was my point here:

in #3, I wrote:

muke12 wrote:

approx 100 task

At that size, you'd be using an (RT)OS - so you wouldn't be dealing directly with low-level stuff like interrupts - the (RT)OS would handle that for you ...

 

In fact, such an (RT)OS would probably prohibit you from directly dealing with interrupts

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Apr 17, 2020 - 08:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In fact, such an (RT)OS would probably prohibit you from directly dealing with interrupts

Yes and no, it will not be called a interrupt, but the task setup you put your code in will do the same.   

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I propose the 'First Law of Interrupts'...

 

"Interrupts shall always be used, especially when you don't understand why you need them. And then, when you do understand why you need them, you can stop using them."

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

seems like the converse of #5 in your signature ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...