Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Return functions from USART/I2C when they're no longer needed #104

Open
hannobraun opened this issue Jun 8, 2018 · 0 comments
Open

Return functions from USART/I2C when they're no longer needed #104

hannobraun opened this issue Jun 8, 2018 · 0 comments

Comments

@hannobraun
Copy link
Member

At this point, the USART and I2C APIs consume and drop the functions that they require. This ensures that they run correctly, but it means that the functions are no longer available after that. More dynamic use of the APIs is inhibited. For example, an application couldn't use the same pins for different things at various points. This would require the functions to still be available after use, so they can be unassigned from the pins.

I have some thoughts on a possible design:

  • Since the functions are only required while the peripherals are enabled, it might make sense to add a payload (with a generic type) to init_state::Enabled, which can be used to store the functions, and any other data that is only required while a peripheral is enabled.
  • Once init_state::Enabled is extended in that way, it should be possible to store mutable references to the functions in it. This would have the advantage of being easy to implement, and in some situations also easy to use, as the compiler would take care of tracking the references. More advanced use cases would need to add the lifetimes to various type signatures, though.
  • A better option is probably to move the functions into the peripheral (like it works now), and later return them again from disable.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant