nrf54l - Add SPI support #4572
nrf54l - Add SPI support #4572
Conversation
|
This PR is inspired by 4393 but takes a different approach to the SPI frequency. The nrf54l introduces a frequency prescaler that can take a relatively wide range of values compared to other NRF chips. Instead of introducing a new Frequency type, I left the prescaler as a u8 for simplicity. The prescaler value is checked in |
| r.dma().rx().ptr().write_value(rx_ptr); | ||
| r.dma().rx().maxcnt().write(|w| w.set_maxcnt(rx_len as _)); | ||
| } | ||
|
|
There was a problem hiding this comment.
Here and below you can see something I reeeeeally would like to avoid (and definitely don't want to support :-) ): #[cfg]'s in the drive code that address the register programming interface change introduced by the nrf54l.
It looks like there is no good way out of the problem. My approach was to hide the change and emulate classic interface, but the project owners want to move the whole codebase to the new interface at the pac level instead.
My opinion: I don't like this and I don't like that [(c) Muzzy from Gondoland], but do not want to block nrf54l development either :)
There was a problem hiding this comment.
Agreed that it is not an easy problem. I gave this approach a shot to see what it looks like. I am not a big fan of all the #[cfg()]s. I think I understand why you went the extend route after looking at the uarte module. The number #[cfg()]s required in that module is a lot.
I will look more into the PAC changes. I wanted to try this approach to see how it looked. The same approach to the |
Signed-off-by: Dmitry Tarnyagin <[email protected]> Signed-off-by: Vegard Eriksen <[email protected]> Signed-off-by: Tyson Lawrence <[email protected]>
Adding SPI (Spim and Spis) support to the nrf54l