profiling roborio apps

Does anyone know if kernel and/or user space support exists for profiling our FRC applications? Is oprofile in the kernel? Are the opcontrol apps in the file system?

It is my understanding that gprof is not supported by uclibc. Does the robot use uclibc and busybox?

I’ll investigate all this but was hoping my reverse engineering might be helped with input from beta users, WPI contributors and NI folks.

TIA

I have always used the profiler built into the LV scheduler, or the tracing that RT has in its schedulers. I checked with someone, and in the 2015 build, oprofile is in the kernel. I suspect it is in 2014 too.

Greg McKaskle

Thanks for the feedback Greg! We are using C++ so i reckon the LV profiling tools are not accessible or useful, correct?

Can you ask about the Task class? It appears to use pthreads but the priority stuff is not used. Are RT or non-zero static priorities supported in the kernel? Of course we’d have to run as root, not lvuser, to set the priorities.

These probably seem like goofy questions but our C++ code is based on standard practices using threads and messages rather than the WPI models. We routinely alter the relative priorities of our tasks in the cRio - it would be nice to do so again.

TIA

The LV profiling relies on instrumentation put in place by the LV compiler and hooks in the LV scheduler, so no, it won’t help. I believe the trace tool would show some minimal thread activity, but not routines.

I’ll ask on Monday. I would expect Task to be a simplified wrapper over pthreads. I would assume that you can change your own process’s thread priorities as lvuser within RLIMIT_RTPRIO values. The LV timed loop and time-critical priorities are after-all run as lvuser.

In case you haven’t seen it http://www.ni.com/white-paper/14626/en/#toc5 and especially the links in section five will give you some background on the linux configuration of the roboRIO. I expect that if you install the operf and other tools that you are set for profiling C++.

Greg McKaskle