rust-embedded / rust-embedded/cortex-m
'get_ticks_per_10ms' works like 'get_ticks_per_1ms' on QEMU
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 1k
- Forks
- 202
- Avg merge
- 6d 2h
- Merged PRs (30d)
- 2
Description
Hello,
Using the Cargo config as below,
...
[target.thumbv7m-none-eabi]
runner = "qemu-system-arm -cpu cortex-m3 -machine lm3s6965evb -nographic -semihosting-config enable=on,target=native -kernel"
[build]
target = "thumbv7m-none-eabi" # Cortex-M3
...
I tested running the below program using QEMU.
#![no_std]
#![no_main]
extern crate panic_halt;
use cortex_m::asm;
use cortex_m_rt::entry;
use cortex_m::peripheral::syst::SystClkSource;
use cortex_m::peripheral::SYST;
use cortex_m_semihosting::{debug, hprintln};
#[entry]
fn main() -> ! {
let p = cortex_m::Peripherals::take().unwrap();
let mut syst = p.SYST;
syst.set_clock_source(SystClkSource::Core);
syst.set_reload(SYST::get_ticks_per_10ms() * 1000); // Works strange in QEMU?
syst.enable_counter();
hprintln!(
"{} ticks = 10 millisecond", SYST::get_ticks_per_10ms()
).unwrap();
let mut seconds: usize = 0;
loop {
// busy wait until the timer wraps around
while !syst.has_wrapped() {}
seconds += 1;
hprintln!("{} seconds passed", seconds).unwrap(); // prints every second!
}
}
I checked that fn get_ticks_per_10ms always returns 10_000 in my program.
Since I set called the set_reload function with an argument of get_ticks_per_10ms() * 1_000,
I expected the program to print out to the console every 10 seconds (since ticks_per_10ms * 1_000 == ticks_per_10seconds).
However, the program prints out to the console every 1 second.
I tried changing the argument fed to set_reload(), and it seems like the get_ticks_per_10ms() is behaving like get_ticks_per_1ms().
Unfortunately, I do not have an actual cortex-m device to test this behavior.
I'm currently not sure whether this is an issue with the api of the cortex-m crate, or QEMU.
If this is an issue with the cortex-m crate, maybe the function name of fn get_ticks_per_10ms should be changed to fn get_ticks_per_1ms.
Thank you for reading 😄
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 Cargo configuration and the main entry point shown in the report, reproducing the SysTick behavior under QEMU with SYST::get_ticks_per_10ms() and set_reload(). Compare the observed interval with the Cortex-M SysTick expectation to determine whether the issue is in the crate API or QEMU, then document the confirmed behavior or required naming change.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- embedded-iot
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100