Add dynamic output gpio example to demonstrate how to use AnyPin and Flex

[Szybet]

Submission Checklist 📝

• I have updated existing examples or added new ones (if applicable).
• I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
• My changes were added to the CHANGELOG.md in the proper section.
• My changes are in accordance to the esp-rs API guidelines

Extra:

• I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖

Description

I added an example which shows how to use the AnyPin and Flex, because it took me too much time to figure out myself and I don't want for anyone else to waste time on this.

Testing

Measured the GPIOs states on the ESP32-C6-DevKitM-1 using an oscilloscope.

[MabezDev]

I think this would be better as an improvement to the documentation: https://docs.esp-rs.org/esp-hal/esp-hal/0.19.0/esp32c6/esp_hal/gpio/struct.Flex.html, instead of an example. As an example it's basically the same as the blinky_erased example.

Would you mind changing this PR to improve the docs for Flex instead?

[Szybet]

I think this would be better as an improvement to the documentation: https://docs.esp-rs.org/esp-hal/esp-hal/0.19.0/esp32c6/esp_hal/gpio/struct.Flex.html, instead of an example. As an example it's basically the same as the blinky_erased example.

Would you mind changing this PR to improve the docs for Flex instead?

The point of this was to make it easier to find this solution, adding it to the docs somewhere is not really a solution to what I'm trying to solve

[MabezDev]

The point of this was to make it easier to find this solution, adding it to the docs somewhere is not really a solution to what I'm trying to solve

Maybe I'm missing something, but if the usage is in the docs (remember, we can add code snippets to the docs) it's probably more discoverable than it being in an example?

[Szybet]

Maybe I'm missing something, but if the usage is in the docs (remember, we can add code snippets to the docs) it's probably more discoverable than it being in an example?

To find it in docs you need to know what you are looking for, while examples are more easily discoverable by just the description of what are they doing

[bjoernQ]

I agree with @MabezDev - maybe extending blinky_erased_pins would be an option but another example just for GPIO is somewhat "expensive"

Every example is built for every target in CI (which is run for every commit in every PR). Additionally, there is maintenance effort needed whenever something gets refactored

[Szybet]

Ok, I'm gonna look into it

[Szybet]

Do I just expand it by putting it into Flex and AnyPin and making a comment "You can use it as output now too"?

Also, what's with the name erased pins? I don't get it

[bjoernQ]

"erased pin" = type erased pin - things changed a lot since adding this example and the name probably isn't a great fit anymore

[bugadani]

Please note that the GPIO driver is under rework, so things will change around here.

[Szybet]

Sure, I will look into it once it's ready

Have you thought maybe about a subset of examples which wouldn't be compiled on every commit (to my knowledge they are compiled with regular cargo build, without release), just cargo check? This example could fit in it, the one from #2032 too.

Or just run the check just before merging a pull request? I understand why we should limit the amount of examples, but I think they are important

[bjoernQ]

Converted to draft for now - set it to Read-for-Review once it's done

[MabezDev]

Thanks for the PR!

We're going to be reworking our current example set soon in favour of more complete "mini-project" type of examples, therefore this PR doesn't really fit in that scheme.