Skip to content

Clocks can no longer be specified in MHz #136

@rfuest

Description

@rfuest

Before the migration to embedded-time it was possible to write HSEClock::new(216.mhz(), HSEClockMode::Oscillator). This isn't possible anymore, because Into<Hertz> isn't implemented for embedded-times Megahertz.

The way the conversion is implemented in embedded-time makes more sense, because it prevents possible integer overflows. But the use of Into<Hertz> in e.g. HSEClock::new suggests that values with any frequency unit could be used. I didn't expect this behavior while porting to the new version and had to look into why this didn't work anymore.

Would it be better to change the API to take Hertz values instead of impl Into<Hertz> values? This way the types should make the user aware that they need to convert the value into hertz first if they want to use another unit (e.g. 216.MHz().try_into().unwrap()).

Another option would be to change the type bounds from Into<Hertz> to TryInto<Hertz>, but this would mean that all functions that take a frequency would need to return a Result. I don't think this would be a good idea.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions