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:

<module name="sys_mon"/>

Module functions

Init Functions

These initialization functions are called once on startup.

• init_sysmon()

Event Functions

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

• event_sysmon()

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

• sys_mon.h

Source Files

• modules/core/rtos_mon.c
• arch dependent: modules/core/rtos_mon_arch.c

Raw sys_mon.xml file:

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