Including a state machine number as argument to pio_set_irqN_source_enabled()

[yukdumboobumm]

It seems that the SDK promotes claiming unused state machines as a best practice. It would make sense to have interrupt sources not hard coded to state machines.

using, for example, pio_set_irq0_source_enabled(pio0, pis_interrupt0, true); requires that I build my functions knowing that I'm using state machine 0.

pio_set_irq0_source_enabled(PIO_NUM, SM_NUM, SOURCE, true) seems more useful and in line with how you've built the SDK.

[peterharperuk]

You mean have SOURCE as another enum specifying the type of interrupt?

[kilograham]

This doesn't make any sense.pio_set_irq0_source_enabled is not specific to any state machine, and neither is pis_interrupt0

pis_sm0_tx_fifo_not_full is specific to SM0, but you can just use pis_sm0_tx_fifo_not_full + sm_num

[yukdumboobumm]

am i missing something about pis_interrupt0 = PIO_INTR_SM0_LSB does SM0 not mean State Machine 0?

[kilograham]

yes; it is poorly named (hence the newer pis_ values)... these INTR_SMx are not specific to an SM - you can target any of the 4 processor visible IRQs from any of the SMs.

[kilograham]

(but your issue does make sense now, though it just equivalent as I say in the cases where it makes sense to adding the SM number to the pis_xxx0)

[yukdumboobumm]

thanks for the clarification. That's helpful to know.

you can just use pis_sm0_tx_fifo_not_full + sm_num

Yes but I'm still struggling to see how this is aligns with how you've written the rest of the SDK. pis_sm0_tx_fifo_not_full + 3 makes little sense for targeting state machine 3. if you wanted to use the enum that way, what's the point of including sm0 in the name?

[kilograham]

ok, yes, we could add explicit methods for not_full and not_empty