"AVR32101: Configuring the AVR32 Interrupt Controller" is where i got the info about masking. under 2.2.2 Masking it says:
Whenever an interrupt occur, hardware automatically sets the mask bits corresponding to all sources with equal or lower priority.
and under 5.1 Nested interrupts:
As all interrupts with the same and lower priority is automatically masked whenever an interrupt is riggered, lower priority interrupts will not preempt the current running interrupt. An interrupt with a higher priority may nevertheless preempt the current running interrupt and thus nested interrupts is enabled by default.
which seems to imply that when you call
cpu_irq_disable_level it will disable the specified level and anything below. but maybe it's not the case...
going over your changes:
event_post to disable
SYS_IRQ_PRIORITY / removing IRQ masking completely: this would mean not blocking the timer interrupts when an event gets added, which i think we agree would cause issues if, say, a timer would try to add to the event queue while a trigger interrupt was doing the same thing. not sure why it worked.
- registering the trigger interrupts at the same level as the timer interrupts: this would mean with high rate triggers
post_event would be called all the time blocking both the trigger and the timer interrupts, and as soon as they would be enabled another trigger would arrive, so makes sense this would mean everything is blocked most of the time.
gpio_clear_pin_interrupt_flag until after
event_post means no 2 trigger interrupts can try adding to the queue at the same time, so makes sense this should have a positive effect on stability.
i think the bottom line is -
event_post needs to be protected from corrupting the queue. this is the whole reason why interrupts are disabled there. but i wonder if this should be achieved by checking if the queue is full before modifying it and then restoring it as the existing code does. there might still be a possible race condition where 2 interrupts check the queue one after another, both confirm it's not full and both add, so checking if it's full should still be within a block that disables interrupts, but it's a smaller block, don't need to disable all for the whole
i like the counter idea - clever! and i think it should take care of all the scenarios with nested interrupts. and good catch on
i2c and USB should have the highest priority imo. i think it's more dangerous to not let a transaction complete and leave devices hanging in some unknown state. the downside of this is that an i2c transmission has the power to block everything, and fixing that would be hard (as you'd need some timer based solution to reset i2c after a timeout, very tricky). but hopefully the hardware improvements should make i2c code reliable enough that this shouldn't happen (btw, monome teletype repo still references livabr32 with pullups enabled).
i also agree with @zebra that UI should be higher priority - i'd rather drop more triggers (we're talking about super high rate anyway!) than have a less responsive UI. perhaps what should be done is not making screen refresh / keyboard / grid / arc handlers timer based (so, not use events for them at all), but process them in the main event loop - this could still be done based on some frequency, by storing the timestamp and comparing against