Tracking ISR runtime

Richard, Is it possible to modify saveContext and restoreContext to make a call to traceContextSwitchedOut and traceContextSwitchedIn to track OS and ISR overhead?  Currently, what is happening is that if you use a lot of Interrupts, the # ticks account towards unknown tasks or Idle time, when it shouldn’t. On a different note, what is the reasoning behind some function calls to start with v, others start with x, and some start with ux ?
Thanks. Preet

Tracking ISR runtime

s it possible to modify saveContext and restoreContext to make a call to traceContextSwitchedOut and traceContextSwitchedIn to track OS and ISR overhead? Currently, what is happening is that if you use a lot of Interrupts, the # ticks account towards unknown tasks or Idle time, when it shouldn’t.
It is easy to put whatever trace you like inside the ISR once the context is saved (if a context is saved). Doing it before the context is saved, so the save time is timed, is much more difficult and port dependent.
On a different note, what is the reasoning behind some function calls to start with v, others start with x, and some start with ux ?
Look at the very end of this page http://www.freertos.org/a00017.html#NamingConventions

Tracking ISR runtime

Thanks for the great reply Edward!