The top application is a standard Unix tool to show the system usage. This implementation mimics most top implementations, but is less verbose and confined to the basic functionality.

The output will look similar to the output below.

Processes: 4 total, 0 running, 0 sleeping
CPU usage: 25.46% tasks, 0.12% sched, 74.41% idle
Uptime: 11408.519 s total, 11347.888 s idle

PID     COMMAND                            CPU TOTAL    %CPU CURR       MIN STACK USE   CURR (BASE) PRIO        RR SLICE
  1     work                               50382 ms       0.069             160 B       199     (199)           1
  7     sensors                             7927 ms      24.000            1224 B       250     (250)           1
  8     top                                  131 ms       0.092             752 B       90      (90)            1
[ Hit Ctrl-C to quit. ]

The individual numbers mean:

• Processes: tasks or pthreads. Running: Ready to run - there should be never more than one process ready to run, else the system is overloaded.
• CPU usage:
  • user all processes started as apps
  • sys system overhead, such as scheduler time, interrupt handling, etc.
  • idle time of idle thread where system is not active at all
• Uptime: Total uptime (since power on) in seconds, idle uptime (where system was on but did not process anything)
• Process List:
  • PID: process identifier.
  • COMMAND: name of the app / task / thread
  • CPU TOTAL: Total time this task has been executed since it was started
  • %CPU CURR: Current CPU usage in percent (within the last measurement interval, in this case 1 second)

The system load and the correct timing of controllers and estimators only loosely depend on each other: If the sensor readout, estimation and control tasks have a high priority, it is not a problem if the system is running at 90% load - they will not be delayed or slowed down and still execute at the predefined rate. If the task priorities are however not correctly set or other high-priority tasks exist, a higher load can lead to delays.

The load shown here is the total load, consisting of CPU delay (due to processing on the CPU) and IO delay (due to sensor interfacing). It shows wether the system is able to meet the deadlines. To time processing, use the high resolution timer. In the example below the 30% load are almost only due to I/O delay, which is known due to the internal code structure of the sensors app.

The displayed stack size is evaluated using the stack pointer at context switch time. It therefore is not the actual stack size needed during execution, but the minimum stack size the process needs at runtime. The real needed stack size will be typically about 60-1000 bytes more.

A higher number of tasks does not imply more load of the system, only higher RAM usage. Almost all tasks in the example below sleep and are wakened by the scheduler once new data is ready to be processed. This is however only true if the tasks do not poll, but are using blocking reads on file descriptors or signals. If tasks would actively poll, they would add to the system load and more tasks would mean more load.