rtt-target icon indicating copy to clipboard operation
rtt-target copied to clipboard

rprint! adding newline

Open pkoevesdi opened this issue 9 months ago • 8 comments

Strange behaviour:

rprint!("rprint");
rprintln!("rprintln");

works as expected, output: rprintrprintln. But

rprint!("rprint");
Timer::after_millis(TIME).await; // use embassy_time::Timer;
rprintln!("rprintln");

adds a newline, depending on the value of TIME. Output:

rprintr
rprintln

when TIME is something above 270 (thereshold is changing from time to time).

pkoevesdi avatar May 01 '24 06:05 pkoevesdi

This shows some more strange behaviour:

for _ in 0..100 {
Timer::after_millis(10).await;
rprint!(".");
}

Output:

.
.
.....
.....
.....
.
.....
.....
.....
.....
.
.....
.....
.
.....
.....
.....
.
.....
.....
.....
.
.....
.....
.....
.
..

pkoevesdi avatar May 01 '24 06:05 pkoevesdi

If anyone is going to look at the code for this, I have a suspicion is that this is not random, but rather related to how and when rtt-target and the application (are you using probe-rs run, cargo-embed, or the VSCode debugger???) flushes the buffer.


From: pkoevesdi @.> Sent: May 1, 2024 2:07 AM To: probe-rs/rtt-target @.> Cc: Subscribed @.***> Subject: [probe-rs/rtt-target] rprint! adding newline (Issue #47)

Strange behaviour:

rprint!("rprint"); rprintln!("rprintln");

works as expected, output: rprintrprintln. But

rprint!("rprint"); Timer::after_millis(TIME).await; // use embassy_time::Timer; rprintln!("rprintln");

adds a newline, depending on the value of TIME. Output:

rprintr rprintln

when TIME is something above 270 (thereshold is changing from time to time).

— Reply to this email directly, view it on GitHubhttps://github.com/probe-rs/rtt-target/issues/47, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ABJJRNXHZAP5L2RSLIMNLHLZACBAVAVCNFSM6AAAAABHBQSFQKVHI2DSMVQWIX3LMV43ASLTON2WKOZSGI3TEOJZGIYTGNI. You are receiving this because you are subscribed to this thread.Message ID: @.***>

noppej avatar May 01 '24 13:05 noppej

Very mysterious. Which program on your computer are you using to look at the output?

mvirkkunen avatar May 01 '24 13:05 mvirkkunen

I use both, cargo run in a normal Linux Terminal and vscode (which also uses cargo in the background).

pkoevesdi avatar May 01 '24 20:05 pkoevesdi

What do you have configured as the runner in .cargo/config.toml? Is it probe-rs run or?

runner = 'probe-rs run --chip <chip-name>'

mvirkkunen avatar May 01 '24 21:05 mvirkkunen

From the original posting, I think what is happening is that somewhere between rtt-target and probe-rs, a newline is added after every write of String RTT data to the client (Terminal or VSCode). I'll have to look through the code to confirm, but I think what happens is the process reads all the data available in the target RTT buffer, and sends it to the output with a newline at the end of it, then goes back to look for more data.

  • If the data comes in during a single buffer read , e.g. "rprintrprintln", then it will send that to the output.
  • If the data comes in the first buffer read having "rprint", it will process it, and then look again, and find the slightly delayed "rprintln" and send that on another (new) line.

noppej avatar May 01 '24 21:05 noppej

Were you able to reproduce the problem?

My config.toml has this line, yes: runner = [ "probe-rs", "run", "--chip", "STM32H730VBTx"] and I can also run probe-rs run --chip STM32H730VBTx target/thumbv7em-none-eabihf/debug/pintest on the terminal and have this effect.

pkoevesdi avatar May 02 '24 05:05 pkoevesdi

I put up a minimum (?) working project that shows this behaviour. rprinttest.zip

pkoevesdi avatar May 02 '24 05:05 pkoevesdi