mirror of
https://github.com/paparazzi/paparazzi.git
synced 2026-05-09 22:49:53 +08:00
Michal Podhradsky
41b2e7ec47
Only one module (sys_mon) used - it will automatically detect if it is rtos, sim or bare-metal and will send the proper message (RTOS_MON or SYS_MON). Easier to use because the user don't have to change between sys_mon and rtos_mon anymore. Plus added support for CPU load on SIM targets
64 lines
2.9 KiB
XML
64 lines
2.9 KiB
XML
<!DOCTYPE module SYSTEM "module.dtd">
|
|
|
|
<module name="sys_mon" dir="core">
|
|
<doc>
|
|
<description>
|
|
System monitor.
|
|
The sys_mon module gives you some information about the timing of the periodic tasks and a rough estimate of cpu load (averaged over 1 sec).
|
|
For systems with RTOS it also gives you stats about threads and memory usage.
|
|
|
|
For bare-metal systems, the SYS_MON message contains the following information (all times are given in microseconds):
|
|
- @b periodic_time : time between two calls of the modules_periodic_task (averaged over 1s)
|
|
- @b periodic_time_min : minimum time between two calls of the modules_periodic_task() during the last second
|
|
- @b periodic_time_max : maximum time between two calls of the modules_periodic_task() during the last second
|
|
- @b periodic_cycle : time it took to execute the main periodic functions (averaged over 1s)
|
|
- @b periodic_cycle_min : minimum time it took to execute the main periodic functions during the last second
|
|
- @b periodic_cycle_max : maximum time it took to execute the main periodic functions during the last second
|
|
- @b event_number : number of times the event loop was called during the last second
|
|
- @b cpu_load : rough estimate of cpu load (averaged over 1 sec)
|
|
- @b cpu_time : time in seconds since start-up
|
|
|
|
So your periodic_time should be 1/MODULES_FREQUENCY, which should be the same as 1/PERIODIC_FREQUENCY
|
|
The periodic_cycle_max should not be over the periodic_time, otherwise in at least one cycle it took longer to calculate everything and the next one was slightly delayed.
|
|
The sys_mon module has to run at the full main frequency!
|
|
So either don't specify a main_freq parameter for the modules node or set your actual main frequency
|
|
|
|
|
|
For systems with RTOS, RTOS_MON message is sent instead and the following information are shown:
|
|
- @b nb_thread : number of threads running
|
|
- @b cpu_load : rough estimate of cpu load (averaged over 1 sec)
|
|
- @b core_free : Core free memory (bytes)
|
|
- @b heap_free : Heap free memory (bytes)
|
|
- @b cpu_time : time in seconds since start-up
|
|
|
|
Again, the sys_mon module has to run at the full main frequency (so the reports are generated at 1 second intervals).
|
|
</description>
|
|
</doc>
|
|
<header>
|
|
<file name="sys_mon.h"/>
|
|
</header>
|
|
<init fun="init_sysmon()"/>
|
|
<periodic fun="periodic_report_sysmon()" freq="1."/>
|
|
<periodic fun="periodic_sysmon()"/>
|
|
<event fun="event_sysmon()"/>
|
|
|
|
<makefile target="ap">
|
|
<raw>
|
|
# for ChibiOS arch include rtos_mon.c and rtos_mon_arch.c
|
|
ifeq ($(ARCH), chibios)
|
|
$(TARGET).srcs += $(SRC_MODULES)/core/rtos_mon.c
|
|
$(TARGET).srcs += $(SRC_ARCH)/modules/core/rtos_mon_arch.c
|
|
else
|
|
# for all other architecture use existing sys_mon.c
|
|
$(TARGET).srcs += $(SRC_MODULES)/core/sys_mon.c
|
|
endif
|
|
</raw>
|
|
</makefile>
|
|
|
|
<makefile target="nps">
|
|
<file name="rtos_mon.c"/>
|
|
<file_arch name="rtos_mon_arch.c"/>
|
|
</makefile>
|
|
</module>
|
|
|