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
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!