nRF52 spi: fix get_rate

[lschuermann]

Pull Request Overview

The nRF52 SPI implementation's get_rate() method has been returning the actual register content instead of the converted SPI operating frequency.

This PR fixes this issue specifically. However, because the Frequency enum relates to two u32s, namely the register content and the actual frequency, using From<> traits are confusing which is likely how the bug was introduced originally. Those traits are replaced with methods indicating their purpose.

The back-conversion of the register content to a frequency may fail if the register contains an invalid value. As the reset value is valid and all other values written should be valid too, this should work. Nonetheless, a .expect() must be introduced.

Testing Strategy

Tested on nRF52DK.

    debug!(
        "Old rate: {:?}",
        hil::spi::SpiMaster::get_rate(&nrf52::spi::SPIM0)
    );
    debug!(
        "Set rate: {:?}",
        hil::spi::SpiMaster::set_rate(&nrf52::spi::SPIM0, 5_000_000)
    );
    debug!(
        "New rate: {:?}",
        hil::spi::SpiMaster::get_rate(&nrf52::spi::SPIM0)
    );

Output on latest master:

NRF52 HW INFO: Variant: AAE0, Part: N52832, Package: QF, Ram: K64, Flash: K512
Old rate: 67108864
Set rate: 4000000
New rate: 1073741824

Output with this PR:

NRF52 HW INFO: Variant: AAE0, Part: N52832, Package: QF, Ram: K64, Flash: K512
Old rate: 250000
Set rate: 4000000
New rate: 4000000

Verifying the actual SPI rate will need to wait for me to get my logic analyzer.

TODO or Help Wanted

• The nRF52840 also supports 16 and 32 Mbps SPI rates. Those should probably be implemented using compile features on the chip crate. Can we do it in this PR as well, or should I open a new one?

Documentation Updated

• Updated the relevant files in /docs, or no updates are required.

Formatting

• Ran make formatall.

[bradjc]

Shouldn't this have more fields?

[lschuermann]

Yes, I've stated this in my todos. However the highest frequencies only apply to the nRF52840. I can fix that in this PR too, or create another one for that.

[bradjc]

I don't like adding a panic to the chip, but we haven't been consistently avoiding that so I won't block on this. If the hardware is broken then it seems like returning any value is fine, but 🤷