5a2df4432c
- 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. |
||
|---|---|---|
| .. | ||
| src | ||
| Cargo.toml | ||
| README.md | ||
Xous API: ticktimer
The Xous ticktimer helps other processes track the passage of time through several mechanisms:
- It can report the elapsed uptime since boot in milliseconds.
- It can block a process for a specified number of milliseconds.
- It can block a process until a condition is met (i.e., condvar)
Processes that are blocked by ticktimer are entirely de-scheduled and consume no CPU
quantum; the only overhead is a few instructions to check the processes' runnability
state in the kernel's simple round-robin thread scheduler. Thus sleep and condvar
blocking states are very efficient.
ticktimer's perception of time stops when a system goes into the suspend state;
thus on resume, the elapsed time picks up exactly where it left off. Wall-clock time
during suspend is tracked by the RTC module.
Xous currently has no notions of thread priority, but if it were to develop one,
the ticktimer would be the logical place to implement such a feature, as it has
a full view of all the waiting and runnable threads, and it can influence which ones
should be unblocked at a given quantum.