Age | Commit message (Collapse) | Author | Files | Lines |
|
342: Implement various interfaces for trace configuration r=adamgreig a=tmplt
I'm working on tracing support and aim to implement functions that abstract the configuration of relevant peripherals. Of chief interest is `DWT`, `ITM` and `TPIU`. Some propored abstractions will go against what is established in the crate; I will ask for comments on these.
Co-authored-by: Viktor Sonesten <v@tmplt.dev>
|
|
Required to support the #[non_exhaustive] attribute.
|
|
|
|
362: add note r=jonathanpallant a=gnxlxnxx
the same note as in https://github.com/rust-embedded/riscv/pull/87
Co-authored-by: gnxlxnxx <roman@kretschmer.email>
|
|
As per Rust API guidelines:
<https://rust-lang.github.io/api-guidelines/interoperability.html#c-common-traits>.
|
|
|
|
|
|
|
|
A DWT unit can do much more than just comparing addresses. PC
comparison, for example, which is only possible with the first DWT unit.
|
|
|
|
|
|
|
|
The function is a bit too large to warrant inlining.
|
|
|
|
|
|
|
|
Exposes two new feature gates for VectActive serde::{Serialize,
Deserialize} (via "serde") and Hash, PartialOrd (via "std-map") for use
on host-side ITM tracing programs. While the struct itself is not
received directly over ITM, its use greatly simplifies the
implementation by allowing VectActive as keys in map collections and
file/socket {,de}serialization to forward the structure elsewhere. These
features are not enabled by default.
Before this patch, serde functionality could be realized via [0], but
this does not propagate down a dependency chain (i.e. if realized for
crate B, which crate A depends on, serde functionality is not exposed in
crate A unless VectActive is wrapped in a type from crate B). I am not
aware of any method to realize PartialOrd, Hash derivation for a
downstream crate.
[0] https://serde.rs/remote-derive.html
|
|
the same note as in https://github.com/rust-embedded/riscv/pull/87
|
|
|
|
|
|
|
|
|
|
|
|
348: Fix slightly misleading examples. r=adamgreig a=newAM
This is a bit of a nitpick; the examples provided for the peripherals use the cycle counter as an example, but it is not properly enabled, which is slightly misleading. The examples only do `peripherals.DWT.enable_cycle_counter`, but this write may be ignored because tracing needs to be enabled first.
Co-authored-by: Alex Martens <alexmgit@protonmail.com>
|
|
352: Add the Cortex-M7 TCM and cache access control registers. r=adamgreig a=rcls
Add the Cortex-M7 TCM and cache access control registers.
These are documented in the Cortex-M7 generic user guide (ARM DUI 0646C).
I'm not sure what feature gate these should be on - should I add a new one for Cortex-M7? Currently I have them on `not(armv6m)` - they do not appear to be in the ARMv7M architecture documentation, so I presume they are M7 specific.
Co-authored-by: Ralph Loader <ralph1loader@gmail.com>
|
|
These registers appear to specific to the Cortex-M7, so add a feature gate
"cm7".
|
|
339: Fix AIRCR PRIGROUP mask r=thejpster a=msamsonoff
Closes #338
Co-authored-by: Matthew W. Samsonoff <matt.samsonoff@gmail.com>
|
|
|
|
|
|
This follows the rust C-GETTER API guidelines.
|
|
This adds support for these counters:
* CPI counter
* Exception overhead counter
* LSU counter
* Folded-instruction counter
|
|
|
|
|
|
Co-authored-by: Vadim Kaushan <admin@disasm.info>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This was fixed in rust 1.49 already, fortunately. But as the MSRV is
still 1.38 we cannot drop the warning entirely yet.
|