Skip to content

Various tweaks to pio_blink example#737

Open
lurch wants to merge 2 commits intodevelopfrom
lurch-patch-2
Open

Various tweaks to pio_blink example#737
lurch wants to merge 2 commits intodevelopfrom
lurch-patch-2

Conversation

@lurch
Copy link
Contributor

@lurch lurch commented Feb 14, 2026

  • Add extra comments and defines to make the code easier to understand
  • Use pio_claim_unused_sm instead of hardcoding "last SM + 1"
  • Should now work with LED3 on GPIO 31 and LED4 on GPIO 32

* Add extra comments and defines to make the code easier to understand
* Use pio_claim_unused_sm instead of hardcoding "last SM + 1"
* Should now work with LED3 on GPIO 31 and LED4 on GPIO 32
@lurch lurch requested a review from peterharperuk February 14, 2026 16:04
@lurch lurch added the enhancement New feature or request label Feb 14, 2026
sm[1] = sm[0] + 2;
offset[1] = offset[0];
pio_sm_claim(pio[1], sm[1]);
sm[2] = pio_claim_unused_sm(pio[1], true);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should have a pio_claim_free_sm_and_add_for_gpio_range function

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds like a @kilograham question to me! 😆
(Although I guess that potential function might be useful for @poetaster in raspberrypi/pico-sdk#2030 )

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or we should make the existing function clever enough to know not to add the same program to the same PIO twice.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or we should make the existing function clever enough to know not to add the same program to the same PIO twice.

Don't know if we can do that with the current API, as I think the PIO instruction memory is write-only?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You might be able to stash an array of pio_program_t structures. Worth seeing if it makes the API better.

assert(PIO_BLINK_LED3_GPIO < 31 || PIO_BLINK_LED3_GPIO >= 32);

// LED1 and LED2 are both expected to be in the "lower" range of PIO-addressable GPIOs
assert((PIO_BLINK_LED1_GPIO < 32) && (PIO_BLINK_LED2_GPIO < 32));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

arguably, these asserts should be unnecessary - the code should be able to work whatever value is used.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess it depends on the focus of the example - is it showing "here's how you flash two GPIOs in one PIO-range and two GPIOs in a different range" (which I think was the original intention?), or is it showing "here's totally generic (but more complicated) code for flashing any four GPIOs in any combination" ?
Perhaps I ought to add a comment highlighting the intention of the example? 🤔

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps I ought to add a comment highlighting the intention of the example?

Done.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants