AVR Freaks

From one AVR datasheet, Mega16A:

There are basically two types of interrupts. The first type is triggered by an event that sets the
Interrupt Flag. For these interrupts, the Program Counter is vectored to the actual Interrupt Vector in order to execute the interrupt handling routine, and hardware clears the corresponding
Interrupt Flag. Interrupt Flags can also be cleared by writing a logic one to the flag bit position(s)
to be cleared. If an interrupt condition occurs while the corresponding interrupt enable bit is
cleared, the Interrupt Flag will be set and remembered until the interrupt is enabled, or the flag is
cleared by software. Similarly, if one or more interrupt conditions occur while the Global Interrupt
Enable bit is cleared, the corresponding Interrupt Flag(s) will be set and remembered until the
global interrupt enable bit is set, and will then be executed by order of priority.

The second type of interrupts will trigger as long as the interrupt condition is present. These
interrupts do not necessarily have Interrupt Flags. If the interrupt condition disappears before the
interrupt is enabled, the interrupt will not be triggered
 

Now, I'm a veteran AVR8 user.  But I have to think about that "second type of interrupts".  Yes, there are those that are level-triggered.  Which >>do not<< have flags?!?  Let's peek at the Mega16A vector table, and see if we can find any:

Table 11-1. Reset and Interrupt Vectors

Vector No.	Program Address(2)	Source	Interrupt Definition
1	$000(1)	RESET	External Pin, Power-on Reset, Brown-out Reset, Watchdog Reset, and JTAG AVR Reset
2	$002	INT0	External Interrupt Request 0
3	$004	INT1	External Interrupt Request 1
4	$006	TIMER2 COMP	Timer/Counter2 Compare Match
5	$008	TIMER2 OVF	Timer/Counter2 Overflow
6	$00A	TIMER1 CAPT	Timer/Counter1 Capture Event
7	$00C	TIMER1 COMPA	Timer/Counter1 Compare Match A
8	$00E	TIMER1 COMPB	Timer/Counter1 Compare Match B
9	$010	TIMER1 OVF	Timer/Counter1 Overflow
10	$012	TIMER0 OVF	Timer/Counter0 Overflow
11	$014	SPI, STC	Serial Transfer Complete
12	$016	USART, RXC	USART, Rx Complete
13	$018	USART, UDRE	USART Data Register Empty
14	$01A	USART, TXC	USART, Tx Complete
15	$01C	ADC	ADC Conversion Complete
16	$01E	EE_RDY	EEPROM Ready
17	$020	ANA_COMP	Analog Comparator
18	$022	TWI	Two-wire Serial Interface
19	$024	INT2	External Interrupt Request 2
20	$026	TIMER0 COMP	Timer/Counter0 Compare Match
21	$028	SPM_RDY	Store Program Memory Ready

 

I guess that while UDRE is described as a "flag", it could/would fall into that second category -- if it goes away then the corresponding enabled interrupt wouldn't fire.  Hmmm--how could that happen?  I guess code could load UDR when interrupts are disabled.  Then, a set UDRE would clear, and the interrupt would not fire when re-enabled.

EE_RDY and SPM_RDY?  I guess those would fit the bill.

None of the above directly apply to your query.  And in a quick scan I think all the others have "conventional" 'sticky' interrupt event flags.

Well, yeah -- but that is still an [the?] important piece of information w.r.t. your query.

the led's have pretty tight timings and interrupts kinda screw it over.

Then use a small, dedicated, chip to drive the LEDs that request the data from the master when ready.

In the process of finishing off (at last) a project that has 5m LED strips with 300 LEDs per strip, about 14,000 LEDs altogether. A beaglebone board is used to drive them, the chip used has 2 PRUs that are basic 200MHz processors, these talk to the LEDs and grab the data after sending out the packets.

A similar thing can be done with AVRs, one or more small chip with enough RAM to hold the packet and maybe communicate with the master via SPI.

But yes, interrupts are a no-no while the packet is being sent.