The CDH Software System manages all aspects of our spacecraft’s command and data handling. The project is structured into three distinct layers:
- Embedded: Directly manages hardware components such as microcontrollers and peripheral interfaces.
- OS Level: Provides a set of APIs that build on the lower-level drivers to deliver system-level services.
- Debugging Interfaces: Comprises web-based UIs and logging tools to generate test reports and facilitate diagnostics.
The various software components are listed below:
graph TD
A[Space Concordia <br> SC-FREYR] --> B[Debugging Interfaces]
A --> C[OS Level]
A --> D[Embedded]
A --> E[Other ICs]
A --> F[Sensors & Actuators <br> Communication]
A --> G[Inter-Processor <br> Communication]
%% Debugging Interfaces
B --> B1[In-house Logger]
B --> B2[Battery Testing WSP]
B --> B3[LSP]
%% OS Level
C --> C1[Power Control API]
C --> C2[Message Processor API]
C --> C3[Watch Dog API]
C --> C4[RTC API]
C --> C5[Sensors API]
C --> C6[Actuators API]
%% Embedded
D --> D1[MSP430 FR5999]
D --> D2[SAMV71]
D --> D3[Watchdog?]
%% Other ICs
E --> E1[MRAM]
%% Sensors & Actuators Communication
F --> F1[Actuators]
F --> F2[Sensors]
F1 --> F1a[Reaction Wheels]
F1 --> F1b[Magnetorquer]
F2 --> F2a[Thermocouples]
F2 --> F2b[IMU]
F2 --> F2c[Sun Sensor]
%% Inter-Processor Communication
G --> G1[AX100]
G --> G2[S-Band]
Before you begin: Check out the Github essentials: #Docs/Github_Essentials.md
Your should be assigned an issue, You can go check it's requirements listed and start implementing it. Make sure you write good commit's with good descriptions. Then once you merge it into the stable branch we have an idea of what you did.
This is how you're development flow should look like: #Docs/branching_rules.md
The following document lists all the protocols required inter-MCU communication: Protocols -> Feel free to add required protocols whenever you want. Leave a comment for every change made.
MSP430 Project Setup and Structure MSP Structure
SAMV71 Project Setup and Structure Coming Soon
Our development adheres to NASA's Rule of Ten. For more details, please refer to the
- For C, NASA Rule of Ten.
- Branching, Successful Git Branching Model
- Commit Naming, Conventional Commits Specification
Branching strategy: Successful Git Branching Model.
Simplified Schematics from EPS: schematics
- Learning Resources: link
- How to Create Software Design Documents (Lucidchart)
- Digital Jhelms' GitHub Gist
This project is licensed under the MIT License.