Runtime ISR binding and simple public API docs for assist-debug

[JurajSadel]

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).
• My changes were added to the CHANGELOG.md in the proper section.

Extra:

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

Pull Request Details 📖

Description

Use runtime ISR binding for assist_debug and adds docs for public API.

Testing

Run modified debug_assist example.

[MabezDev]

Thanks, this all LGTM from a code perspective!

I have a question about adding a MODE param to a driver that would (correct me if I'm wrong) never have an async version. If a driver won't ever support async, then the mode param seems redundant. We could just drop the parameter here, and assume that it's always in "blocking" mode. 🤔

[bjoernQ]

Thanks, this all LGTM from a code perspective!

I have a question about adding a MODE param to a driver that would (correct me if I'm wrong) never have an async version. If a driver won't ever support async, then the mode param seems redundant. We could just drop the parameter here, and assume that it's always in "blocking" mode. 🤔

Good question! Would debug_assist ever make sense to be async? I think technically we could do that but will we do that? 🤔

[bjoernQ]

I somehow thought GitHub lets me comment on non-changed lines but either it doesn't, it doesn't work or I don't know how. Anyways ....

The example shouldn't use #[interrupt] and pass None for the interrupt handler. It should use #[handler] and pass the handler to the constructor

[bjoernQ]

We probably just need to decide if this will never be async and then remove the mode ... or decide it might become async and keep it 🤷‍♂️

[JurajSadel]

Thanks, this all LGTM from a code perspective!

I have a question about adding a MODE param to a driver that would (correct me if I'm wrong) never have an async version. If a driver won't ever support async, then the mode param seems redundant. We could just drop the parameter here, and assume that it's always in "blocking" mode. 🤔

That's really good question! I think adding async doesn't make too much sense .. so if we all agree on not having async version, I'm happy to remove the MODE generic.

[jessebraham]

If there is currently no async support, I do not think we should speculate about the possibility of it at some unknown point in the future. If the mode is not necessary then IMO it should not be a generic parameter, if we ever (for whatever reason) add async support here it's easy enough to change it at that time.

[JurajSadel]

I reverted MODE generic changes.

[jessebraham]

Thanks for making those changes, I think this LGTM now.