oxidecomputer / oxidecomputer/humility
Display the programmer names for the SPRs instead of "SPR"
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 584
- Forks
- 63
- Avg merge
- 3h
- Merged PRs (30d)
- 2
Description
ARMv7-M/v8-M expose a set of special-purpose registers to the programmer: CONTROL, BASEPRI, PRIMASK, and FAULTMASK. From assembly language, they're separate registers, and you access one at a time.
ADIv5 appears to expose them all in a single "SPR", and Humility prints them that way, e.g. from probe:
humility: SPR => 0x0
This is confusing because it doesn't match the programmer model of the system. It would be nice to break this out:
CONTROL => 0x0
BASEPRI => 0x0
PRIMASK => 0x0
FAULTMASK => 0x0
etc
(I actually didn't realize until Friday that Humility even read back the CONTROL register because I had scanned output looking for its name, and didn't see it.)
registers does a slightly better job in that it prints decodes of the constituent bits of SPR:
SPR = 0x00000000 <- 0000_0000_0000_0000_0000_0000_0000_0000
||| | | |
||| | | + PRIMASK = 0
||| | +---------- BASEPRI = 0x0
||| +-------------------- FAULTMASK = 0
||+------------------------------ CONTROL.nPRIV = 0
|+------------------------------- CONTROL.SPSEL = 0
+-------------------------------- CONTROL.FPCA = 0
However, here too it'd be better to present these as separate registers.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the code paths behind the probe and registers commands, searching for the SPR label and its ARM register decoding. Done means both commands present CONTROL, BASEPRI, PRIMASK, and FAULTMASK as separate programmer-facing registers while preserving the relevant decoded values.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- devtools, embedded-iot
- Issue type
- Feature
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100