Send decoded and resolved ITM data to a frontend

[tmplt]

The main reason for cargo-rtic-trace is the ability to get a human-readable description of what the traced target is doing and when. Of main interest is a graphical frontend that displays the run-time of RTIC tasks, when they are preempted by other tasks, and auxilliary data such as task queue sizes, etc. The possibilities with a frontend are virtually endless:

• Do we want statistics about task run-time?
• Do we only want to trace some specific task and/or change the trace configuration from the frontend?
• Do we want to add arbitrary hooks to task events?

The main idea now is a web frontend that displays the tasks and when they are running. Consider an oscilloscope or a logic analyzer, but instead of signals we have tasks and their state (running or not). This frontend is a completely separate project so this issue will only consider how the communication should be managed. For now, data will only flow from the backend (cargo-rtic-trace) to the frontend.

Some initial questions/considerations:

• cargo-rtic-trace will not be very useful on its own without a frontend. Should it perhaps handle the startup of a default frontend (feature gated, course)? It could detach the process and reuse the instance after the initial run.

---

CC @Yatekii @perlindgren

[tmplt]

@Yatekii, did you have a public front-end prototype in the works that can be experimented with?

[Yatekii]

Yeah I have it here: https://github.com/Yatekii/tracer.

Thing is: currently it does nothing more than render a few bars. I could not decice upon the architecture. I wanted to do as much as possible in Rust. But as UI frameworks are in a terrible spot in Rust atm, I chose Flutter for that. Rust interop is wonky to say the least, so I tried to aim for a Client-Server approach, which kinda stopped when I needed to decide if I transfer the full trace state oir just specific events. Transferring the entire trace without filtering means A LOT of data serialization just after a few seconds which is not feasible. So one would have to either just send Events serialized which means that analysis has to be done in Dart on the Client side or we have to filter/squash data on the Server side already and display that.
Basically we have to decide what we want to use here.
I am good with using Flutter/Dart. I am not sure about you. Also, I'd still prefer Rust if possible.

So assuming we just do the UI/Rendering in Dart/Flutter we would have to preprocess all the events in Rust to a point where we will just transfer the bars/elemnts on screen and retransfer everytime someone zooms/pans the view.

What do you think about this? Once we have decided on a format I am happy to continue working on this :)

[tmplt]

Yeah I have it here: https://github.com/Yatekii/tracer.

Neat. What do you think of moving it here, under RTIC Scope?

I am good with using Flutter/Dart. I am not sure about you.

I have zero experience when it comes to web frameworks and tools. Were I to create a front-end myself it would likely be based on https://github.com/ocornut/imgui. You're on your own here, I'm afraid.

Also, I'd still prefer Rust if possible.

Majority of RTIC Scope will be in Rust, so it would make sense to try and keep it that way. But if it becomes too troublesome we shouldn't dismiss other approaches just because it isn't Rust. I speak of the front-end here; a key point of RTIC Scope is that everything embedded-related is written in (safe) Rust.

So assuming we just do the UI/Rendering in Dart/Flutter we would have to preprocess all the events in Rust to a point where we will just transfer the bars/elemnts on screen and retransfer everytime someone zooms/pans the view.

Makes sense to me. For now lets only focus on one-way communication of tasks and their status over time. The backend (cargo-rtic-trace) will send a struct { timestamp: chrono::DateTime, packets: [ResolvedPackets] } ("resolved" in the sense that interrupt, exceptions, and DWT payloads are replaced with RTIC task names) as soon as it is able. Effectively instantly if it's a replay. For now, no other packets will be sent. This will keep the API between front- and backend initially simple. It will have to be reviewed and extended for post-v1.0.0 releases.

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. A better solution would be if the frontend queries the backend for what happens within a range of time. The backend already streams the trace to disk, we might as well revamp the implementation so it can dig up what the frontend asks for. For a first major I'm alright with a proof-of-concept: as long as we can graphically plot tasks. We can make it more efficient after that.

[perlindgren]

Personally I have no experience with Flutter/Dart, so I don't have any strong opinion. An all Rust alternative might be Druid, but that is likely even more effort.
/Per

[tmplt]

Closing this as of 542b1f6 where a dummy frontend is spawned in a separate thread that simply prints the received api::EventChunks to stdout. For the sake of simplicity the data is passed via std::sync::mpsc instead of a Unix socket simply because the frontend is not a subprocess at the moment. This may change in the future. Also, note the current dummy value for the EventChunk timestamp.

Frontend spawning is very adhoc at the moment, and will be reconsidered during an upcoming refactor.

[tmplt]

Frontend spawning is very adhoc at the moment, and will be reconsidered during an upcoming refactor.

Frontends are now subprocesses that take no arguments and prints the path to the Unix domain socket it is listening to for api::EventChunks. Frontends are expected to be installed separately, i.e., an example RTIC software setup would be cargo install cargo-rtic-scope && cargo install rtic-scope-frontend-impl where impl is whatever frontend you spawn with cargo rtic-scope --frontend impl. rtic-trace-frontend-dummy has been updated to reflect these changes.