You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: profile/BareMetal2RTOS.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,7 +16,7 @@ Bare-metal designs rely on a [superloop](https://arm-software.github.io/CMSIS_6/
16
16
17
17
## Keil RTX (CMSIS-RTOS2 Kernel)
18
18
19
-
[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.
19
+
[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.
20
20
21
21
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.
22
22
@@ -30,7 +30,7 @@ As a result, high-priority interrupts always execute with predictable latency, i
30
30
31
31
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.
32
32
33
-
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.
33
+
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.
34
34
35
35
> **TIP**
36
36
>
@@ -50,11 +50,11 @@ This level of integration comes at the cost of increased footprint and a steeper
50
50
51
51
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.
52
52
53
-
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.
53
+
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.
54
54
55
55
## Further Reading
56
56
57
57
-[Shawn Hymel – When to Use an RTOS](https://shawnhymel.com/2928/when-to-use-an-rtos-an-important-decision-for-embedded-projects/)
58
58
-[Shawn Hymel – Zephyr vs FreeRTOS](https://shawnhymel.com/3106/zephyr-vs-freertos-how-to-choose-the-right-rtos-for-your-embedded-project/)
59
59
-[Nathan Jones - You Don't Need an RTOS](https://www.embeddedrelated.com/showarticle/1636.php)
Copy file name to clipboardExpand all lines: profile/CICD.md
+14-15Lines changed: 14 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,7 @@
4
4
5
5
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.
6
6
7
-
[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.
7
+
[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.
8
8
9
9
![CI/CD Process Overview](CICD_Overview.png"CI/CD Process Overview")
10
10
@@ -14,7 +14,7 @@ The underlying build system of [Keil Studio](https://www.keil.arm.com/) uses the
14
14
15
15
- 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.
16
16
- CMSIS solution files (`*.csolution.yml`) that enable seamless builds in CI, for example using GitHub actions.
17
-
-[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`.
17
+
-[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`.
18
18
19
19
### Automated Build Test
20
20
@@ -66,28 +66,28 @@ Raspberry Pi devices can serve as cost-effective self-hosted GitHub runners for
66
66
### Prerequisites
67
67
68
68
- Raspberry Pi 3 or newer (Arm64 architecture).
69
-
- microSD card (minimum 8 GB).
69
+
- microSD card (minimum 16 GB).
70
70
- Network connection (LAN or Wi-Fi).
71
71
- Debug probe (e.g. ULINKplus or ST-LINK) for target hardware connection.
72
72
73
73
### Setup Steps
74
74
75
75
The setup requires four steps:
76
76
77
-
1.[Create an image for the Raspberry Pi](#1-image-the-microsd-card)
78
-
2.[Configure your network access](#2-network-configuration-and-access)
79
-
3.[Install the development tools](#3-install-development-tools)
80
-
4.[Setup your GitHub runner](#4-setup-github-runner)
77
+
1.[Create microSD card image for Raspberry Pi](#1-create-microsd-card-image-for-raspberry-pi)
0 commit comments