Non-maskable interrupts

Am I right in concluding that the AVRs don't have an NMI? Well, reset is non-maskable I guess but that's not the way I mean.

I have an application where I need to use an incremental encoder to generate an interrupt every degree of rotation. At 1000 RPM that's one degree every 166 usec and as everything depends on not EVER missing a degree and there is a fair amount of computing going on during the ISR, it's imperative that it not be interrupted.

I probably need to use another processor anyway because I'm not sure there is enough internal ram to do the job but it's tempting to try to prototype it on the Arduino.

Any ideas?

I think the watchdog can be made NMI-able by fuse settings. It's been a while since I looked.

You can always re-enable interrupts at the beginning of your ISR's (carefully!) to make sure you don't miss another interrupt source.

166usec is a reasonably long time. It might work.

Luminary Micro makes some neat ARM-based micros with built-in hardware quadrature encoders. Might be less of a square peg in a round hole than a pokey AVR :-)

Can you make the signal a level with reset rather than a pulse? The processor supports level interrupts on some (most?) pins. So long as no interrupt handler takes longer than 2*166 usec (minus a bit) no degree will be missed.

However, there will be a delay handling the event up to the longest interrupt service routine. Is it critical that events are processed "quickly"?

A little background material will probably help at this point.

I'm trying to recreate an instrument from the 70s that was packaged in a 19" rackmount case. It had a 5" CRT display and a membrane keypad on the front panel. The 32 x 16 character display had the same pixel resolution as the nintendo ds so I had hoped to hack that display and use its touchscreen as a soft keypad. I thought it would be fun to reduce the size to a small hobby box just to demonstrate how things have changed in 30 years.

That instrument did everything with a 1 MHz Motorola 6809 processor so I don't think "pokey" is an issue, rather maybe architecture. :)

Since rotational direction wasn't an issue, a quadrature encoder wouldn't really be necessary. The most important thing is to be able to capture and store 360 or 720 12-bit pressure values at a time and store them long enough to integrate them mathematically with another nonlinear function that can be table driven. The calculation doesn't have to happen during the ISR although nowadays it probably could be done quite handily with a processor that had a multiply and accumulate instruction.

I'm probably pushing the limits of an AVR, but it was a thought. :-/

CB, it's only critical that the sample that has to be a/d converted and stored during the 166 usec not be missed. There is some other stuff that happens like reseting some counters if the degree happens to coincide with the encoder index pulse.

During the pressure sampling, all the other interrupts could be disabled and there wouldn't be a noticeable glitch in the operation but during the rest of the time several other interrupt driven tasks have to not affect what's happening in the NMI ISR or there is a noticeable change in various displays which is not tolerable.

That's why the NMI pin was so nice on the MC6809. You could interleave a lot of slower tasks with a time critical one and not notice any problems.

CB, it's only critical that the sample that has to be a/d converted and stored during the 166 usec not be missed

According to the ATmega328 datasheet, the analog to digital "Conversion Time" is 13 - 260 [ch956]s. Even though there are six input channels, there's only a single converter available. A little bad luck (a few successive long conversions) and the application would overrun the 166 [ch956]s limit.

I'm probably pushing the limits of an AVR, but it was a thought

I think you're right. :'(

Yeah, the application would require 12-bit precision so an external IA, S/H & ADC would be required anyway.

The original instrument would cancel the offset voltage of an attached strain gauge transducer when a “balance” key was pressed. It would do this by summing -(offset) into the instrumentation amplifier using a DAC and an iterative process similar to successive approximation.

You shouldn't "miss" an interrupt unless you have some other code that turns off interrupts for long enough to allow TWO interrupts to go by. If the HW see the appropriate edge of an interrupt while interrupts are otherwise disabled (ie the code is in some other ISR or has done "cli"), the interrupt won't be "missed", it should just be deferred until interrupts are enabled again.

The non-maskable interrupt must be able to interrupt any ISR that might be running when it occurs, run its ISR and then return control to what ever was running when it happened.

The NMI can't be deferred.

Are you saying that interrupts are automatically disabled when any interrupt occurs?

Interrupts are disabled when an interrupt occurs. An interrupt service routine can re-enable interrupts but I don't believe any of the Arduino interrupt service routines do that.

As far as I can tell, the only non-maskable interrupt is reset.

That's what I thought. That's not the same as true NMI.

Reset can be disabled as well.

Correct: there is no NMI on the AVR chips, and despite the vectoring for interrupts, interrupts are globally disabled when any interrupt occurs. You can think of it a having multiple vectors, but only a single "level." (contrast with a 68000, where something that signals an level 3 interrupt would go off to its vector even if a level 4 interrupt were in progress at the time. (or is it the other way around.))

I still don't think you need an NMI for the described application...

Yes, the Motorola processors are very well behaved. They have a nice orthogonal instruction set as well.

The data acquisition that is performed at each degree of crank angle rotation is very phase sensitive and the accuracy of the measurement cannot tolerate missing a degree. Consequently, either it must be performed in a tight polling loop or if done in an ISR it can be the only interrupt. In either case, the human interface suffers with missed keystrokes and flickering display.

If you have a way that satisfies both criteria, I'm all ears.

Would you mind using two processors?

For what you've described, that kind of defeats the purpose but it's worth asking just in case.

You bet, I'm all about distributed processing. I had actually been thinking along those lines. That would make things pretty simple.

The original had a 256x192 crt display. That happens to be exactly the same as the Nintendo DS which also has a touch screen. Unfortunately, I haven't seen any information about hacking that display.

Any ideas?

About hacking the display or building the distributed system?

I'm about to go out for the evening so I won't be able to engage in a real time dialog but I was referring to hacking the display.


That one is way beyond me! I'd be lucky to get the thing properly powered!

I hope you enjoy your evening! I'll be spending my evening in battle with an obstinate puppy.