Skip to content

Commit 5b27483

Browse files
kepler452b123kepler452b123
committed
added content to index for FreeRTOS tasks
1 parent 30153ff commit 5b27483

File tree

1 file changed

+126
-3
lines changed

1 file changed

+126
-3
lines changed

‎docs/src/content/docs/tasks/index.mdx‎

Lines changed: 126 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,8 +1,131 @@
11
---
2-
title: FreeRTOS tasks
3-
description: The FreeRTOS tasks throughout the codebase
2+
title: Modules/FreeRTOS tasks
3+
description: Overview of all of our running FreeRTOS Tasks
44
sidebar:
55
badge:
66
text: WIP
7-
variant: caution
7+
variant: success
8+
order: 4
89
---
10+
import { FileTree } from '@astrojs/starlight/components';
11+
12+
## Introduction
13+
14+
Often, understanding the starting point through which the application "does stuff" can give a more holistic view
15+
of our architecture and our folder/file organization. This helps put things into context when working on smaller scoped tasks
16+
and generally trying to understand parts of the codebase.
17+
18+
Our application can be broken into modules. This is the name we use to isolate a single FreeRTOS task, and any relevant
19+
logic specific to the task. You can think of FreeRTOS tasks like threads in an OS - FreeRTOS chooses which thread is running at one time,
20+
and these threads use other FreeRTOS tools, and our drivers, to perform logic and interact with our peripherals (note that
21+
this is a simplified explanation - FreeRTOS tasks are not exactly analagous to OS threads).
22+
23+
Tasks are our highest level of abstraction, with some of the FreeRTOS API and all of our periheral drivers directly underneath.
24+
25+
## File structure
26+
<FileTree>
27+
- obc
28+
- app
29+
- app_main.c
30+
- modules FreeRTOS tasks
31+
- alarm_mgr
32+
- ...
33+
- camera_mgr
34+
- ...
35+
- command_mgr
36+
- ...
37+
- comms_link_mgr
38+
- ...
39+
- digital_watchdog_mgr
40+
- ...
41+
- eps_mgr
42+
- ...
43+
- gnc_mgr
44+
- ...
45+
- health_collector
46+
- ...
47+
- logger
48+
- ...
49+
- state_mgr
50+
- ...
51+
- task_stats_collector
52+
- ...
53+
- telemetry_mgr
54+
- ...
55+
- timekeeper
56+
- ...
57+
</FileTree>
58+
59+
## About this guide
60+
61+
This guide aims to give a practical overview and understanding of what each FreeRTOS task we currently have does. It will start
62+
chronologically by what code executes. Though, there is no set order after the state manager.
63+
64+
The reader should be able to understand the specifics of how each task is implemented by referring to the codebase after
65+
understanding their general purposes and functions from this document. However, soon we will have guides up explaining each
66+
task more in depth, and how they are implemented.
67+
68+
## Understanding app_main.c
69+
70+
Before FreeRTOS starts, the application executes the code in app_main.c. You can think of this file as the true entry point to the
71+
firmware - similar to the main.c file in other projects. This file initializes general hardware for the RM46, creates the state manager task,
72+
and then starts the FreeRTOS scheduler. It is minimalistic by design, app_main does not have a lot of stack size.
73+
Once the main loop calls the FreeRTOS scheduler, the state manager task starts running.
74+
75+
## State manager
76+
77+
This task can be thought of as the **"initializing/config" task**. It currently creates the base states for tasks that
78+
track their own state (e.g. comms_manager), initializes most external peripherals, and initializes and starts running the
79+
other tasks. State manager currently does not yet have many events/functionality once the other tasks start running.
80+
(Note that the only event possible to send to its queue is a null event)
81+
82+
The actual config for all tasks can be found in
83+
<FileTree>
84+
- obc
85+
- app
86+
- rtos
87+
- obc_scheduler_config.h
88+
- obc_scheduler_config.c
89+
</FileTree>
90+
91+
The various functions used by the state manager to initialize and create the tasks can be found here, as well as the static config array
92+
containing all the fields needed by FreeRTOS for each task for those who are curious. This will also be explained in greater
93+
detail in the page focused solely on the state manager.
94+
95+
Though the task does not currently have any events that can be sent to its queue, in the future it is planned to also be responsible for
96+
- General RM46 system states (e.g. low power mode, testing/debug mode)
97+
- Handling resets
98+
- Controlling load switches
99+
100+
The state manager is a system service, along with the alarm handler, watchdog manager, logger, and timekeeper.
101+
102+
## System services vs mission services (todo: make this a tip/note)
103+
104+
Though this is not significant from a technical standpoint, our tasks can generally be thought of as either a system service or
105+
a mission service. This is not a distinction made using strict criteria.
106+
107+
The best explanation is that **system services manage the general upkeep of the software systems**, interacting minimally
108+
with the external world. They help ensure that the mission services function, and that there are no issues in the overall software.
109+
110+
**Mission services on the other hand perform needed functions for the cubesat systems**. They often interface and interact directly with
111+
the environment through sensors and devices (e.g. thermal manager gets temp data and then activates heaters, GNC manager
112+
uses motors, comms manager exchanges data between our satellite and the ground through a custom transceiver).
113+
114+
## Alarm manager
115+
116+
We need the capibility to execute commands at specific times. To do this, we have an RTC (the DS3232). However, the RTC can
117+
only alert to one event at a time. So what happens when we receive multiple time tagged commands in a short span, where all of them
118+
are set to some time in the future?
119+
120+
The alarm manager was created exactly for this purpose. It has a static queue (separate from its FreeRTOS queue) to track all
121+
the future alarms that need to be set in the RTC. The soonest of these alarms are then loaded into the RTC. Once an alarm
122+
is triggered, an event is sent to the alarm manager FreeRTOS queue, which signals to load the next soonest alarm.
123+
124+
Overall, **the alarm manager is responsible for managing all the alarms for the RTC**.
125+
126+
## Digital watchdog manager
127+
128+
129+
130+
131+

0 commit comments

Comments
 (0)