CPU Monitor Tenant

[AarC10]

This closes #316

Description

Add a tenant that monitors CPU statistics including the uptime, die temperature and utilization percentage. Note this is not going to be fully integrated with backplane firmware yet, because I want to make some changes to messaging and networking. This will also allow us to monitor at a high-level how much a software change affects the CPU utilization, without needing specialized tools and software to analyze.

Type of change

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Created a new sample that prints the statistics.

Sleeping for 1 second before getting statistics

No sleep

Checklist:

• New functionality is documented in the necessary spots (i.e new functions documented in the header)
• Unit tests cover any new functionality or edge cases that the PR was meant to resolve (if applicable)
• The CI checks are passing
• I reviewed my own code in the GitHub diff and am sure that each change is intentional
• I feel comfortable about this code flying in a rocket

[Copilot]

Pull Request Overview

This PR adds CPU monitor tenant functionality and die temperature support across several board and module configurations while fixing compiler errors and cleaning up code. Key changes include:

• Enabling ADC and STM32 temperature sensor support in defconfigs and DTS files.
• Integrating a new CPU monitor tenant in both the sensor module and the sample application.
• Updating build configurations and sample files to support the new monitoring features.

Reviewed Changes

Copilot reviewed 22 out of 24 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
boards/arm/sensor_module/sensor_module_defconfig	Added ADC and temperature sensor configuration options.
boards/arm/sensor_module/sensor_module.dts	Added die-temp node and alias for temperature monitoring.
boards/arm/radio_module/*	Enabled RTC, ADC, and temperature sensor support in defconfig and DTS.
boards/arm/power_module/*	Updated defconfig and DTS with ADC and temperature sensor options (note duplicate CONFIG_SENSOR).
boards/arm/deployment_module/*	Added ADC, sensor, and temperature sensor configurations and DTS entries.
app/samples/cpu_monitor/*	Introduced CPU monitor sample application and updated build configurations.
app/backplane/sensor_module/*	Integrated CPU monitor tenant into sensor module.
.github/workflows/build_samples.yml	Included cpu_monitor sample in the build workflow.

Files not reviewed (2)

• app/backplane/sensor_module/.idea/csv-editor.xml: Language not supported
• app/samples/cpu_monitor/.idea/.gitignore: Language not supported

Comments suppressed due to low confidence (1)

boards/arm/power_module/power_module.dts:32

• [nitpick] Inconsistent indentation observed for the 'die-temp' alias; consider aligning it with surrounding entries for improved readability.

		die-temp = &die_temp;

[AarC10]

TODO: Need to do a delta

[AarC10]

Note that there is a separate PR I want to do so we can run tenants periodically without threading

[cowsed]

Overall, does this give us a ton more than just the builtin thread monitor in zephyr? Die temp is nice but do we ever care about it in a way that it isnt more directly integrated into the application (logged to flight data in flash and the like)?
(and uptime is in every LOG_* message)

[AarC10]

Overall, does this give us a ton more than just the builtin thread monitor in zephyr? Die temp is nice but do we ever care about it in a way that it isnt more directly integrated into the application (logged to flight data in flash and the like)? (and uptime is in every LOG_* message)

This is just a very basic way to monitor the CPU. You can only read uptime if you are connected to UART which may not be the case. The idea is to have this published by a module over Ethernet. At some point I would like to publish more of the thread stuff over Ethernet too, and we can run this as a very low priority task. For die temp, I dont think it hurts to have as well. It would be nice to just have more insight into what is going on with our system as we start doing more data analysis and new things to think about for improvement