Paparazzi UAS  v5.14.0_stable-0-g3f680d1
Paparazzi is a free software Unmanned Aircraft System.
 All Data Structures Namespaces Files Functions Variables Typedefs Enumerations Enumerator Macros Modules Pages
sys_mon module

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):

  • periodic_time : time between two calls of the modules_periodic_task (averaged over 1s)
  • periodic_time_min : minimum time between two calls of the modules_periodic_task() during the last second
  • periodic_time_max : maximum time between two calls of the modules_periodic_task() during the last second
  • periodic_cycle : time it took to execute the main periodic functions (averaged over 1s)
  • periodic_cycle_min : minimum time it took to execute the main periodic functions during the last second
  • periodic_cycle_max : maximum time it took to execute the main periodic functions during the last second
  • event_number : number of times the event loop was called during the last second
  • cpu_load : rough estimate of cpu load (averaged over 1 sec)
  • 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:

  • nb_thread : number of threads running
  • cpu_load : rough estimate of cpu load (averaged over 1 sec)
  • core_free : Core free memory (bytes)
  • heap_free : Heap free memory (bytes)
  • 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).

Example for airframe file

Add to your firmware section:

1 <module name="sys_mon"/>

Module functions

Init Functions

These initialization functions are called once on startup.

Event Functions

These event functions are called in each cycle of the module event loop.

Periodic Functions

These functions are called periodically at the specified frequency from the module periodic loop.

  • periodic_report_sysmon()
    • Frequency in Hz: 1.
    • Autorun: LOCK
      Periodic function automatically starts after init and can't be stopped.
  • periodic_sysmon()
    • Running at maximum module frequency.
    • Autorun: LOCK
      Periodic function automatically starts after init and can't be stopped.

Files

Header Files

The following headers are automatically included in modules.h

Source Files

Raw sys_mon.xml file:

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