You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I'm not sure if this is the correct communication channel but figured I would ask here, apologies if it is not. I've been looking into the rust abstractions over peripheral registers and have become slightly confused.
svd2rust wraps registers at the lowest level in the vcell::VolatileCell type. This type is essentially a volatile wrapper for std::cell:UnsafeCell which is the foundational type for interior mutability. What are the reasons for which interior mutability is required for peripheral register access ?
This property means that the write and modify methods of the Reg type created by svd2rust do not require a mutable reference to the register to modify it, and the API is usually pretty good in my experience meaning that several methods usually exist to perform the exact operation you would like without using unsafe. I personally find this a little bit unsettling as it means the following code is allowed to compile with an svd2rust generated pac.
Whereas for example looking at the SysTick API in the cortex_m crate, it can be see that a mutable reference to the RegisterBlock is required for any reads or writes. I have seen in some generated pacs that a mutable reference to the specific register's writer type is required (it is not for the reader type even though reads can effect the state also).
This property means that there is nothing stopping a HAL from creating multiple types with non-mutable references to a peripheral and all modifying it in ways that could be confusing. Fortunately, in most HAL implementations I have seen, generally ownership of the peripheral is moved ensuring exclusive access.
I was hoping someone could clarify if what I have described is in fact correct and if so why that particular design choice was made.
The text was updated successfully, but these errors were encountered:
Hi,
I'm not sure if this is the correct communication channel but figured I would ask here, apologies if it is not. I've been looking into the rust abstractions over peripheral registers and have become slightly confused.
svd2rust
wraps registers at the lowest level in the vcell::VolatileCell type. This type is essentially a volatile wrapper for std::cell:UnsafeCell which is the foundational type for interior mutability. What are the reasons for which interior mutability is required for peripheral register access ?This property means that the
write
andmodify
methods of theReg
type created bysvd2rust
do not require a mutable reference to the register to modify it, and the API is usually pretty good in my experience meaning that several methods usually exist to perform the exact operation you would like without using unsafe. I personally find this a little bit unsettling as it means the following code is allowed to compile with ansvd2rust
generated pac.Whereas for example looking at the SysTick API in the cortex_m crate, it can be see that a mutable reference to the RegisterBlock is required for any reads or writes. I have seen in some generated pacs that a mutable reference to the specific register's writer type is required (it is not for the reader type even though reads can effect the state also).
This property means that there is nothing stopping a HAL from creating multiple types with non-mutable references to a peripheral and all modifying it in ways that could be confusing. Fortunately, in most HAL implementations I have seen, generally ownership of the peripheral is moved ensuring exclusive access.
I was hoping someone could clarify if what I have described is in fact correct and if so why that particular design choice was made.
The text was updated successfully, but these errors were encountered: