Viktor Vilhelm Sonesten
Viktor Vilhelm Sonesten
That is ```rust cortex_m_rtic_trace::configure( &mut ctx.core.DCB, &mut ctx.core.TPIU, &mut ctx.core.DWT, &mut ctx.core.ITM, 1, // task enter DWT comparator ID 2, // task exit DWT comparator ID &TraceConfiguration { delta_timestamps: LocalTimestampOptions::Enabled,...
>So, the recv component of the frontend will simply copy what the backend sends it, and redraw the UI according to what the user asks. This approach will not scale....
Replaying the trace file in [trace.zip](https://github.com/rtic-scope/cargo-rtic-scope/files/7863884/trace.zip) yields different output each time: ``` $ cargo rtic-scope replay --trace-file /path/to/trace-file Warning cannot map Instrumentation { port: 8, payload: [128, 136, 14, 28]...
The whole point of RTIC Scope is to offer instant insight into firmware behavior if it's written in RTIC. Work remains to reach this point. Namely: - [ ] #94...
The flashing configurations of `cargo-rtic-scope` are the same as `cargo-flash`, but one will want to store these settings in a persistent configuration file alike `Embed.toml`. Either we merge relevant settings...
A goal of RTIC Scope is to be as non-intrusive as possible which ultimately requires us to remove the use of [`cortex-m-rtic-trace`](https://github.com/rtic-scope/cargo-rtic-scope/tree/master/cortex-m-rtic-trace): `probe-rs` should be able to configure almost everything...
A frontend mustn't be written i Rust and bindings can most likely be generated.
We'll have to modify the probe-rs API to use external pin instead. This will be target specific. When this is done, we can drop the whole `setup` module from `cortex-m-rtic-trace`.
We want cargo-rtic-scope to be POSIX-compliant, but this only makes sense if probe-rs itself is. That should be checked for first. This is a portability issue and can be left...
To test frontends we need a recorded trace. To make it as simple as possible to CI, a `--bogus-trace` or similar option should provide a source of randomized ITM packages...