Implement TryFrom<u32> for ledc::timer::config::Duty

[AnthonyGrondin]

Thank you for your contribution!

We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:

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

This is a resurrection for #814 that was closed by mistake a while ago. The intent is to provides a driver for a piezo-electric buzzer by abstracting LEDC and offering a user-friendly API to control the buzzer

Since the GPIO refactoring, I've solved the issue I had with providing a type for an optional volume pin.

Testing

An example was added in esp-hal-buzzer/examples/buzzer.rs and works on my hardware. The duty volume is working on the specific hardware that I have, using logic gates to decrease the output.

Edit: The esp-hal-buzzer package has been moved to https://github.com/esp-rs/esp-hal-community so I've kept only the part of this PR that touches esp-hal, which is to implement TryFrom<u32>

[jessebraham]

Sorry for hijacking your PR for this, but I guess we need to have some discussion with regards to where packages like this belong. We have esp-hal-smartled in the repo, but frankly it's just a bit of an annoyance from the perspective of maintenance/publishing, and barely anybody seems to even use it based off the download stats on crates.io. I'm not sure we really want to take on a number of packages like this given their limited use, though I do acknowledge their utility. Perhaps some of the other maintainers have thoughts on this.

[AnthonyGrondin]

I agree with this. I see it like a chicken 🐔 and egg 🥚 situation. Such extra packages are an unnecessary burden because nobody uses them, but nobody uses them because such package doesn't exist.

My original intent was to add the Buzzer as a new driver in the HAL. But since it's not technically a hardware driver, but rather a combination of drivers, it was suggested to move the buzzer driver in its own specific package.

I agree with moving both esp-hal-buzzer and esp-hal-smartled into extras/, and I think we should treat those packages as tier 2 packages, having a lower priority, maintenance, etc. Tier 1 packages being the most important ones, part of the root of the repo.

[jessebraham]

Sorry for the delay here, it took some time for us to discuss and decide on how we wanted to proceed.

We have decided to create the esp-hal-community repository, to which I have already moved esp-hal-smartled and its associated example. If you wouldn't mind opening a new PR there adding this package, that would be much appreciated!

I have not really documented the contribution process there yet (though I did open an issue), but I hope it is intuitive enough. Feel free to ping me if you need any assistance :)

[AnthonyGrondin]

• I've moved esp-hal-buzzer to esp-hal-community in Add esp-hal-buzzer to drive a piezo-electric buzzer. esp-hal-community#3
• I've updated this PR title and description to reflect the changes
• I rebased on the latest HEAD

[bjoernQ]

LGTM