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)
Notes on Control and Estimation
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.
Notes on CPU Load vs. peripheral / IO Load
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
Notes on the displayed stack size
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.
Notes on the Number of Tasks
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.