Live Q&A - Troubleshooting Embedded Applications with Runtime Visualizations

Hi
As i deduct from the talk this only works if you have a "real" OS?
Most of the systems I come across only have what we call a "Camshaft OS", meaning interrupts is the only threadding available. In other words: 1 task == 1 ISR
Can this tool (realistically) be used for those systems?
One example is that i often use an I/O pin to visualize how often and for how long an ISR is running, By simply putting a pin_high, and pin_low, at the beginning and end of the ISR, then connectiong a osciloscope to that pin (or pins)
This however has several limitations, for one it does not tell me anything of the timing overhead in shifting in and out of that interrupt, as the pin high/low happens inside the IRQ. Also I have to manually measure and compenstae if this is not the higest level IRQ, thus it itself can be interruptet. Not to say if it interrups itself....
I don't know if this information is present in the ETM. But also could this tool help ilustrating this?

Great Talk Kristoffer!
Hearing all the interesting questions in the Q&A, brought up another question on my side: For the use case of porting an application from on Target/Rtos/... to another: How generic is the instrumentation of the code?
Is it possible to instrument once and then use Tracelyzer in any setup? If not- How complicated is the adoption to different Target-Set-Ups?
Thanks,
Andreas

There is not nearly enough emphasis put on the benefit of visualization tools in understanding the behavior of your system better, and of RTOSs in general. To that point, I can see Tracealyzer being a great educational tool. Computer engineering students learn about task scheduling by drawing it out; I can see a huge benefit in incorporating this tool after they have base knowledge of scheduling and are now ready to see it for a real system.

Amazing presentation and demos, thank you for this very valuable content! :)

Hi Kristoffer... Amazing talk... Of course the Percepio tools are the best to find and analyze strange situations... I have used the tool with the debugger connected to obtain the real data from the device... I have a question... There is a way to save the Percepio information for example in Flash memory to obtain real issues in the field? I have had strange issues to analyze but in the real field... not in development environment... Is possible save that details and after analyze the situations recover the information from the Flash memory? BTW: My favorite technique to track issues is Application Logging

Great multi-queue blocking demo, thanks

Thanks for this nice presentation along with the demos. I'm using Tracealyzer now for rughly 3 years and it helped a lot to understand the timing of our application. I truely agree that it is much easier to analyze and understand what's causing a problem if you have a visual view on it.
It is also very useful to see if you have any bottlenecks in your software and see where starting to optimize is beneficial.
Some more capabilities to do automated measuring and analysis would be fine.

Great presentation and great tool, I'm learning every day more features. Some improvements in the usability would be needed, e.g. while measuring the distance between events (one must select the time span on the trace, it would be also nice to have the possibility to select two events in the log or on the events name in the trace and get immediately the time difference).