in practice, we're not putting a 128M part out there, but merely
saving space for that amount of memory chews up 32k of page tracking
for something we will never use.
Tune that down to 64M, reducing the overhead to 16k. This also
matches the largest available HyperRam / FLASH part that we might
put into the XIP memory range.
I can't figure out why rust-analyzer on my system isn't work
correctly but if I change the order of imports things work better.
If this breaks things for Foundation Devices (@eupn) let me know,
I will poke at this some more and try to figure it out. In theory
it should have no impact but somehow I'm getting the atsamd target
*always* live in my vscode environment, even when it is switched
off when it isn't the last target in the list (and this overrides
all of the rust-analyzer settings for other targets).
formatting of generated files is suppressed with a `rustfmt::skip`
directive on the `mod` import. HOWEVER, if a change is made to the
file and saved, it may still be formatted automatically until the
files are updated with codegens that put a format suppression
directive at the top
a lot of re-import warnings have cropped up. While I appreciate
their studiousness on this, the problem is that removing some
of these exports in the API crate could mean that future users
who want access to some API features that aren't used in this
configuration are now unaccessible.
I think it's not a huge problem at the moment, just spam-cleaning
the warnings because there are too many to deal with carefully
at the moment.
- make the "base" field no longer public. It is accessible, but only
through an `unsafe` method, because, it is unsafe.
- add accessors to offest/mask fields. Because, it's not at all
unsafe to access these, and it can be useful for bit-ops that are
not part of the generic set of UTRA.
- add Arc to AtomicCSR, and require `std` for AtomicCSR types.
This should not break anything, I checked inside @foundation-devices
keyOS and they don't seem to be using AtomicCSR anywhere.
The Arc makes it a bit safer to clone the AtomicCSR base pointer
and share it between threads, but it will have an impact on performance.
The USB stack (which requires AtomicCSR) was regression testing and the
impact seems minimal.
Recall that the main purpose of AtomicCSR is to provide a CSR accessor
that does not require a mutable reference to the base object. This
can make certain Rust idioms a bit cleaner. We wrap the base accessor
in Arc+Atomic to try and improve the safety of throwing the borrow
checker under the bus, but it's still not perfect because hardware
mutable state can have side-effects within hardware itself that cannot
be modeled or checked by Rust's borrow checker.
in practice this has not been a useful indicator, and we
have stabilized the SVD format so that changes in the code don't
cause the SVD files to go incompatible anymore.
this should make maintenance a bit easier going forward, hopefully.
also merge in cramium support to harmonize the forks for easier
cross-patches in the future.
