-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Send decoded and resolved ITM data to a frontend #3
Comments
@Yatekii, did you have a public front-end prototype in the works that can be experimented with? |
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. 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 :) |
Neat. What do you think of moving it here, under RTIC Scope?
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.
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.
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 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. |
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. |
This is a quick and dirty commit that resolves api::EventChunk from itm_decode::TimestampedTracePackets. For now, only TracePacket::{Overflow, ExceptionTrace} are converted because of the presently small scope of the API. Only exceptions and IRQ numbers that are mapped can be converted, but all packets are still saved to file. XXX api::EventChunk { timestamp } is a dummy variable. Proper timestamps have yet to be resolved. Related to #3. Related to #4.
Closing this as of 542b1f6 where a dummy frontend is spawned in a separate thread that simply prints the received 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 |
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:
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:
CC @Yatekii @perlindgren
The text was updated successfully, but these errors were encountered: