mirror of
https://github.com/paparazzi/paparazzi.git
synced 2026-05-09 22:49:53 +08:00
Gautier Hattenberger
62646d68de
Add two new items in module's dependency: - recommends: a recommended module tells the sorting algo that if the module is found, it should be sorted accordingly. It is useful for optional dependencies, like shell or mission in some modules - suggests: if a functionality is not provided by the user, a module can suggest a list of modules that can provide them. It is a convenient way to have "default" modules. As a result the former autoload node is removed and replaced by suggested modules.
67 lines
2.9 KiB
XML
67 lines
2.9 KiB
XML
<!DOCTYPE module SYSTEM "module.dtd">
|
|
|
|
<module name="sys_mon" dir="core" task="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>
|
|
<dep>
|
|
<recommends>shell</recommends>
|
|
</dep>
|
|
<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>
|
|
|