rtc driver for the stm32u5xx and instantiation on the nucleo_u545re_q board. - #4950
rtc driver for the stm32u5xx and instantiation on the nucleo_u545re_q board.#4950K-Nicolas-10 wants to merge 7 commits into
Conversation
| usart1: &'a usart::Usart<'a>, | ||
| exti: &'a exti::Exti<'a>, | ||
| dma1: &'a Dma, | ||
| rtc: &'a rtc::Rtc<'a>, |
There was a problem hiding this comment.
I think this can be created here rather than passed in.
There was a problem hiding this comment.
Did it in 5ee4e4e.
I had to borrow RCC in order for the DefaultPeripherals to own RTC. Can I ask why this might be a better solution? I thought about the fact that if someone comes along to have multiple RCC initializations, like let rcc = rcc::Rcc::new(rcc::RCC_BASE); , it can cause synchronization issues and borrowing rcc thus being the better approach, is there more to it than this?
| register_structs! { | ||
| pub PwrRegisters { | ||
| (0x00 => _padding), | ||
| /// PWR disable backup domain register | ||
| (0x28 => pwr_dbpr: ReadWrite<u32, PWR_DBPR::Register>), | ||
| (0x2C => @END), | ||
| } | ||
| } |
There was a problem hiding this comment.
This should be in its own file.
| // 5. After the LSI Oscillator stabilizes we select it as the RTC clock source. There can be | ||
| // a situation where the oscillator doesn't stabilize, in that case my approach is to not hang the kernel | ||
| // and just timeout. | ||
| let rcc = rcc::Rcc::new(rcc::RCC_BASE); |
There was a problem hiding this comment.
Can you pass a reference in instead?
| // Turn on the RTC clock and unlock the backup domain. | ||
| // We handle errors here such that a failure doesn't halt the kernel. | ||
| if let Err(e) = rtc.initialize_clock() { | ||
| debug!("{:?}", e) | ||
| } | ||
|
|
||
| // Set up the RTC mode. (configure prescalers, 24h format, default date/time) | ||
| // This requires the previous step, the clock and bckup domain to have been sucessfully initialized. | ||
| if let Err(e) = rtc.init_mode() { | ||
| debug!("{:?}", e) | ||
| } |
There was a problem hiding this comment.
Can this all be handled by the default peripheral init function?
… board Signed-off-by: K-Nicolas-10 <alinicolas006@gmail.com>
Signed-off-by: K-Nicolas-10 <alinicolas006@gmail.com>
…t instead of in board Signed-off-by: K-Nicolas-10 <alinicolas006@gmail.com>
| // Register the RTC to the deferred call client | ||
| periphs.rtc.register(); | ||
|
|
||
| // Board specific wiring |
There was a problem hiding this comment.
I think this can move to the def peripherals init function as well.
Signed-off-by: K-Nicolas-10 <alinicolas006@gmail.com>
Signed-off-by: K-Nicolas-10 <alinicolas006@gmail.com>
|
Please work with the rest of the stm32u5xx team to determine how you all want the chip to handle RCC. Most peripheral drivers seem to initialize everything in the default peripherals init function. It could be handled like this PR. But having multiple patterns makes it hard to use this chip. |
3 participants
Pull Request Overview
This pull request adds RTC driver for stm32u5xx and instantiates it in
boards/nucleo_u545re_q.Testing Strategy
This pull request was tested by uploading tock on the Nucleo U545RE-Q board and running a userspace RTC application. The application can be found in
libtock-c/examples/tests/rtc.TODO or Help Wanted
N/A
Documentation Updated
/docs, or no updates are required.Formatting
make prepush.AI Use
code in this PR, if any, and I have manually checked and
personally certify the entire contents of this PR.
My AI use: Although AI didn't write any lines of code in this PR, I have used Gemini for asking questions about the RTC driver for the F429ZI to understand it better and to have the same approach for my driver.