ATMega328P How many interrupts per second can it handle?

Me and someone else got into a discussion on an automotive forum about using an arduino to power some digital gauges. One thing I question is arduinos ability to keep up with the data. For example we figured the VSS speed cable could send 30 to 60 pulses per second depending on how fast you are going.

I figured the best way to handle this would be an interrupt. The question is can the ATMega328P handle that many interrupts per second? I know the rest of the code would have to be optimized for performance as well to make sure everything actually worked correctly, but I'm just question from a pure hardware perspective if it could handle it?

Thanks!

60 interrupts per second is very slow for an ATmega328P running at 16 MHz. No problem. You probably don't even need an interrupt to keep up with that rate -- just keep sampling the signal (unless you've got lots of other things going on in your program that might cause you to miss it).

-- The Rugged Motor Driver: two H-bridges, more power than an L298, fully protected

I have a simple project that uses an 8MHz system clock. It has a seven-segment display that is multiplexed directly by the '328P. One of the timers is set to interrupt every 100┬Ás (10kHz interrupt frequency), and the ISR actually manages the display. Now the rest of this project is doing essentially nothing from a CPU load standpoint, just human input via a few buttons, and that is certainly part of the equation as RC noted. But it works great, response to the buttons seems immediate.

Thanks guys, figured it would be able to just wanted to be sure :slight_smile:

And yeah the reason I was thinking interrupts is because there would be other things going on, monitoring other signal cables and such that may be voltage based instead of pulse based, so that is why I was thinking interrupts for pulse based signals would be easier to insure none were missed.

Interrupts make multitasking easier. Interrupts though need to store and then restore registers, polling in a tight loop is the fastest way to monitor something.

At those speeds it should not be a problem, but for more critical timing you might want to look into assembly language. You would have to do all the work, but the cosde can be much faster because you only have to save registers you are really using so the save and restore code can be much shorter. Depending on what else oyu are doing, you might be able to keep each routine in its own set of registers...