Cosmetic fixes

profile/BareMetal2RTOS.md

@@ -16,7 +16,7 @@ Bare-metal designs rely on a [superloop](https://arm-software.github.io/CMSIS_6/
 
 ## Keil RTX (CMSIS-RTOS2 Kernel)
 
-[Keil RTX](https://www.keil.arm.com/packs/cmsis-rtx-arm) is Arm’s reference RTOS kernel implementation for CMSIS-RTOS2 and is designed with strict real-time and safety requirements in mind. A key architectural property of RTX is that it never globally blocks interrupts to implement scheduling or synchronization. Instead, it relies on bounded critical sections, priority-aware mechanisms, and Arm Cortex-M architectural features to maintain kernel consistency while preserving interrupt responsiveness.
+[Keil RTX](https://www.keil.arm.com/packs/cmsis-rtx-arm) is Arm’s reference RTOS kernel implementation for [CMSIS-RTOS2](https://arm-software.github.io/CMSIS_6/latest/RTOS2/index.html) and is designed with strict real-time and safety requirements in mind. A key architectural property of RTX is that it never globally blocks interrupts to implement scheduling or synchronization. Instead, it relies on bounded critical sections, priority-aware mechanisms, and Arm Cortex-M architectural features to maintain kernel consistency while preserving interrupt responsiveness.
 
 As a result, high-priority interrupts always execute with predictable latency, independent of RTOS activity. Communication between ISRs and threads is explicitly defined through CMSIS-RTOS2 APIs that are safe to call from interrupt context, ensuring that time-critical interrupt handling remains separate from deferred thread-level processing. This behavior makes RTX particularly suitable for safety-critical and real-time control systems where interrupt masking must be minimized or avoided altogether. For [safety-critical applications](#functional-safety), the [MDK-Professional edition](https://www.keil.arm.com/keil-mdk/) includes FuSa RTS, a TÜV certified version of Keil RTX.
 
@@ -30,7 +30,7 @@ As a result, high-priority interrupts always execute with predictable latency, i
 
 Internally, FreeRTOS may temporarily mask interrupts as part of its kernel operation. Interrupts at or below a configured priority level are deferred while kernel data structures are updated. While this behavior is well-documented, it introduces interrupt latency that depends on kernel activity and requires careful interrupt priority configuration. Application code written against the native FreeRTOS API is also not inherently portable across RTOS implementations.
 
-Using the standardized CMSIS-RTOS2 API layer decouples application code from the underlying kernel by providing a common interface for threads, synchronization primitives, and timers. CMSIS-RTOS2 is used natively by Keil RTX and FuSa RTS and is also supported by FreeRTOS and Zephyr via wrapper layers. This abstraction is particularly valuable in projects that prioritize portability, long-term maintainability, or safety certification.
+Using the standardized CMSIS-RTOS2 API layer decouples application code from the underlying kernel by providing a common interface for threads, synchronization primitives, and timers. [CMSIS-RTOS2](https://arm-software.github.io/CMSIS_6/latest/RTOS2/index.html) is used natively by Keil RTX and FuSa RTS and is also supported by FreeRTOS and Zephyr via wrapper layers. This abstraction is particularly valuable in projects that prioritize portability, long-term maintainability, or safety certification.
 
 > **TIP**
 >
@@ -50,11 +50,11 @@ This level of integration comes at the cost of increased footprint and a steeper
 
 Selecting between bare-metal, Keil RTX, FreeRTOS, and Zephyr depends on system complexity, longevity, and non-functional requirements. Bare-metal designs favor simplicity, minimal overhead, and unrestricted hardware control. FreeRTOS and Keil RTX provide a middle ground, offering multitasking with relatively low overhead. Zephyr targets product-scale systems that benefit from a rich ecosystem and enforced structure.
 
-When portability across RTOS kernels or safety standards is a primary concern, CMSIS-RTOS2 combined with an appropriate kernel provides a clean abstraction that reduces long-term risk.
+When portability across RTOS kernels or safety standards is a primary concern, [CMSIS-RTOS2](https://arm-software.github.io/CMSIS_6/latest/RTOS2/index.html) combined with an appropriate kernel provides a clean abstraction that reduces long-term risk.
 
 ## Further Reading
 
 - [Shawn Hymel – When to Use an RTOS](https://shawnhymel.com/2928/when-to-use-an-rtos-an-important-decision-for-embedded-projects/)
 - [Shawn Hymel – Zephyr vs FreeRTOS](https://shawnhymel.com/3106/zephyr-vs-freertos-how-to-choose-the-right-rtos-for-your-embedded-project/)
 - [Nathan Jones - You Don't Need an RTOS](https://www.embeddedrelated.com/showarticle/1636.php)
-- [Arm – CMSIS-RTOS2 Overview](https://arm-software.github.io/CMSIS_5/RTOS2/html/index.html)
+- [Arm – CMSIS-RTOS2 Overview](https://arm-software.github.io/CMSIS_6/latest/RTOS2/index.html)

profile/CICD.md

@@ -4,7 +4,7 @@
 
 Modern embedded software development requires automated workflows that ensure code quality, enable rapid iteration, and support collaborative development. CI/CD practices bring these capabilities to embedded systems, helping teams deliver reliable firmware faster while maintaining high quality standards.
 
-[MDK](https://www.keil.arm.com/keil-mdk/) includes tools to establish comprehensive CI/CD workflows that include [automated builds](#automated-build-test) as well as unit testing and integration testing on [simulation models](#arm-fixed-virtual-platforms-fvp) or [target hardware](#hil-testing-with-pyocd). [Keil Studio](https://marketplace.visualstudio.com/items?itemName=Arm.keil-studio-pack/) is based on VS Code that integrates Git features and offers several VS Code extensions for static code analysis. The [CMSIS-Toolbox](https://open-cmsis-pack.github.io/cmsis-toolbox/) is a command-line interface for building embedded applications, enabling seamless integration with popular CI/CD platforms (like GitHub Actions). Integration with static code analysis tools (e.g. MISRA checking) is achieved with standard database files that third-party tools can consume.
+[MDK](https://www.keil.arm.com/keil-mdk/) includes tools to establish comprehensive CI/CD workflows that include [automated builds](#automated-build-test) as well as unit testing and integration testing on [simulation models](#arm-fixed-virtual-platforms-fvp) or [target hardware](#hil-testing-with-pyocd). [Keil Studio](https://marketplace.visualstudio.com/items?itemName=Arm.keil-studio-pack) is based on VS Code that integrates Git features and offers several VS Code extensions for static code analysis. The [CMSIS-Toolbox](https://open-cmsis-pack.github.io/cmsis-toolbox/) is a command-line interface for building embedded applications, enabling seamless integration with popular CI/CD platforms (like GitHub Actions). Integration with static code analysis tools (e.g. MISRA checking) is achieved with standard database files that third-party tools can consume.
 
 ![CI/CD Process Overview](CICD_Overview.png "CI/CD Process Overview")
 
@@ -14,7 +14,7 @@ The underlying build system of [Keil Studio](https://www.keil.arm.com/) uses the
 
 - Consistent tool installation based on a single [`vcpkg-configuration.json`](https://github.com/Arm-Examples/Hello_World/blob/main/vcpkg-configuration.json) file for desktop and CI environments.
 - CMSIS solution files (`*.csolution.yml`) that enable seamless builds in CI, for example using GitHub actions.
-- [Run and Debug Configuration](https://open-cmsis-pack.github.io/cmsis-toolbox/build-overview/#run-and-debug-configuration) for pyOCD that uses a single configuration file `*.cbuild-run.yml`. 
+- [Run and Debug Configuration](https://open-cmsis-pack.github.io/cmsis-toolbox/build-overview/#run-and-debug-configuration) for pyOCD that uses a single configuration file `*.cbuild-run.yml`.
 
 ### Automated Build Test
 
@@ -66,28 +66,28 @@ Raspberry Pi devices can serve as cost-effective self-hosted GitHub runners for
 ### Prerequisites
 
 - Raspberry Pi 3 or newer (Arm64 architecture).
-- microSD card (minimum 8 GB).
+- microSD card (minimum 16 GB).
 - Network connection (LAN or Wi-Fi).
 - Debug probe (e.g. ULINKplus or ST-LINK) for target hardware connection.
 
 ### Setup Steps
 
 The setup requires four steps:
 
-1. [Create an image for the Raspberry Pi](#1-image-the-microsd-card)
-2. [Configure your network access](#2-network-configuration-and-access)
-3. [Install the development tools](#3-install-development-tools)
-4. [Setup your GitHub runner](#4-setup-github-runner)
+1. [Create microSD card image for Raspberry Pi](#1-create-microsd-card-image-for-raspberry-pi)
+2. [Configure network access](#2-configure-network-access)
+3. [Install development tools](#3-install-development-tools)
+4. [Setup GitHub runner](#4-setup-github-runner)
 
-#### 1. Image the microSD Card
+#### 1. Create microSD Card Image for Raspberry Pi
 
-- Use [Raspberry Pi Imager](https://www.raspberrypi.com/software/) to install Ubuntu Server 24.04 LTS (64-bit).
+- Use [Raspberry Pi Imager](https://www.raspberrypi.com/software) to install Ubuntu Server 24.04 LTS (64-bit).
 - Configure hostname (e.g., `rpi-ci`), user credentials, SSH access, and network settings during the imaging process.
   See [Ubuntu installation guide for Raspberry Pi](https://ubuntu.com/tutorials/how-to-install-ubuntu-on-your-raspberry-pi).
 
-#### 2. Network Configuration and Access
+#### 2. Configure Network Access
 
-Configure network access and establish SSH connection for remote management.
+Configure your network access and establish SSH connection for remote management.
 
 ```bash
 # Determine the Raspberry Pi's MAC address (useful for network registration)
@@ -139,14 +139,13 @@ tar -xf cmsis-toolbox-linux-arm64.tar.gz
 
 # Download and extract pyOCD
 wget https://github.com/pyocd/pyOCD/releases/download/v0.42.0/pyocd-linux-arm64-0.42.0.zip
-mkdir pyocd_42 && cd pyocd_42
+mkdir pyocd && cd pyocd
 unzip ./../pyocd-linux-arm64-0.42.0.zip
 cd ..
 
 # Set up environment variables (persist across reboots)
-echo 'export PATH="$HOME/pyocd_42:$PATH"' >> ~/.bashrc
-echo 'export CMSIS_TOOLBOX_ROOT="$HOME/cmsis-toolbox-linux-arm64"' >> ~/.bashrc
-echo 'export PATH="$CMSIS_TOOLBOX_ROOT/bin:$PATH"' >> ~/.bashrc
+echo 'export PATH="$HOME/pyocd:$PATH"' >> ~/.bashrc
+echo 'export PATH="$HOME/cmsis-toolbox-linux-arm64/bin:$PATH"' >> ~/.bashrc
 echo 'export CMSIS_PACK_ROOT="$HOME/packs"' >> ~/.bashrc
 source ~/.bashrc