Simultaneous Teletype triggers?

I though I’d start a new topic, rather than clutter up the code exchange one…

Continuing the discussion from > teletype : code exchange:

Can I ask a hypothetical question then, what happens if I trigger 2 scripts from the same trigger source (i.e via a multiple)? Will the scripts fire in a deterministic order?

Or put another way, how does the Teletype determine which triggers have gone high, via an interrupt or via polling?

i tested this-- the results are buried in another TT thread elsewhere. but the outcome: indeed, simultaneous triggers (via a mult etc) are processed in numerical order.

triggers are via interrupt.

i was also curious about this, so i took a look at the mechanisms:

  • all the triggers are on port 0, line 0, so they all share an IRQ: (IRQ source)

  • i think, but i’m not 100% sure, that if the trigger is truly simultaneous - meaning same wire / ports change value within one clock cycle - then the IRQ will be entered once, with the relevant flags set in the GPIO status register.

  • therefore, that looping structure alone determines the order in which simultaneous trigger events are pushed to the event queue.

  • unfortunately, this behavior is dependent on magic numbers. the index of the trigger is assumed to be the physical pin number (index is passed directly to this function.) i guess this is fine as long as nothing ever changes! but it’s fragile and not obvious.

i would always prefer to explicitly test pins based on their function, not on their physical layout, with all functions defined in the board conf header:

// in board.h or whatever

#define TRIG_PIN_0 0
#define TRIG_PIN_1 1
/// ... etc
#define NUM_TRIG_PINS 8

// in interrupts.c or whatever

static const int trig_pins[] = { TRIG_PIN_0, TRIG_PIN_1, /*... etc*/ };

__attribute__((__interrupt__)) static void irq_port0_line0(void) {
 for(int i=0; i<NUM_TRIG_PINS; i++) { 
    if(gpio_get_pin_interrupt_flag(trig_pins[i])) { 
        //... add trigger event

i know it looks “non-minimalist” but this is more maintainable. you don’t need intimate knowledge of the avr32 port structure to change the code without breaking it, and you don’t need intimate knowledge of the code to change the board layout without breaking it.

(and yes, the compiler is smart enough to inline the array values instead of actually looking them up.)

(and yes, you could use an enum instead of defines.)