update README

Author: Ibrassow

README.md

@@ -1,9 +1,18 @@
-# Flight Software for the PyCubed Board (Argus-1)
+# Flight Software for the Argus Board
 
-The repository contains the current flight software stack for the **Mainboard** of Argus-1. Argus-1 is a technology demonstration mission with the goal of:
-- Demonstrating Vision-based Orbit Determination (A&OD) on a low-cost satellite (devoid of any GPS or ground involvement)
-- Collecting a dataset of images of the Earth to further efforts in CubeSat visual applications.
-- Demonstrating efficient on-orbit ML/GPU Payload processing 
+The repository contains the current flight software for the **Mainboard** of Argus. Argus is a technology demonstration mission with the goal of demonstrating vision-based Orbit Determination on a low-cost satellite (devoid of any GPS or ground involvement). We also aim to collect a decent dataset of images of the Earth to further efforts in CubeSat visual applications and demonstrate efficient on-orbit ML/GPU processing.
+
+## Architecture 
+
+See [High-Level Architecture](docs/architecture.md)
+
+## Hardware 
+
+The flight software currently supports:
+- Argus v1 (ATSAMD51J20)
+- Argus v1.1
+- Argus v2 (RP2040, in testing)
+- Argus v3 (STM32 variant, board in dev) 
 
 ## Build and Execution
 
@@ -13,7 +22,7 @@ Building current files and moving them to the board can be handled by the run.sh
 ```bash
 ./run.sh
 ```
-The script first builds and compiles the flight software files to .mpy files and transfers them to the mainboard you are connected to.
+The script first builds and compiles the flight software files to .mpy files and transfers them to the mainboard you are connected to. The compilation is supported on Linux, MacOS, and Windows.
 
 ### Without mainboard
 

docs/architecture.md

@@ -0,0 +1,19 @@
+# Architecture
+
+The onboard flight software for Argus-1 follows a hierarchical architecture, structured into distinct layers that isolate hardware interfacing, fault handling, core functionalities, and mission-specific applications.
+
+## Hardware Abstraction Layer (HAL)
+The HAL interfaces directly with the spacecraft’s hardware, managing initialization, communication, and status reporting for all hardware components across the spacecraft bus (excluding payload elements). This layer ensures consistent, low-level access to the hardware, abstracting specific details to provide a standardized interface for higher software layers.
+
+## Middleware
+The middleware layer acts as a wrapper around the HAL, adding local fault-handling capabilities based on defined drivers and associated handling functions. It enables safe and reliable interactions with hardware components and manages fault conditions at the HAL level.
+
+## Core Framework
+The core framework layer is responsible for essential system services such as data handling (telemetry, onboard mass storage), task scheduling, state management, and command processing. This layer forms the backbone of the flight software, managing the flow of data and commands within the system.
+
+## Application Layer
+The application layer contains mission-specific software, including attitude determination and control, communication protocols, and payload control systems. This layer focuses on the execution of mission objectives and includes high-level functionality required for autonomous operations.
+
+<p align="center">
+    <img src="hl_diag.png" alt="Architecture Diagram">
+</p>

docs/hl_diag.png

@@ -20,7 +20,7 @@ def print_memory_stats(call_gc=True):
     if path not in sys.path:
         sys.path.append(path)
 
-setup_logger(level="NOTHING")
+setup_logger(level="INFO")
 
 print_memory_stats(call_gc=True)