Compare commits
76 Commits
dev
...
docs-trunk
| Author | SHA1 | Date |
|---|---|---|
|
|
88020672b7 | |
|
|
1cc34d8709 | |
|
|
a674f5280a | |
|
|
c1943f8c68 | |
|
|
53e6d1a679 | |
|
|
2df92aabf9 | |
|
|
0bf088c117 | |
|
|
8d612d05c0 | |
|
|
2cef4a73a4 | |
|
|
d1144f0c7b | |
|
|
a009c9037b | |
|
|
ac96045fd1 | |
|
|
af01300b82 | |
|
|
689ad95a62 | |
|
|
ed114dbaf9 | |
|
|
917bba073c | |
|
|
c5bcb2932e | |
|
|
4f8acc5e16 | |
|
|
0649c6233b | |
|
|
7ba6ed4d75 | |
|
|
952e91c630 | |
|
|
d292b2d0d6 | |
|
|
0e6d4fbe2c | |
|
|
12d45a294f | |
|
|
9407f8d73f | |
|
|
c1d0fa7530 | |
|
|
7bbef47dae | |
|
|
a04a168480 | |
|
|
e80f1d2916 | |
|
|
ba5ed2eacf | |
|
|
36232a9fd7 | |
|
|
f056adf2f2 | |
|
|
a127d5dd91 | |
|
|
1b369ff501 | |
|
|
63dcddf2f0 | |
|
|
d4536f1c43 | |
|
|
c7c540f472 | |
|
|
1870c8f2d5 | |
|
|
8aab4f69b0 | |
|
|
70764b3a61 | |
|
|
0e0c15c12b | |
|
|
202d8bfa52 | |
|
|
f05b040dfb | |
|
|
d5b124c1e3 | |
|
|
4f25280885 | |
|
|
daed5ebf8e | |
|
|
cd6ed80a15 | |
|
|
182fe127dd | |
|
|
53b7c507f5 | |
|
|
531e9bcaae | |
|
|
26863182c3 | |
|
|
891dbcc0f1 | |
|
|
53ccc1dd9b | |
|
|
1bab4b4faa | |
|
|
01149e37d1 | |
|
|
cb8e826498 | |
|
|
58025ef7f7 | |
|
|
8ef2472d77 | |
|
|
f03dd7d2cf | |
|
|
e8e90c3996 | |
|
|
935d419691 | |
|
|
dbc4cc3987 | |
|
|
63d8ecade1 | |
|
|
c5039eb7a0 | |
|
|
afbe1041a1 | |
|
|
f2048e0a90 | |
|
|
bef74a1640 | |
|
|
b038a81788 | |
|
|
59ec889b94 | |
|
|
8b215997c8 | |
|
|
affeced945 | |
|
|
ceb2f53ab1 | |
|
|
f234b27ff5 | |
|
|
0919d784cb | |
|
|
2d302e6ba7 | |
|
|
66483f41d2 |
|
|
@ -1 +1 @@
|
|||
* @aiduxiaoxiong @smile0425 @tanghao-xiaomi @TangMeng12 @yanxingyu17
|
||||
* @xiaoxiang781216 @aiduxiaoxiong @smile0425 @tanghao-xiaomi @TangMeng12 @yanxingyu17
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
*Note: Please adhere to [Contributing Guidelines](https://github.com/open-vela/docs/blob/dev/CONTRIBUTING.md).*
|
||||
*Note: Please adhere to [Contributing Guidelines](https://github.com/open-vela/docs/blob/trunk/CONTRIBUTING.md).*
|
||||
|
||||
## Summary
|
||||
|
||||
|
|
|
|||
|
|
@ -10,5 +10,5 @@ on:
|
|||
# A workflow run is made up of one or more jobs that can run sequentially or in parallel
|
||||
jobs:
|
||||
checkpatch:
|
||||
uses: open-vela/public-actions/.github/workflows/checkpatch.yml@trunk
|
||||
uses: open-vela/public-actions/.github/workflows/checkpatch.yml@dev
|
||||
secrets: inherit
|
||||
|
|
|
|||
|
|
@ -2,10 +2,10 @@ name: 'Close stale issues and PR'
|
|||
on:
|
||||
schedule:
|
||||
- cron: '30 1 * * *'
|
||||
workflow_dispatch: # 允许手动触发
|
||||
workflow_dispatch: # Manual triggering is allowed.
|
||||
|
||||
jobs:
|
||||
stale:
|
||||
uses: open-vela/public-actions/.github/workflows/stale.yml@trunk
|
||||
uses: open-vela/public-actions/.github/workflows/stale.yml@dev
|
||||
secrets: inherit
|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Contributing to openvela
|
||||
|
||||
\[ English | [简体中文](CONTRIBUTING_zh-cn.md) | [繁體中文](CONTRIBUTING_zh-tw.md) \]
|
||||
[ English | [简体中文](CONTRIBUTING_zh-cn.md)]
|
||||
|
||||
openvela is developed by an active team of software engineers and researchers.You are welcome to join openvela, an open source community, and contribute in any way to this project!
|
||||
|
||||
|
|
@ -45,6 +45,16 @@ Follow these tips before making a pull request to speed up the review.
|
|||
- Lines that are not part of your change should not be edited (e.g. **don't format unchanged lines, don't reorder existing imports**).
|
||||
- Add the appropriate license headers to any new files.
|
||||
|
||||
### Before Submitting Your Code
|
||||
|
||||
Following these guidelines before creating a new pull request will help speed up the review and merge process.
|
||||
|
||||
- **Follow the Code Style Guide**: Ensure your code submission conforms to the [openvela Code Style Check Guide](./en/contribute/code_style_check_guide.md). Running local checks before submitting can help prevent unnecessary failures in the Continuous Integration (CI) pipeline.
|
||||
- **Add License Headers**: Add the standard license header to all new files.
|
||||
- **Add Unit Tests**: Include appropriate unit tests for your code changes to verify their correctness.
|
||||
- **Add Integration Tests**: If your changes involve interactions between multiple modules, add corresponding integration tests.
|
||||
- **Keep Commits Atomic**: Do not modify code unrelated to your changes. A single submission should focus on an independent feature or fix, avoiding unrelated formatting adjustments or code refactoring.
|
||||
|
||||
### Submitting Your Changes
|
||||
|
||||
1. Check current status.
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# 为 openvela 做出贡献
|
||||
|
||||
\[ [English](CONTRIBUTING.md) | 简体中文 | [繁體中文](CONTRIBUTING_zh-tw.md) \]
|
||||
[ [English](CONTRIBUTING.md) | 简体中文 ]
|
||||
|
||||
openvela 由一支活跃的软件工程师和研究人员团队开发。欢迎你加入 openvela 开源社区,为改进此项目做出任何贡献!
|
||||
|
||||
|
|
@ -38,14 +38,15 @@ openvela 主要遵循 Apache License 2.0 许可证,具体请参看 LICENSE 文
|
|||
- **trunk**:**trunk** 分支不接受 pull request。
|
||||
- **dev**:从 **dev** 分支 fork 代码,并推送 pull request。
|
||||
|
||||
### 提交代码前准备
|
||||
### 提交代码前的准备工作
|
||||
|
||||
在新建 pull request 之前遵循这些提示将加快审核周期。
|
||||
在创建新的 Pull Request 之前,请遵循以下指南。这将有助于加快代码的审核与合入周期。
|
||||
|
||||
- 添加适当的单元测试。
|
||||
- 如果适用,添加集成测试。
|
||||
- 不属于您更改范围的行不应被编辑(例如,不要格式化未更改的行,不要重新排序现有的导入)。
|
||||
- 在任何新文件中添加适当的许可证标头。
|
||||
- **遵循代码风格规范**:确保您的代码提交符合 [openvela 代码风格检查指南](./zh-cn/contribute/code_style_check_guide.md)。在提交前运行本地检查,可以有效避免在持续集成 (CI) 流程中出现不必要的失败。
|
||||
- **添加许可证头部**:为所有新增的文件添加标准的许可证头部信息。
|
||||
- **补充单元测试**:为您的代码变更添加必要且充分的单元测试,以验证其正确性。
|
||||
- **补充集成测试**:如果您的变更涉及多个模块的交互,请添加相应的集成测试。
|
||||
- **保持提交的原子性**:请勿修改与本次变更无关的代码。一次提交应聚焦于一个独立的功能或修复,避免混合不相关的格式化调整或代码重排。
|
||||
|
||||
### 提交您的更改
|
||||
|
||||
|
|
|
|||
|
|
@ -1,138 +0,0 @@
|
|||
# 為 openvela 做出貢獻
|
||||
|
||||
\[ [English](CONTRIBUTING.md) | [简体中文](CONTRIBUTING_zh-cn.md) | 繁體中文 \]
|
||||
|
||||
openvela 由一支活躍的軟體工程師和研究人員團隊開發。歡迎您加入 openvela 開源社區,為改進此專案做出任何貢獻!
|
||||
openvela 主要遵循 Apache License 2.0 許可證,具體請參看 LICENSE 檔案。
|
||||
|
||||
## 簽署貢獻者許可協議 (CLA)
|
||||
|
||||
為了參與社區貢獻,首次提交程式碼時,需要簽署相應的**貢獻者許可協議(Contributor License Agreement, CLA)**。以下是針對不同平台的具體步驟:
|
||||
|
||||
- **Gitee 平台**:
|
||||
|
||||
- 請訪問 [Gitee CLA 簽署頁面](https://gitee.com/organizations/open-vela/cla/zs6b7c48u6juka2tsnrnkzx6k88np85e) 完成簽署。
|
||||
- 您可以透過 [我簽署的 CLA](https://gitee.com/profile/clas) 查看簽署狀態。
|
||||
|
||||
- **GitHub 平台**:
|
||||
|
||||
- 在提交新的 Pull Request (PR) 後,系統會提示您完成 CLA 的簽署。請根據提示操作以完成簽署流程。
|
||||
|
||||
## 錯誤報告
|
||||
|
||||
如果您認為在 openvela 中發現了錯誤,請首先確保您已使用了最新版本的 openvela 進行了測試(您的問題可能已得到修復)。
|
||||
如果未解決,請搜索問題列表,查看是否已有類似的問題。
|
||||
|
||||
## 功能請求
|
||||
|
||||
請提交一個 Issue,描述您希望添加的功能、您需要它的原因以及預期的工作方式。
|
||||
|
||||
## 提交程式碼
|
||||
|
||||
如果您想給 openvela 增加新功能或者修復一些錯誤,先確認是否已有類似的問題。如果沒有,請您新建一個問題,與大家討論您的想法。
|
||||
|
||||
### 分支策略
|
||||
|
||||
- **trunk**:**trunk** 分支不接受 pull request。
|
||||
- **dev**:從 **dev** 分支 fork 程式碼,並推送 pull request。
|
||||
|
||||
### 提交程式碼前準備
|
||||
|
||||
在新建 pull request 之前遵循這些提示將加快審核週期。
|
||||
|
||||
- 添加適當的單元測試。
|
||||
- 如果適用,添加整合測試。
|
||||
- 不屬於您更改範圍的行不應被編輯(例如,不要格式化未更改的行,不要重新排序現有的匯入)。
|
||||
- 在任何新檔案中添加適當的許可證標頭。
|
||||
|
||||
### 提交您的更改
|
||||
|
||||
#### 1 測試您的更改
|
||||
|
||||
請執行測試套件以確保沒有出現任何問題。
|
||||
|
||||
#### 2 簽署貢獻者許可協議
|
||||
|
||||
**首次提交需完成**:簽署貢獻者許可協議,請參考[簽署貢獻者許可協議 (CLA)](#簽署貢獻者許可協議-cla)章節。
|
||||
|
||||
#### 3 提交程式碼
|
||||
|
||||
1. 檢查當前狀態。
|
||||
|
||||
```Bash
|
||||
# 查看工作區狀態
|
||||
git status
|
||||
```
|
||||
|
||||
2. 暫存更改。
|
||||
|
||||
```Bash
|
||||
# 添加特定檔案到暫存區
|
||||
git add path/to/changed/file.cpp
|
||||
# 或添加所有更改
|
||||
git add .
|
||||
```
|
||||
|
||||
3. 提交更改。
|
||||
|
||||
```Bash
|
||||
# 創建提交
|
||||
git commit -m "簡明扼要的提交資訊"
|
||||
# 或使用詳細提交資訊
|
||||
git commit
|
||||
```
|
||||
|
||||
4. 配置上游倉庫。
|
||||
|
||||
```Bash
|
||||
# 顯示現有遠端倉庫地址
|
||||
git remote -v
|
||||
# 添加上游遠端倉庫引用(僅首次需要執行)
|
||||
git remote add upstream git@github.com:open-vela/[repository].git
|
||||
# 顯示現有遠端倉庫地址(應包含 origin 和 upstream)
|
||||
git remote -v
|
||||
```
|
||||
|
||||
5. 獲取最新程式碼並變基。
|
||||
|
||||
```Bash
|
||||
# 獲取上游倉庫的最新程式碼
|
||||
git fetch upstream
|
||||
# 將當前分支變基到最新主分支
|
||||
git rebase upstream/dev
|
||||
```
|
||||
|
||||
6. 解決衝突(如有)。
|
||||
|
||||
```Bash
|
||||
# 檢測衝突狀態(推薦)
|
||||
git status
|
||||
# 編輯衝突檔案(如 conflict.cpp),可使用任何編輯器,如 nano、vim、VSCode 等
|
||||
nano conflict.cpp
|
||||
# 標記為已解決
|
||||
git add conflict.cpp
|
||||
# 解決所有衝突後繼續變基操作
|
||||
git rebase --continue
|
||||
# 確認變基完成狀態
|
||||
git status
|
||||
```
|
||||
|
||||
7. 強制推送更新:
|
||||
|
||||
```Bash
|
||||
# 強制推送更新後的分支到您的遠端倉庫
|
||||
git push --force origin dev
|
||||
```
|
||||
|
||||
#### 4 創建合入請求
|
||||
|
||||
1. 訪問 GitHub 上您的 fork 倉庫。
|
||||
2. 點擊 **New pull request** 按鈕。
|
||||
3. 點擊 **Create pull request** 創建合入請求。
|
||||
4. 填寫合入請求資訊。
|
||||
|
||||
#### 5 合入請求後續工作
|
||||
|
||||
- **持續監控合入請求的審查意見**
|
||||
- 及時回應審查者的反饋
|
||||
- 如需修改,在同一分支上進行更改並推送
|
||||
|
|
@ -1,21 +0,0 @@
|
|||
# openvela 文件
|
||||
|
||||
歡迎來到 openvela 文件目錄,參與 openvela 開發者文件開源專案,與我們一起完善開發者文件。
|
||||
|
||||
此目錄存放 openvela 提供的開發者文件。
|
||||
|
||||
## 目錄結構
|
||||
|
||||
- [简体中文 文档](zh-cn/README.md)
|
||||
- English Documentation
|
||||
- 繁體中文 說明文件
|
||||
|
||||
## 分支說明
|
||||
|
||||
- dev:最新開發版本,從 dev 分支 fork 代碼,並推送到 pull request。
|
||||
|
||||
- trunk:穩定版本,不接受 pull request。
|
||||
|
||||
## 貢獻
|
||||
|
||||
歡迎您參與[貢獻](./CONTRIBUTING_zh-cn.md),我們鼓勵開發者以各種方式參與文件回饋和貢獻。
|
||||
173
README.md
|
|
@ -6,9 +6,9 @@
|
|||
|
||||
# openvela Open Source Project
|
||||
|
||||
\[ English | [简体中文](README_zh-cn.md) | [繁體中文](README_zh-tw.md) \]
|
||||
\[ English | [简体中文](README_zh-cn.md) ]
|
||||
|
||||
## Introduction to openvela
|
||||
## About openvela
|
||||
|
||||
openvela is an operating system specifically crafted for the AIoT industry, with a focus on being lightweight, standards-compliant, secure, and highly scalable. It has become the technology of choice for millions of IoT devices and AI gadgets, including smart watches, fitness bands, smart speakers, earbuds, smart appliances, and robotics.
|
||||
|
||||
|
|
@ -30,36 +30,111 @@ The name "Vela" is originated from the Latin term for "sail," which is also the
|
|||
|
||||
Maintenance and testing tools include common utilities and diagnostic frameworks. In addition to standard tools like Logger and Debugger, they feature the Emulator — a high-fidelity device simulator that supports full functional emulation, including CPU instruction-set simulation. The Emulator currently supports multiple product form factors, including smart panels, smartwatches, smart bands, and smart screen speakers. By leveraging the Emulator’s PC-based debugging tools, developers can perform application development and testing without physical devices, significantly reducing both development and debugging efforts.
|
||||
|
||||
## Technical advantages
|
||||
## Technical Advantages
|
||||
|
||||
- **Highly Scalable**: openvela has been designed to be modular and scalable, allowing it to easily adapt to a wide range of IoT applications. It can fit in a small BLE module with 32KB RAM, and scale up to a powerful smart display device with 512MB RAM, highly scalable!
|
||||
- **Highly Scalable**
|
||||
|
||||
- **One-Stop Solution**: Over the years, openvela has evolved into a powerful platform with comprehensive feature sets, making it a one-stop solution for various IoT applications. We consistently incorporate new functionalities to meet emerging needs. By leveraging openvela, manufacturers can significantly reduce their R&D costs and accelerate their product development cycles.
|
||||
openvela has been designed to be modular and scalable, allowing it to easily adapt to a wide range of IoT applications. It can fit in a small BLE module with 32KB RAM, and scale up to a powerful smart display device with 512MB RAM, highly scalable!
|
||||
|
||||
- **Mature Heterogeneous Computing Support**: openvela offers top-of-the-line support for heterogeneous multi-core systems, featuring a seamless IPC mechanism between various processing units such as MCU, MPU, DSP, GPU, and NPU. Additionally, openvela provides an advanced RPC framework between openvela, Linux, and Android systems to enable hybrid OS leveraging strength from three systems.
|
||||
- **One-Stop Solution**
|
||||
|
||||
- **Standard Compliant and High Portability**: openvela Kernel is built upon Apache NuttX, which is often referred to as "tiny Linux". With this foundation, openvela achieves a high degree of conformity with the POSIX standard. Our team has been continually enhancing its POSIX compatibility, which has now reached an impressive 88%. Because of this standards conformance, software developed under other standard OSs (such as Linux) can be easily ported to openvela with minimum effort.
|
||||
Over the years, openvela has evolved into a powerful platform with comprehensive feature sets, making it a one-stop solution for various IoT applications. We consistently incorporate new functionalities to meet emerging needs. By leveraging openvela, manufacturers can significantly reduce their R&D costs and accelerate their product development cycles.
|
||||
|
||||
- **Comprehensive Connectivity Suite**: openvela offers broad protocol support, including Bluetooth BR/EDR/LE, LE Mesh, WiFi, Matter, IEEE802.15.4, and LTE Cat1, Ethernet, CAN/LIN, etc. Additionally, it seamlessly integrates with Xiaomi HyperConnect protocols.
|
||||
- **Mature Heterogeneous Computing Support**
|
||||
|
||||
- **Rich Developer Tools**: openvela offers a comprehensive suite of developer tools, including system monitoring, performance analysis, debugger, trace, crash dumb, and log analysis tools.
|
||||
openvela offers top-of-the-line support for heterogeneous multi-core systems, featuring a seamless IPC mechanism between various processing units such as MCU, MPU, DSP, GPU, and NPU. Additionally, openvela provides an advanced RPC framework between openvela, Linux, and Android systems to enable hybrid OS leveraging strength from three systems.
|
||||
|
||||
## Supported platforms
|
||||
- **Standard Compliant and High Portability**
|
||||
|
||||
openvela Kernel is built upon Apache NuttX, which is often referred to as "tiny Linux". With this foundation, openvela achieves a high degree of conformity with the POSIX standard. Our team has been continually enhancing its POSIX compatibility, which has now reached an impressive 88%. Because of this standards conformance, software developed under other standard OSs (such as Linux) can be easily ported to openvela with minimum effort.
|
||||
|
||||
- **Comprehensive Connectivity Suite**
|
||||
|
||||
openvela offers broad protocol support, including Bluetooth BR/EDR/LE, LE Mesh, WiFi, Matter, IEEE802.15.4, and LTE Cat1, Ethernet, CAN/LIN, etc. Additionally, it seamlessly integrates with Xiaomi HyperConnect protocols.
|
||||
|
||||
- **Rich Developer Tools**
|
||||
|
||||
openvela offers a comprehensive suite of developer tools, including system monitoring, performance analysis, debugger, trace, crash dumb, and log analysis tools.
|
||||
|
||||
## Hardware Support
|
||||
|
||||
- openvela supports a variety of architectures (ARM32, ARM64, RISC-V, Xtensa, MIPS, CEVA, etc.) and platforms.
|
||||
- Please refer to the [Supported Architectures and Platforms](https://nuttx.apache.org/docs/latest/platforms/index.html) page for a complete list.
|
||||
- For adaptation cases regarding development boards, please refer to the [Case Documentation](./en/dev_board/STM32H750.md).
|
||||
- For adaptation cases regarding development boards, please refer to the [Case Documentation](./en/dev_board/Development_Board.md).
|
||||
|
||||
## What's New
|
||||
|
||||
- **Significant Hardware Ecosystem Expansion**: Added support for **Infineon AURIX™ TC4**, **Flagchip MCU**, and the **QEMU-R52 SIL** platform. (View [TC4 Guide](./en/quickstart/development_board/tc4d9_evb_guide.md) / [Flagchip Guide](./en/quickstart/development_board/fc7300f8m_evb_guide.md))
|
||||
|
||||
- **Enhanced Ubuntu Development Experience**: The OpenVela VS Code plugin now **fully supports the Ubuntu environment**. Linux developers can enjoy a seamless, end-to-end workflow—from project creation and build to system debugging—significantly boosting development efficiency. Get started: [VS Code Plugin Guide](./en/quickstart/vscode_plugin_usage.md).
|
||||
|
||||
## Version Strategy
|
||||
|
||||
We manage releases based on the `trunk` branch, using Tags to track release history. This ensures traceability and stability for production environments.
|
||||
|
||||
### Release Tags
|
||||
|
||||
Release tags are immutable markers created on the `trunk` branch. Each tag represents an officially released version of openvela.
|
||||
|
||||
- **Production Environment Recommendation**: To ensure maximum system stability and security, we **strongly recommend** using the latest release tags in production environments (Production Environment), rather than using branch code directly.
|
||||
|
||||
### Released Versions
|
||||
|
||||
Below are the currently released stable versions and their change logs:
|
||||
|
||||
- **trunk-5.5**: Please refer to the [v5.5 Release Notes](./en/release_notes/v5.5.md) for detailed changes.
|
||||
|
||||
- **trunk-5.4**: Please refer to the [v5.4 Release Notes](./en/release_notes/v5.4.md) for detailed changes.
|
||||
|
||||
- **trunk-5.2**: Please refer to the [v5.2 Release Notes](./en/release_notes/v5.2.md) for detailed changes.
|
||||
|
||||
### Hardware Adaptation Guide
|
||||
|
||||
To maximize efficiency and ensure code stability, we offer the following recommendations for developers performing hardware porting:
|
||||
|
||||
- **Recommended Baseline**: We strongly recommend **basing your development on the latest openvela release version** (i.e., Release Tags on the `trunk` branch).
|
||||
- **Risk Warning**: The current **`dev` branch** is undergoing rapid iteration with frequent code updates. It may be subject to underlying interface changes or temporary instability. Therefore, it is **NOT recommended** as a baseline for hardware adaptation.
|
||||
- **Get Support**: If you have adaptation requirements or encounter technical difficulties, please feel free to **submit an Issue** or contact us via the **WeChat Community**. The openvela team is ready to provide the necessary development support.
|
||||
|
||||
### Version Maintenance Strategy
|
||||
|
||||
openvela follows a strict version maintenance lifecycle:
|
||||
|
||||
- **Patch Updates**: For critical bugs or security vulnerabilities discovered in released versions, the team issues new patch release tags (Patch Release) to provide fixes.
|
||||
- **Naming Convention**: Patch versions increment based on the original version number, such as `trunk-5.5.1`.
|
||||
|
||||
## Branch Strategy
|
||||
|
||||
openvela adopts a dual-branch model to balance system innovation and stability. Please select the appropriate branch according to your development needs.
|
||||
|
||||
### dev (Development Branch)
|
||||
|
||||
- **Definition**: This is the cutting-edge development branch of openvela, aggregating the latest features and bug fixes.
|
||||
- **Status**: The code updates frequently and remains in a state of continuous integration and rapid iteration. It may contain features not yet fully verified, so potential instability exists.
|
||||
- **Target Audience**:
|
||||
|
||||
- Developers who wish to experience new features early.
|
||||
- Contributors planning to submit code or participate in core function development.
|
||||
|
||||
### trunk (Stable Trunk Branch)
|
||||
|
||||
- **Definition**: This is the fully tested main branch, representing the current stable state of the system.
|
||||
- **Status**: Features from the `dev` branch are merged here only after they pass rigorous testing and verification.
|
||||
- **Target Audience**: Most users who require high system stability, and engineers developing standard applications.
|
||||
|
||||
## Quick start
|
||||
|
||||
If you want to experience openvela, we provide a fully functional emulator that can be used without a hardware platform.For more information, refer to the following guide.
|
||||
### Device Development
|
||||
|
||||
1. [Set up the development environment](./en/quickstart/Set_up_the_development_environment.md)
|
||||
2. [Download openvela source code](./en/quickstart/Download_Vela_sources.md)
|
||||
3. [Compile openvela source code](./en/quickstart/Build_Vela_from_sources.md)
|
||||
4. [Run build artifacts on Emulator](./en/quickstart/Run_Vela_on_Vela_Emulator.md)
|
||||
If you want to experience openvela, we provide a fully functional emulator that can be used without a hardware platform. For more information, refer to the following guide.
|
||||
|
||||
## Sub-repository List
|
||||
[Quick Start (Ubuntu)](./en/quickstart/openvela_ubuntu_quick_start.md)
|
||||
|
||||
### Quick App Development
|
||||
|
||||
[Quick App Quick Start](https://iot.mi.com/vela/quickapp/zh/guide/start/use-ide.html)
|
||||
|
||||
## List of Sub-repositories
|
||||
|
||||
| Sub-repository Link | Description |
|
||||
| :--------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
|
|
@ -75,28 +150,68 @@ If you want to experience openvela, we provide a fully functional emulator that
|
|||
|
||||
- [Documentation Center](https://doc.openvela.com/document)
|
||||
|
||||
## Examples Tutorials
|
||||
## Application Example Center
|
||||
|
||||
- [Music player](./en/demo/Music_Player_Example.md)
|
||||
- [Smart band](./en/demo/Smart_Band_Example.md)
|
||||
- [Bike computer](./en/demo/X_Track.md)
|
||||
A collection of native and Quick App examples for developers to learn from.
|
||||
|
||||
### Native Apps
|
||||
|
||||
Here are some typical native application examples demonstrating the usage of different modules and features.
|
||||
|
||||
- [Music Player](./en/demo/Music_Player_Example.md): Demonstrates audio playback, playlist management, and background services.
|
||||
- [Smart Band](./en/demo/Smart_Band_Example.md): Demonstrates sleep monitoring, heart rate monitoring, music playback, and a stopwatch.
|
||||
- [Cycling Computer](./en/demo/X_Track.md): Demonstrates GPS positioning, real-time data display, and route tracking.
|
||||
- [Calculator](../../../../open-vela/packages_demos/blob/trunk-5.5/calculator/Readme.md): A basic example of UI and logic interaction.
|
||||
- [Relation Calculator](../../../../open-vela/packages_demos/blob/trunk-5.5/relation_calculator/Readme.md): Demonstrates complex conditional logic and algorithm implementation.
|
||||
- [Whack-a-Mole](../../../../open-vela/packages_demos/blob/trunk-5.5/Whackmole/README.md): Demonstrates a game loop, random number generation, and animation effects.
|
||||
|
||||
To see the full list of native apps, please visit the [Native App Examples Repository](../../../packages_demos/blob/trunk-5.5/README.md).
|
||||
|
||||
### Quick Apps
|
||||
|
||||
- [Mi Band Weather App](../../.././packages_fe_examples/blob/trunk-5.5/weather/README.md): Presents a clean and intuitive seven-day weather forecast.
|
||||
- [Music Player](../../.././packages_fe_examples/blob/trunk-5.5/player/README.md): Demonstrates a basic music player, including playback, volume control, and playlist viewing.
|
||||
- [Calendar](../../.././packages_fe_examples/blob/trunk-5.5/calendar/README.md): Demonstrates a basic calendar.
|
||||
|
||||
More Quick App examples are continuously being added. To see all examples, please visit the [Quick App Examples Repository](../../../packages_fe_examples).
|
||||
|
||||
## Code contribution
|
||||
|
||||
Contribute: [Code contribution guide](./CONTRIBUTING.md).
|
||||
- [Code Contribution Guide](./CONTRIBUTING.md)
|
||||
- [Documentation Contribution Guide](./en/contribute/process/doc_dev_process.md)
|
||||
|
||||
## License agreement
|
||||
## Licensing
|
||||
|
||||
The code in this repository is licensed under the Apache 2.0 license. You can find more information about Apache 2.0 license [here](https://www.apache.org/licenses/LICENSE-2.0.txt).
|
||||
The openvela project consists of multiple independent repositories. Its licensing policy is as follows:
|
||||
|
||||
openvela uses third-party open source software and license description. Refer to [third-party open source software description](Third_Party_and_Open_Source_Components.md)
|
||||
1. Basic Principles
|
||||
|
||||
## Contact
|
||||
The openvela project generally adopts the **Apache 2.0** license. However, the specific license for each code repository is determined by the `LICENSE` file located in its respective root directory.
|
||||
|
||||
In order to better manage and respond to feedback and support requests, we recommend contacting us by:
|
||||
2. Vendor Repositories
|
||||
|
||||
- **Issues**: If you have any questions, suggestions, or find any bugs, submit a new issue on the Issues page.Try to provide detailed information, so that we can understand and solve the problem faster.
|
||||
Repositories under the `vendor` directory are provided by third parties (such as chip manufacturers). These repositories follow their own independent licenses (e.g., MIT, BSD, etc.) and are **not** governed by the openvela project's Apache 2.0 license. Please ensure you review and comply with their respective terms before use.
|
||||
|
||||
3. Third-Party Dependencies
|
||||
|
||||
For information regarding third-party open source components referenced in the project code and their licenses, please refer to the [Third-Party Open Source Software Notice](./Third_Party_and_Open_Source_Components.md) file.
|
||||
|
||||
## Community and Support
|
||||
|
||||
We welcome you to interact with and contribute to the openvela community through our various channels.
|
||||
|
||||
## Technical Discussions and Contributions
|
||||
|
||||
- **Issues**: If you have any questions, suggestions, or find any bugs, submit a new issue on the Issues page. Try to provide detailed information, so that we can understand and solve the problem faster.
|
||||
- **Pull Requests**: If you find an issue and have fixed it, you are welcome to submit a Pull Request. Please make sure to follow our [Contribution Guide](./CONTRIBUTING.md).
|
||||
- **Discussions**: If you have a broader topic or discussion, you can start a new discussion on the Discussions page.
|
||||
|
||||
We appreciate every user's feedback and support. Communicating through the GitHub/Gitee platform is helpful for us to maintain and improve the project.
|
||||
### WeChat Community
|
||||
|
||||
Welcome to the **OpenVela** community! Scan the QR codes below to follow our Official Account or add our assistant to join the group chat.
|
||||
|
||||
| Official Account | Developer Group |
|
||||
| :---------------------------------------------------------------------: | :-------------------------------------------------: |
|
||||
| <img src="./images/openvela_WeChat_Official_Account.png" width="200" /> | <img src="./images/assistant_qr.jpg" width="200" /> |
|
||||
| **Follow Us**<br>Get the latest updates and technical articles | **Join the Group**<br>Scan to add assistant |
|
||||
|
||||
|
|
|
|||
136
README_zh-cn.md
|
|
@ -4,10 +4,10 @@
|
|||
|
||||
<h1 align="center">openvela</h1>
|
||||
|
||||
\[ [English](README.md) | 简体中文 | [繁體中文](README_zh-tw.md) \]
|
||||
|
||||
# openvela 开源项目
|
||||
|
||||
[ [English](README.md) | 简体中文]
|
||||
|
||||
## openvela 简介
|
||||
|
||||
openvela 操作系统专为 AIoT 领域量身定制,以轻量化、标准兼容、安全性和高度可扩展性为核心特点。openvela 以其卓越的技术优势,已成为众多物联网设备和 AI 硬件的技术首选,涵盖了智能手表、运动手环、智能音箱、耳机、智能家居设备以及机器人等多个领域。
|
||||
|
|
@ -34,33 +34,102 @@ Vela 的命名源自拉丁语中船帆的含义,也是南方星空中船帆星
|
|||
|
||||
## 技术优势
|
||||
|
||||
- **高度可扩展**:openvela 的设计注重模块化与可扩展性,使其能够灵活适应多样的物联网应用场景。小到仅配备 32KB RAM 的微型 BLE 模组,大到拥有 512MB RAM 的智能有屏音箱,openvela 都能提供高度可扩展的支持。
|
||||
- **高度可扩展**
|
||||
|
||||
- **一站式解决方案**:随着时间的推移,openvela 不断沉淀了各类 AIoT 应用的共性需求,成为一个功能完备的软件平台,为各类物联网解决方案提供了全面的支持。厂商采用 openvela,可以显著降低研发成本并加速产品的上市时间。
|
||||
openvela 的设计注重模块化与可扩展性,使其能够灵活适应多样的物联网应用场景。小到仅配备 32KB RAM 的微型 BLE 模组,大到拥有 512MB RAM 的智能有屏音箱,openvela 都能提供高度可扩展的支持。
|
||||
|
||||
- **成熟的异构计算支持**:openvela 为异构多核系统提供了强大的支持,实现了 MCU、MPU、DSP、GPU 以及 NPU 等不同处理单元间无缝的 IPC 通信机制。此外,openvela 还提供了一个高级的 RPC 框架,简化了 openvela 与 Android 和 Linux 系统的通信,使快速打造一个异构融合操作系统成为可能。
|
||||
- **一站式解决方案**
|
||||
|
||||
- **标准兼容和高可移植性**:openvela 内核基于 Apache NuttX ,这个被称为 “Tiny Linux” 的系统为 openvela 提供了高标准的 POSIX 兼容性。通过持续提升其 POSIX 兼容性,openvela 当前已达到 88% 的兼容水平。这种高标准的兼容性意味着在其他标准操作系统(例如 Linux)上开发的软件可以轻松迁移到 openvela,几乎不需要额外的工作。
|
||||
随着时间的推移,openvela 不断沉淀了各类 AIoT 应用的共性需求,成为一个功能完备的软件平台,为各类物联网解决方案提供了全面的支持。厂商采用 openvela,可以显著降低研发成本并加速产品的上市时间。
|
||||
|
||||
- **全面的连接套件**:openvela 提供了广泛的协议支持,包括蓝牙 BR/EDR/LE、LE Mesh、WiFi、Matter、LTE Cat1、以太网、CAN/LIN 等。同时,它还能与小米的 HyperConnect 协议无缝集成,提供了强大的连接能力。
|
||||
- **成熟的异构计算支持**
|
||||
|
||||
- **丰富的开发者工具**:openvela 提供了一系列完备的开发者工具,包括系统监控、性能分析、调试器、追踪、崩溃分析和日志分析工具,为开发者提供了强大的支持。
|
||||
openvela 为异构多核系统提供了强大的支持,实现了 MCU、MPU、DSP、GPU 以及 NPU 等不同处理单元间无缝的 IPC 通信机制。此外,openvela 还提供了一个高级的 RPC 框架,简化了 openvela 与 Android 和 Linux 系统的通信,使快速打造一个异构融合操作系统成为可能。
|
||||
|
||||
- **标准兼容和高可移植性**
|
||||
|
||||
openvela 内核基于 Apache NuttX ,这个被称为 “Tiny Linux” 的系统为 openvela 提供了高标准的 POSIX 兼容性。通过持续提升其 POSIX 兼容性,openvela 当前已达到 88% 的兼容水平。这种高标准的兼容性意味着在其他标准操作系统(例如 Linux)上开发的软件可以轻松迁移到 openvela,几乎不需要额外的工作。
|
||||
|
||||
- **全面的连接套件**
|
||||
|
||||
openvela 提供了广泛的协议支持,包括蓝牙 BR/EDR/LE、LE Mesh、WiFi、Matter、LTE Cat1、以太网、CAN/LIN 等。同时,它还能与小米的 HyperConnect 协议无缝集成,提供了强大的连接能力。
|
||||
|
||||
- **丰富的开发者工具**
|
||||
|
||||
openvela 提供了一系列完备的开发者工具,包括系统监控、性能分析、调试器、追踪、崩溃分析和日志分析工具,为开发者提供了强大的支持。
|
||||
|
||||
## 硬件支持
|
||||
|
||||
- openvela 支持各种不同的架构(ARM32、ARM64、RISC-V、Xtensa、MIPS、CEVA 等)和硬件平台。请在[硬件支持](https://nuttx.apache.org/docs/latest/platforms/index.html)页面上查看完整列表。
|
||||
- 关于**开发板**的适配案例,请参见[案例文档](./zh-cn/dev_board/Development_Board.md)。
|
||||
|
||||
## 最新动态
|
||||
|
||||
- 硬件生态大幅扩展:新增对 **英飞凌 AURIX™ TC4**、**旗芯微 (Flagchip) MCU** 以及 **QEMU-R52 SIL** 平台的适配支持。(查看 [TC4 指南](./zh-cn/quickstart/development_board/tc4d9_evb_guide.md) / [旗芯微指南](./zh-cn/quickstart/development_board/fc7300f8m_evb_guide.md))
|
||||
|
||||
- Ubuntu 开发体验升级:openvela VS Code 插件现已**完美支持 Ubuntu 环境**。Linux 开发者现在也可以享受从项目创建、编译构建到系统调试的一站式流畅体验,开发效率显著提升。即刻体验:[VS Code 插件使用指南](./zh-cn/quickstart/vscode_plugin_usage.md)。
|
||||
|
||||
## 版本发布管理 (Version Strategy)
|
||||
|
||||
我们基于 `trunk` 分支进行版本发布,通过标签(Tags)管理发布历史,确保生产环境的可追溯性与稳定性。
|
||||
|
||||
### 发布标签 (Release Tags)
|
||||
|
||||
发布标签是基于 `trunk` 分支创建的不可变标记(Immutable Marker)。每个标签代表一个正式发布的 openvela 版本。
|
||||
|
||||
- **生产环境建议**:为了确保系统的最高稳定性和安全性,我们**强烈建议**在生产环境(Production Environment)中使用最新的发布标签,而非直接使用分支代码。
|
||||
|
||||
### 已发布版本列表
|
||||
|
||||
以下是当前已发布的稳定版本及其变更说明:
|
||||
|
||||
- **trunk-5.5**:请查阅 [v5.5 版本发布说明](./zh-cn/release_notes/v5.5.md) 了解详细变更。
|
||||
|
||||
- **trunk-5.4**:请查阅 [v5.4 版本发布说明](./zh-cn/release_notes/v5.4.md) 了解详细变更。
|
||||
|
||||
- **trunk-5.2**:请查阅 [v5.2 版本发布说明](./zh-cn/release_notes/v5.2.md) 了解详细变更。
|
||||
|
||||
### 硬件适配特别说明 (Hardware Adaptation Guide)
|
||||
|
||||
为提升适配效率并确保代码稳定性,针对进行硬件移植(Porting)的开发者,我们提供以下建议:
|
||||
|
||||
- **推荐基准**:建议**优先基于 openvela 最新发布版本**(即 `trunk` 上的 Release Tag)进行硬件适配开发。
|
||||
- **风险提示**:当前 **`dev` 分支** 处于快速迭代期,代码更新较为频繁,可能存在底层接口变动或临时性问题,**不推荐**作为硬件适配的基准代码。
|
||||
- **获取支持**:如有适配需求或在过程中遇到技术疑问,欢迎**提交 Issue** 或者通过**微信社区**与我们取得联系,openvela 团队将提供必要的开发支持。
|
||||
|
||||
### 版本维护策略
|
||||
|
||||
openvela 遵循严格的版本维护生命周期:
|
||||
|
||||
- **补丁更新**:针对已发布版本中发现的关键缺陷(Critical Bugs)或安全漏洞,团队将发布新的补丁版本标签(Patch Release)进行修复。
|
||||
- **命名规则**:补丁版本将在原版本号基础上递增,例如 `trunk-5.5.1`。
|
||||
|
||||
## 代码分支管理 (Branch Strategy)
|
||||
|
||||
openvela 采用双分支模型来平衡系统的创新性与稳定性。请根据您的开发需求选择合适的分支。
|
||||
|
||||
### dev (开发分支)
|
||||
|
||||
- **定义**:这是 openvela 的前沿开发分支,汇集了最新的功能特性与缺陷修复。
|
||||
- **状态**:代码更新频率高,处于持续集成与快速迭代状态,可能包含尚未完全验证的特性,因此可能存在不稳定性。
|
||||
- **适用人群**:
|
||||
|
||||
- 希望抢先体验新功能的开发者。
|
||||
- 计划向社区提交代码、参与核心功能建设的贡献者。
|
||||
|
||||
### trunk (主干稳定分支)
|
||||
|
||||
- **定义**:这是经过全面测试的主干分支,代表了当前系统的稳定状态。
|
||||
- **状态**:`dev` 分支中的功能在经过严格测试验证稳定后,会被合并至此分支。
|
||||
- **适用人群**:大多数对系统稳定性有较高要求的用户,以及进行标准应用开发的工程师。
|
||||
|
||||
## 快速入门
|
||||
|
||||
### 设备开发
|
||||
|
||||
如果您想要体验 openvela,我们提供一个功能完备的模拟器,无需硬件平台即可使用。有关详细信息,请参阅如下指南。
|
||||
|
||||
1. [准备开发环境](./zh-cn/quickstart/Set_up_the_development_environment_zh-cn.md)
|
||||
2. [下载 openvela 源码](./zh-cn/quickstart/Download_Vela_sources_zh-cn.md)
|
||||
3. [编译 openvela 源码](./zh-cn/quickstart/Build_Vela_from_sources_zh-cn.md)
|
||||
4. [在模拟器上运行编译产物](./zh-cn/quickstart/Run_Vela_on_Vela_Emulator_zh-cn.md)
|
||||
[快速入门(Ubuntu)](./zh-cn/quickstart/openvela_ubuntu_quick_start.md)
|
||||
|
||||
### 快应用开发
|
||||
|
||||
|
|
@ -93,17 +162,17 @@ Vela 的命名源自拉丁语中船帆的含义,也是南方星空中船帆星
|
|||
- [音乐播放器](./zh-cn/demo/Music_Player_Example_zh-cn.md):演示音频播放、列表管理和后台服务。
|
||||
- [智能手环](./zh-cn/demo/Smart_Band_Example_zh-cn.md):演示睡眠监测、心率监测、音乐播放、秒表计时。
|
||||
- [自行车码表](./zh-cn/demo/X_Track_zh-cn.md):演示 GPS 定位、实时数据显示和运动轨迹记录。
|
||||
- [计算器](../../../../open-vela/packages_demos/blob/dev/calculator/Readme.md):一个基础的 UI 与逻辑交互示例。
|
||||
- [亲戚计算器](../../../../open-vela/packages_demos/blob/dev/relation_calculator/Readme_zh-cn.md):演示复杂的条件逻辑与算法实现。
|
||||
- [打地鼠](../../../../open-vela/packages_demos/blob/dev/Whackmole/Readme.md):演示游戏循环、随机数生成和动画效果。
|
||||
- [计算器](../../../../open-vela/packages_demos/blob/trunk-5.5/calculator/Readme.md):一个基础的 UI 与逻辑交互示例。
|
||||
- [亲戚计算器](../../../../open-vela/packages_demos/blob/trunk-5.5/relation_calculator/Readme_zh-cn.md):演示复杂的条件逻辑与算法实现。
|
||||
- [打地鼠](../../../../open-vela/packages_demos/blob/trunk-5.5/Whackmole/README_zh-cn.md):演示游戏循环、随机数生成和动画效果。
|
||||
|
||||
查看完整的原生应用列表,请访问[原生应用示例仓库](../../../packages_demos/blob/dev/README_zh-cn.md)。
|
||||
查看完整的原生应用列表,请访问[原生应用示例仓库](../../../packages_demos/blob/trunk-5.5/README_zh-cn.md)。
|
||||
|
||||
### 快应用(Quick Apps)
|
||||
|
||||
- [小米手环天气预报应用](../../.././packages_fe_examples/blob/dev/weather/README.md):演示音频播放、列表管理和后台服务。
|
||||
- [音乐播放器](../../.././packages_fe_examples/blob/dev/player/README.md):演示一个基础的音乐播放器,包含音乐的播放,音量调节,歌单查看。
|
||||
- [日历](../../.././packages_fe_examples/blob/dev/calendar/README.md):演示一个基础的日历。
|
||||
- [小米手环天气预报应用](../../.././packages_fe_examples/blob/trunk-5.5/weather/README.md):提供简洁直观的未来七日天气信息展示。
|
||||
- [音乐播放器](../../.././packages_fe_examples/blob/trunk-5.5/player/README.md):演示一个基础的音乐播放器,包含音乐的播放,音量调节,歌单查看。
|
||||
- [日历](../../.././packages_fe_examples/blob/trunk-5.5/calendar/README.md):演示一个基础的日历。
|
||||
|
||||
快应用相关示例正在持续丰富中。查看所有示例,请访问[快应用示例仓库](../../../packages_fe_examples)。
|
||||
|
||||
|
|
@ -114,14 +183,35 @@ Vela 的命名源自拉丁语中船帆的含义,也是南方星空中船帆星
|
|||
|
||||
## 许可协议
|
||||
|
||||
这个代码库中的代码使用 Apache 2.0 许可证。你可以在[这里](https://www.apache.org/licenses/LICENSE-2.0.txt)找到更多关于 Apache 2.0 许可证的信息。
|
||||
openvela 项目由多个独立的仓库组成,其许可证策略如下:
|
||||
|
||||
openvela 引用三方开源软件及许可证说明,参考[第三方开源软件说明](Third_Party_and_Open_Source_Components_zh-cn.md)。
|
||||
1. 基本原则
|
||||
|
||||
## 联系方式
|
||||
openvela 项目整体采用 Apache 2.0 作为主许可证,各代码库的许可证以各仓库根目录下 LICENSE 文件为准。
|
||||
|
||||
为了更好地管理和响应反馈和支持请求,建议通过以下方式联系我们:
|
||||
2. Vendor 仓库
|
||||
|
||||
`vendor` 目录下的仓库由芯片厂商等第三方提供,它们遵循各自独立的许可证(如 MIT, BSD 等),不受 openvela 项目的 Apache 2.0 许可证约束。使用前请务必查阅并遵守其规定。
|
||||
|
||||
3. 第三方依赖组件
|
||||
|
||||
项目代码中引用的第三方开源组件及其许可证信息,请参阅[第三方开源组件声明](Third_Party_and_Open_Source_Components_zh-cn.md)文件。
|
||||
|
||||
## 社区与支持
|
||||
|
||||
我们欢迎您通过多种渠道与 openvela 社区互动和贡献。
|
||||
|
||||
### 技术讨论与贡献
|
||||
|
||||
- **Issues**: 如果你有任何问题、建议或发现任何 Bug,请在 Issues 页面提交一个新的 Issue。请尽量提供详细的信息,以便我们更快地理解和解决问题。
|
||||
- **Pull Requests**: 如果你发现了问题并已经修复,欢迎提交 Pull Request。请确保遵循我们的[贡献指南](./CONTRIBUTING_zh-cn.md)。
|
||||
- **Discussions**: 如果你有更广泛的话题或讨论,可以在 Discussions 页面发起一个新的讨论。
|
||||
|
||||
### 微信社区
|
||||
|
||||
欢迎加入 **openvela** 社区!扫描下方二维码关注公众号,或添加小助手入群。
|
||||
|
||||
| 官方公众号 | 技术交流群 |
|
||||
| :---------------------------------------------------------------------: | :-------------------------------------------------: |
|
||||
| <img src="./images/openvela_WeChat_Official_Account.png" width="200" /> | <img src="./images/assistant_qr.jpg" width="200" /> |
|
||||
| **关注我们**<br>获取一手资讯与深度技术文章 | **加入群聊**<br>扫码添加好友 |
|
||||
|
|
|
|||
|
|
@ -1,88 +0,0 @@
|
|||
<div align="center">
|
||||
<img src="./images/openvela.svg" width="180" />
|
||||
</div>
|
||||
|
||||
<h1 align="center">openvela</h1>
|
||||
|
||||
# openvela 開源項目
|
||||
|
||||
\[ [English](README.md) | [简体中文](README_zh-cn.md) | 繁體中文 \]
|
||||
|
||||
## openvela 簡介
|
||||
|
||||
openvela 作業系統專為 AIoT 領域量身打造,專注在輕量化、符合標準、安全性及高度可擴充性。openvela 已成為數百萬物聯網裝置和人工智慧裝置的首選技術,包括智慧手錶、健身手環、智慧音箱、耳機、智慧家電和機器人等多個領域。
|
||||
|
||||
Vela 這個名字源自於拉丁語【帆】,也是南方天空中形似船帆的星座名稱。我們渴望與開發者合作,在 AIoT 領域揚帆起航。
|
||||
|
||||
## openvela 特色
|
||||
|
||||
- **高度可擴展性**:openvela 的設計著重於模組化與可擴充性,讓其能夠靈活適應多樣的物聯網應用場景。最低只需要 32KB RAM 的微型 BLE 模组,最大更可以來到 512MB RAM 帶有螢幕的智慧音箱,openvela 讓設備擁有高度的擴展性。
|
||||
|
||||
- **一站式解决方案**:多年來,openvela 已發展成為一個強大的平台,具有完整的軟體平台,使其成為各種物聯網應用的一站式解決方案。我們不斷融入新功能以滿足新興需求。透過利用 openvela,製造商可以大幅降低研發成本並加快產品開發週期。
|
||||
|
||||
- **成熟的異構計算支援**:openvela 為不同的架構及核心系統提供強大的支援,具有 MCU、MPU、DSP、GPU 和 NPU 等各種處理單元之間的無縫 IPC 機制。此外,openvela 在 openvela、Linux 和 Android 系統之間提供了先進的 RPC 框架,從而實現利用三種系統優勢的混合作業系統。
|
||||
|
||||
- **符合標準且可移植性高**:openvela 核心建立在 Apache NuttX 之上,通常被稱為「微型 Linux」。在此基礎上,openvela 實現了與 POSIX 標準的高度一致。我們的團隊一直在不斷增強其 POSIX 相容性,目前已達到令人印象深刻的 88%。由於符合此標準,在其他標準作業系統(例如 Linux)下開發的軟體可以輕鬆移植到 openvela。
|
||||
|
||||
- **完整的連接套件**:openvela 提供廣泛的協定支持,包括藍牙 BR/EDR/LE、LE Mesh、WiFi、Matter、IEEE802.15.4、LTE Cat1、乙太網路、CAN/LIN 等。
|
||||
|
||||
- **豐富的開發者工具**:openvela 提供了一系列完整的開發者工具,包括系統監控、效能分析、偵錯工具、trace、閃退分析和 log 分析工具,為開發者提供強大的資源。
|
||||
|
||||
## 硬體支援
|
||||
|
||||
- openvela 支援許多不同的架構(ARM32、ARM64、RISC-V、Xtensa、MIPS、CEVA 等)和硬體平台。
|
||||
- 請在[硬體支援](https://nuttx.apache.org/docs/latest/platforms/index.html)頁面中查詢完整的列表。
|
||||
- 关于開發板的適配案例,請參見[案例文檔](./zh-cn/dev_board/Development_Board.md)。
|
||||
|
||||
## 快速入門
|
||||
|
||||
如果您想要體驗 openvela,我們提供一個功能完整的模擬器,不需要硬體即可使用。詳細資訊請參考下方指南。
|
||||
|
||||
1. [準備開發環境](./zh-cn/quickstart/Set_up_the_development_environment_zh-cn.md)
|
||||
2. [下载 openvela 原始碼](./zh-cn/quickstart/Download_Vela_sources_zh-cn.md)
|
||||
3. [編譯 openvela 原始碼](./zh-cn/quickstart/Build_Vela_from_sources_zh-cn.md)
|
||||
4. [在模擬器上執行並編譯程式](./zh-cn/quickstart/Run_Vela_on_Vela_Emulator_zh-cn.md)
|
||||
|
||||
## 子倉庫清單
|
||||
|
||||
| 子倉庫連結 | 描述 |
|
||||
| :--------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| [frameworks](../../../../open-vela/frameworks) | openvela 服務框架:主要包含藍芽、電話、圖形、多媒體、應用框架、安全、系統服務框架(KVDB、OTA、healthd、binder、charger 等)。 |
|
||||
| [vendor](../../../../open-vela/vendor) | 晶片原廠的驅動和框架。 |
|
||||
| [nuttx](../../../../open-vela/nuttx) | 基於開源的 RTOS NuttX 打造的內核,提供基礎的核心功能,包括任務調度、跨進程通訊、檔案系統、TCP/IP 協定堆疊、裝置驅動和電源管理等,同時對上提供標準的 POSIX 接口。如果您想要對 NuttX 操作系統有更深的了解,可以在 [Apache NuttX](https://nuttx.apache.org/) 官網查看更多資訊。 |
|
||||
| [apps](../../../../open-vela/apps) | `apps` 是開源即時作業系統(NuttX)的應用程式庫,包含了一系列為 NuttX RTOS 設計的應用程式和實用工具。這些應用程式和工具包括 shell 命令列工具、檔案系統工具、網路工具等,它們可以幫助開發者更方便地開發和偵錯基於 NuttX RTOS 的嵌入式系統。 |
|
||||
| [external](../../../../open-vela/external) | openvela 引入的第三方程式庫。 |
|
||||
| [tests](../../../../open-vela/tests) | 該倉庫包含接口測試,具體包括多媒體、文件系統、記憶體管理和 socket 通訊等核心 API 的測試。 |
|
||||
| [docs](../../../../open-vela/docs) | openvela 對應的開發者文件。 |
|
||||
|
||||
## 開發者文檔
|
||||
|
||||
- [文檔中心](https://doc.openvela.com/document)
|
||||
|
||||
## 範例
|
||||
|
||||
- [音樂播放器](./zh-cn/demo/Music_Player_Example_zh-cn.md)
|
||||
- [智慧手環](./zh-cn/demo/Smart_Band_Example_zh-cn.md)
|
||||
- [自行車碼錶](./zh-cn/demo/X_Track_zh-cn.md)
|
||||
- [計算器](../../../../open-vela/packages_demos/blob/dev/calculator/Readme.md)
|
||||
- [親戚計算器](../../../../open-vela/packages_demos/blob/dev/relation_calculator/Readme_zh-cn.md)
|
||||
- [打地鼠](../../../../open-vela/packages_demos/blob/dev/Whackmole/Readme.md)
|
||||
|
||||
## 貢獻
|
||||
|
||||
- [原始碼貢獻指南](CONTRIBUTING_zh-tw.md)
|
||||
- [文件貢獻指南](./zh-cn/contribute/process/doc_dev_process.md)
|
||||
|
||||
## 授權
|
||||
|
||||
這個代碼庫中的代碼使用 Apache 2.0 授權。你可以在[這裡](https://www.apache.org/licenses/LICENSE-2.0.txt)找到更多關於 Apache 2.0 授權的資訊。
|
||||
|
||||
openvela 引用第三方開源軟體及授權說明,參考[第三方開源軟體說明](Third_Party_and_Open_Source_Components_zh-tw.md)。
|
||||
|
||||
## 聯絡方式
|
||||
|
||||
為了更好的管理和處裡回饋及技術支援,建議通過以下方式聯絡我們:
|
||||
|
||||
- **Issues**: 如果你有任何問題、建議或是發現任何的 Bug,請在 Issues 頁面中發起一個新的 Issue。盡可能提供詳細的資訊,讓我們能更快的釐清問題並解決。
|
||||
- **Pull Requests**: 如果你發現問題並修復了,歡迎發起 Pull Request。請確認依照我們的[貢獻指南](./CONTRIBUTING_zh-tw.md)。
|
||||
- **Discussions**: 如果你有更多的想法,可以在 Discussions 頁面發起一個新的討論。
|
||||
|
|
@ -1,164 +1,168 @@
|
|||
| **Components** | **License** | **Is there any modification** | **Open source code address** |
|
||||
| --------------------- | ------------------------------------------------------------ | -------------- | ------------------------------------------------------------ |
|
||||
| libsodium | ISC License | No | https://github.com/jedisct1/libsodium |
|
||||
| minmea | MIT License | Yes | https://github.com/kosma/minmea |
|
||||
| libyuv | BSD-3-Clause | No | https://chromium.googlesource.com/libyuv |
|
||||
| lvgl | MIT License | Yes | https://github.com/lvgl/lvgl |
|
||||
| lua | MIT License | No | https://github.com/lua/lua |
|
||||
| cJSON | MIT License | Yes | https://github.com/DaveGamble/cJSON |
|
||||
| MQTT-C | MIT License | No | https://github.com/LiamBindle/MQTT-C |
|
||||
| microADB | Apache License 2.0 | Yes | https://github.com/spiriou/microADB |
|
||||
| argtable3 | BSD-3-Clause | No | https://github.com/argtable/argtable3 |
|
||||
| libuv | MIT License | Yes | https://github.com/libuv/libuv |
|
||||
| Unity | MIT License | No | https://github.com/ThrowTheSwitch/Unity |
|
||||
| aac | Fraunhofer FDK AAC License | Yes | https://github.com/mstorsjo/fdk-aac |
|
||||
| avb | Apache License 2.0 | Yes | https://android.googlesource.com/platform/external/avb/ |
|
||||
| bzip2 | BSD | No | https://sourceware.org/bzip2/ |
|
||||
| cAT | MIT License | Yes | https://github.com/marcinbor85/cAT |
|
||||
| Chipmunk2D | MIT License | Yes | http://chipmunk2d.net https://github.com/slembcke/Chipmunk2D |
|
||||
| cmocka | Apache License 2.0 | Yes | https://gitlab.com/cmocka/cmocka |
|
||||
| cmsis | Apache License 2.0 | Yes | https://github.com/ARM-software/CMSIS_5 |
|
||||
| coremark | Apache License 2.0 | Yes | https://github.com/eembc/coremark |
|
||||
| curl | MIT License | Yes | https://curl.se https://github.com/curl/curl |
|
||||
| zlib | Zlib | Yes | http://www.zlib.org https://github.com/madler/zlib |
|
||||
| ddelta | BSD | Yes | https://github.com/julian-klode/ddelta |
|
||||
| dlg | BSL-1.0 | No | https://github.com/nyorain/dlg |
|
||||
| enet | MIT License | No | https://github.com/lsalzman/enet |
|
||||
| freetype | FreeType License | Yes | https://github.com/freetype/freetype |
|
||||
| googlebenchmark | Apache License 2.0 | Yes | https://github.com/google/benchmark |
|
||||
| googletest | BSD-3-Clause | Yes | https://google.github.io/googletest/ |
|
||||
| inipp | MIT License | No | https://github.com/mcmtroffaes/inipp |
|
||||
| iperf2 | MIT License | No | https://github.com/esnet/iperf |
|
||||
| iperf3 | MIT License | Yes | https://github.com/esnet/iperf |
|
||||
| json-c | BSD-3-Clause | No | https://github.com/json-c/json-c |
|
||||
| lc3 | Apache License 2.0 | Yes | https://www.bluetooth.com/specifications/specs/low-complexity-communication-codec-1-0/ |
|
||||
| libdivide | Zlib | Yes | https://github.com/ridiculousfish/libdivide |
|
||||
| libexpat | MIT License | No | https://github.com/libexpat/libexpat |
|
||||
| libfluoride-sbc | Apache License 2.0 | No | https://github.com/artem/libldac |
|
||||
| libpng | libpng-2.0 | Yes | https://github.com/pnggroup/libpng |
|
||||
| libtar | University of Illinois/NCSA Open Source License | Yes | https://repo.or.cz/w/libtar.git |
|
||||
| mbedtls | Apache License 2.0 | Yes | https://github.com/Mbed-TLS/mbedtls |
|
||||
| nanopb | Zlib | No | https://github.com/nanopb/nanopb |
|
||||
| Ne10 | BSD-3-Clause | Yes | https://github.com/projectNe10/Ne10 |
|
||||
| nghttp2 | MIT License | No | https://github.com/nghttp2/nghttp2 |
|
||||
| nng | MIT License | Yes | https://github.com/nanomsg/nng |
|
||||
| opus | BSD-3-Clause | Yes | https://opus-codec.org/ https://gitlab.xiph.org/xiph/opus |
|
||||
| protobuf-c | BSD-2-Clause | No | https://github.com/protobuf-c/protobuf-c |
|
||||
| quirc | ISC License | Yes | https://github.com/dlbeer/quirc |
|
||||
| rtos-benchmark | Apache License 2.0 | Yes | https://github.com/zephyrproject-rtos/rtos-benchmark |
|
||||
| thorvg | MIT License | No | https://github.com/thorvg/thorvg |
|
||||
| tinyxml2 | zlib License | Yes | https://github.com/leethomason/tinyxml2 |
|
||||
| unqlite | Apache License 2.0 | Yes | https://github.com/symisc/unqlite |
|
||||
| dhara | ISC License | No | https://github.com/dlbeer/dhara |
|
||||
| fatfs | FatFs License(BSD style) | Yes | http://elm-chan.org/fsw/ff/00index_e.html |
|
||||
| littlefs | BSD-3-Clause | Yes | https://github.com/littlefs-project/littlefs |
|
||||
| libsamplerate | BSD-2-Clause | No | https://github.com/libsndfile/libsamplerate |
|
||||
| openlibm | MIT License | Yes | https://github.com/JuliaMath/openlibm |
|
||||
| libcxx | Apache License 2.0 | Yes | https://github.com/llvm/llvm-project/tree/main/libcxx |
|
||||
| libcxxabi | MIT License | Yes | https://itanium-cxx-abi.github.io/cxx-abi |
|
||||
| tlsf | BSD | No | https://github.com/mattconte/tlsf |
|
||||
| libmetal | Apache License 2.0 | Yes | https://github.com/OpenAMP/libmetal |
|
||||
| open-amp | Apache License 2.0 | Yes | https://github.com/OpenAMP/open-amp |
|
||||
| apps | Apache License 2.0 | Yes | https://github.com/apache/nuttx-apps |
|
||||
| nuttx | Apache License 2.0 | Yes | https://github.com/apache/nuttx |
|
||||
| kmgk | Apache License 2.0 | Yes | https://github.com/linaro-swg/kmgk |
|
||||
| optee_client | BSD 2-clause | Yes | https://github.com/OP-TEE/optee_client |
|
||||
| optee_examples | BSD 2-clause | No | https://github.com/linaro-swg/optee_examples |
|
||||
| optee_os | BSD 2-Clause | Yes | https://github.com/OP-TEE/optee_os |
|
||||
| nist-sts | [License](https://unlicense.org/) | Yes | https://github.com/terrillmoore/NIST-Statistical-Test-Suite |
|
||||
| libtomcrypt | LibTom | Yes | https://github.com/libtom/libtomcrypt |
|
||||
| test-tlb | GPL-2.0 | Yes | https://github.com/torvalds/test-tlb |
|
||||
| tinycrypt | BSD 2-Clause | Yes | https://github.com/intel/tinycrypt |
|
||||
| unpv13e | [License](https://github.com/unpbook/unpv13e/blob/master/LICENSE) | No | https://github.com/unpbook/unpv13e |
|
||||
| wasm-micro-runtime | Apache License 2.0 | Yes | https://github.com/bytecodealliance/wasm-micro-runtime |
|
||||
| gemmlowp | Apache License 2.0 | No | https://github.com/google/gemmlowp |
|
||||
| kissfft | BSD-3-Clause | No | https://github.com/mborgerding/kissfft |
|
||||
| libtommath | LibTom | No | https://github.com/libtom/libtommath |
|
||||
| ruy | Apache License 2.0 | No | https://github.com/google/ruy |
|
||||
| CMSIS-NN | Apache License 2.0 | No | https://github.com/ARM-software/CMSIS-NN |
|
||||
| tflite-micro | Apache License 2.0 | Yes | https://github.com/tensorflow/tflite-micro |
|
||||
| connectedhomeip | Apache License 2.0 | Yes | https://github.com/project-chip/connectedhomeip |
|
||||
| nlassert | Apache License 2.0 | No | https://github.com/nestlabs/nlassert |
|
||||
| nlio | Apache License 2.0 | No | https://github.com/nestlabs/nlio |
|
||||
| nlunit-test | Apache License 2.0 | No | https://github.com/nestlabs/nlunit-test |
|
||||
| pigweed | Apache License 2.0 | No | https://github.com/google/pigweed |
|
||||
| jsoncpp | MIT License | Yes | https://github.com/open-source-parsers/jsoncpp |
|
||||
| flatbuffers | Apache License 2.0 | No | https://github.com/google/flatbuffers |
|
||||
| fff | MIT License | No | https://github.com/meekrosoft/fff |
|
||||
| libc-test | MIT License | No | https://github.com/AssemblyScript/libc-test |
|
||||
| ltp | GPL-2.0 | Yes | https://github.com/linux-test-project/ltp |
|
||||
| stressapptest | Apache License 2.0 | Yes | https://github.com/stressapptest/stressapptest |
|
||||
| abseil-cpp | Apache License 2.0 | No | https://github.com/abseil/abseil-cpp |
|
||||
| native | Apache License 2.0 | Yes | https://android.googlesource.com/platform/frameworks/native/ |
|
||||
| interfaces | Apache License 2.0 | No | https://android.googlesource.com/platform/hardware/interfaces/ |
|
||||
| libhardware | Apache License 2.0 | No | https://android.googlesource.com/platform/hardware/libhardware/ |
|
||||
| chre | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/chre/ |
|
||||
| core | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/core |
|
||||
| keymaster | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/keymaster |
|
||||
| libbase | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/libbase |
|
||||
| libcppbor | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/libcppbor |
|
||||
| libfmq | Apache License 2.0 | No | https://android.googlesource.com/platform/system/libfmq |
|
||||
| libhidl | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/libhidl |
|
||||
| libhwbinder | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/libhwbinder |
|
||||
| logging | Apache License 2.0 | No | https://android.googlesource.com/platform/system/logging |
|
||||
| security | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/security |
|
||||
| aidl | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/tools/aidl |
|
||||
| hidl | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/tools/hidl |
|
||||
| atomic_queue | MIT License | Yes | https://github.com/max0x7ba/atomic_queue |
|
||||
| auto-pts | GPL-2.0 | Yes | https://github.com/auto-pts/auto-pts |
|
||||
| c-ares | MIT License | Yes | https://github.com/c-ares/c-ares |
|
||||
| cmark-gfm | MIT License | Yes | https://github.com/github/cmark-gfm |
|
||||
| cpuid | ISC | No | https://github.com/tycho/cpuid |
|
||||
| dbus | GPL-2.0 | Yes | https://gitlab.freedesktop.org/dbus/dbus |
|
||||
| erpc | BSD-3-clause | Yes | https://github.com/EmbeddedRPC/erpc |
|
||||
| exfatprogs | GPL-2.0 | Yes | https://github.com/namjaejeon/exfatprogs |
|
||||
| fluoride | Apache License 2.0 | Yes | https://github.com/anchao/fluoride |
|
||||
| fmt | MIT License | Yes | https://github.com/fmtlib/fmt |
|
||||
| freetype | freetype license | Yes | https://gitlab.freedesktop.org/freetype/freetype |
|
||||
| dlg | Boost Software License - Version 1.0 | No | https://github.com/nyorain/dlg |
|
||||
| glib | LGPL-2.1 | Yes | https://github.com/GNOME/glib |
|
||||
| gvdb | LGPL-2.1 | No | https://github.com/GNOME/gvdb |
|
||||
| harfbuzz | "Old MIT" license | No | https://github.com/harfbuzz/harfbuzz |
|
||||
| ldns | Apache License 2.0 | Yes | https://github.com/NLnetLabs/ldns |
|
||||
| modp_b64 | BSD License | No | https://chromium.googlesource.com/chromium/src/third_party/modp_b64 |
|
||||
| libhelix-aac | Apache License 2.0 | Yes | https://github.com/pschatzmann/arduino-libhelix/tree/main/src/libhelix-aac |
|
||||
| libhelix-mp3 | Apache License 2.0 | Yes | https://github.com/pschatzmann/arduino-libhelix/tree/main/src/libhelix-mp3 |
|
||||
| libjpeg-turbo | libjpeg-turbo license | Yes | https://github.com/libjpeg-turbo/libjpeg-turbo |
|
||||
| libldac | Apache License 2.0 | Yes | https://android.googlesource.com/platform/external/libldac/ |
|
||||
| opencore-amr | Apache License 2.0 | Yes | https://sourceforge.net/projects/opencore-amr/ |
|
||||
| libssh-mirror | BSD 2-Clause | Yes | https://gitlab.com/libssh/libssh-mirror/ |
|
||||
| libtar | BSD | Yes | https://repo.or.cz/libtar.git |
|
||||
| libwebp | BSD-3-Clause license | Yes | https://chromium.googlesource.com/webm/libwebp |
|
||||
| lz4 | BSD | Yes | https://github.com/lz4/lz4 |
|
||||
| mdns | [License](https://github.com/mjansson/mdns/blob/main/LICENSE) | Yes | https://github.com/mjansson/mdns |
|
||||
| mmc-utils | GPL-2.0 | Yes | https://git.kernel.org/pub/scm/utils/mmc/mmc-utils.git |
|
||||
| mtp-responder | Apache License 2.0 | Yes | https://review.tizen.org/git/?p=framework/connectivity/mtp-responder.git |
|
||||
| ofono | GPL-2.0 license | Yes | https://github.com/ubports/ofono |
|
||||
| ell | LGPL-2.1 license | Yes | https://github.com/bryanperris/ell |
|
||||
| protobuf | [License](https://github.com/protocolbuffers/protobuf/blob/main/LICENSE) | No | https://github.com/protocolbuffers/protobuf |
|
||||
| rapidjson | MIT License | Yes | https://github.com/Tencent/rapidjson |
|
||||
| ril | Apache License 2.0 | Yes | https://android.googlesource.com/platform/hardware/ril/+/refs/tags/android-7.0.0_r7 |
|
||||
| rlottie | LGPL-v2.1 license | No | https://github.com/TelegramMessenger/rlottie |
|
||||
| silk-v3-decoder | Apache License 2.0 | Yes | https://github.com/kn007/silk-v3-decoder |
|
||||
| sqlite | BSD | No | https://github.com/sqlite/sqlite |
|
||||
| stress | GPL-2.0 | Yes | https://github.com/resurrecting-open-source-projects/stress |
|
||||
| sysklogd | GPL-2.0 | Yes | https://github.com/troglobit/sysklogd |
|
||||
| sil-kit | MIT License | No | https://github.com/vectorgrp/sil-kit |
|
||||
| sil-kit-adapters-qemu | MIT License | No | https://github.com/vectorgrp/sil-kit-adapters-qemu |
|
||||
| sil-kit-adapters-vcan | MIT License | No | https://github.com/vectorgrp/sil-kit-adapters-vcan |
|
||||
| yoga | MIT License | No | https://github.com/facebook/yoga |
|
||||
| zblue | Apache License 2.0 | Yes | https://github.com/zephyrproject-rtos/zephyr |
|
||||
| zint | GPL-3.0 | No | https://github.com/zint/zint |
|
||||
| nuttx | Apache License 2.0 | Yes | https://github.com/apache/nuttx |
|
||||
| SEGGER_SystemView | [License](https://github.com/RT-Thread-packages/SEGGER_SystemView/blob/master/SystemView_Src/License_SystemView.txt) | No | https://github.com/RT-Thread-packages/SEGGER_SystemView |
|
||||
| dtc | GPL-2.0 | No | https://github.com/dgibson/dtc |
|
||||
| libmcs | SPDX | No | https://gitlab.com/gtd-gmbh/libmcs |
|
||||
| newlib | LGPL | No | https://sourceware.org/pub/newlib |
|
||||
| libstdc++ | GPL-2.0 | No | https://github.com/gcc-mirror/gcc/tree/master/libstdc%2B%2B-v3/libsupc%2B%2B |
|
||||
| uClibc++ | LGPL-2.1 | No | [https://cxx.uclibc.org/src/](https://git.busybox.net/uClibc++) |
|
||||
| tlsf | BSD | Yes | https://github.com/mattconte/tlsf |
|
||||
| X-TRACK | MIT License | No | https://github.com/FASTSHIFT/X-TRACK |
|
||||
| wamr | Apache License 2.0 | No | https://github.com/bytecodealliance/wasm-micro-runtime |
|
||||
| libopencore-amr | Apache License 2.0 | Yes | https://github.com/BelledonneCommunications/opencore-amr/blob/master |
|
||||
| kconfig-frontends | GPL-2.0 | Yes | https://bitbucket.org/nuttx/tools/src/master/kconfig-frontends/ |
|
||||
| FFmpeg | LGPL v2.1+ | Yes | https://github.com/FFmpeg/FFmpeg.git |
|
||||
# Third-Party Open Source Software Notice
|
||||
|
||||
\[ English | [简体中文](./Third_Party_and_Open_Source_Components_zh-cn.md) \]
|
||||
|
||||
| **Components** | **License** | **Is there any modification** | **Open source code address** |
|
||||
| --------------------- | -------------------------------------------------------------------------------------------------------------------- | ----------------------------- | -------------------------------------------------------------------------------------- |
|
||||
| libsodium | ISC License | No | https://github.com/jedisct1/libsodium |
|
||||
| minmea | MIT License | Yes | https://github.com/kosma/minmea |
|
||||
| libyuv | BSD-3-Clause | No | https://chromium.googlesource.com/libyuv |
|
||||
| lvgl | MIT License | Yes | https://github.com/lvgl/lvgl |
|
||||
| lua | MIT License | No | https://github.com/lua/lua |
|
||||
| cJSON | MIT License | Yes | https://github.com/DaveGamble/cJSON |
|
||||
| MQTT-C | MIT License | No | https://github.com/LiamBindle/MQTT-C |
|
||||
| microADB | Apache License 2.0 | Yes | https://github.com/spiriou/microADB |
|
||||
| argtable3 | BSD-3-Clause | No | https://github.com/argtable/argtable3 |
|
||||
| libuv | MIT License | Yes | https://github.com/libuv/libuv |
|
||||
| Unity | MIT License | No | https://github.com/ThrowTheSwitch/Unity |
|
||||
| aac | Fraunhofer FDK AAC License | Yes | https://github.com/mstorsjo/fdk-aac |
|
||||
| avb | Apache License 2.0 | Yes | https://android.googlesource.com/platform/external/avb/ |
|
||||
| bzip2 | BSD | No | https://sourceware.org/bzip2/ |
|
||||
| cAT | MIT License | Yes | https://github.com/marcinbor85/cAT |
|
||||
| Chipmunk2D | MIT License | Yes | http://chipmunk2d.net https://github.com/slembcke/Chipmunk2D |
|
||||
| cmocka | Apache License 2.0 | Yes | https://gitlab.com/cmocka/cmocka |
|
||||
| cmsis | Apache License 2.0 | Yes | https://github.com/ARM-software/CMSIS_5 |
|
||||
| coremark | Apache License 2.0 | Yes | https://github.com/eembc/coremark |
|
||||
| curl | MIT License | Yes | https://curl.se https://github.com/curl/curl |
|
||||
| zlib | Zlib | Yes | http://www.zlib.org https://github.com/madler/zlib |
|
||||
| ddelta | BSD | Yes | https://github.com/julian-klode/ddelta |
|
||||
| dlg | BSL-1.0 | No | https://github.com/nyorain/dlg |
|
||||
| enet | MIT License | No | https://github.com/lsalzman/enet |
|
||||
| freetype | FreeType License | Yes | https://github.com/freetype/freetype |
|
||||
| googlebenchmark | Apache License 2.0 | Yes | https://github.com/google/benchmark |
|
||||
| googletest | BSD-3-Clause | Yes | https://google.github.io/googletest/ |
|
||||
| inipp | MIT License | No | https://github.com/mcmtroffaes/inipp |
|
||||
| iperf2 | MIT License | No | https://github.com/esnet/iperf |
|
||||
| iperf3 | MIT License | Yes | https://github.com/esnet/iperf |
|
||||
| json-c | BSD-3-Clause | No | https://github.com/json-c/json-c |
|
||||
| lc3 | Apache License 2.0 | Yes | https://www.bluetooth.com/specifications/specs/low-complexity-communication-codec-1-0/ |
|
||||
| libdivide | Zlib | Yes | https://github.com/ridiculousfish/libdivide |
|
||||
| libexpat | MIT License | No | https://github.com/libexpat/libexpat |
|
||||
| libfluoride-sbc | Apache License 2.0 | No | https://github.com/artem/libldac |
|
||||
| libpng | libpng-2.0 | Yes | https://github.com/pnggroup/libpng |
|
||||
| libtar | University of Illinois/NCSA Open Source License | Yes | https://repo.or.cz/w/libtar.git |
|
||||
| mbedtls | Apache License 2.0 | Yes | https://github.com/Mbed-TLS/mbedtls |
|
||||
| nanopb | Zlib | No | https://github.com/nanopb/nanopb |
|
||||
| Ne10 | BSD-3-Clause | Yes | https://github.com/projectNe10/Ne10 |
|
||||
| nghttp2 | MIT License | No | https://github.com/nghttp2/nghttp2 |
|
||||
| nng | MIT License | Yes | https://github.com/nanomsg/nng |
|
||||
| opus | BSD-3-Clause | Yes | https://opus-codec.org/ https://gitlab.xiph.org/xiph/opus |
|
||||
| protobuf-c | BSD-2-Clause | No | https://github.com/protobuf-c/protobuf-c |
|
||||
| quirc | ISC License | Yes | https://github.com/dlbeer/quirc |
|
||||
| rtos-benchmark | Apache License 2.0 | Yes | https://github.com/zephyrproject-rtos/rtos-benchmark |
|
||||
| thorvg | MIT License | No | https://github.com/thorvg/thorvg |
|
||||
| tinyxml2 | zlib License | Yes | https://github.com/leethomason/tinyxml2 |
|
||||
| unqlite | Apache License 2.0 | Yes | https://github.com/symisc/unqlite |
|
||||
| dhara | ISC License | No | https://github.com/dlbeer/dhara |
|
||||
| fatfs | FatFs License(BSD style) | Yes | http://elm-chan.org/fsw/ff/00index_e.html |
|
||||
| littlefs | BSD-3-Clause | Yes | https://github.com/littlefs-project/littlefs |
|
||||
| libsamplerate | BSD-2-Clause | No | https://github.com/libsndfile/libsamplerate |
|
||||
| openlibm | MIT License | Yes | https://github.com/JuliaMath/openlibm |
|
||||
| libcxx | Apache License 2.0 | Yes | https://github.com/llvm/llvm-project/tree/main/libcxx |
|
||||
| libcxxabi | MIT License | Yes | https://itanium-cxx-abi.github.io/cxx-abi |
|
||||
| tlsf | BSD | No | https://github.com/mattconte/tlsf |
|
||||
| libmetal | Apache License 2.0 | Yes | https://github.com/OpenAMP/libmetal |
|
||||
| open-amp | Apache License 2.0 | Yes | https://github.com/OpenAMP/open-amp |
|
||||
| apps | Apache License 2.0 | Yes | https://github.com/apache/nuttx-apps |
|
||||
| nuttx | Apache License 2.0 | Yes | https://github.com/apache/nuttx |
|
||||
| kmgk | Apache License 2.0 | Yes | https://github.com/linaro-swg/kmgk |
|
||||
| optee_client | BSD 2-clause | Yes | https://github.com/OP-TEE/optee_client |
|
||||
| optee_examples | BSD 2-clause | No | https://github.com/linaro-swg/optee_examples |
|
||||
| optee_os | BSD 2-Clause | Yes | https://github.com/OP-TEE/optee_os |
|
||||
| nist-sts | [License](https://unlicense.org/) | Yes | https://github.com/terrillmoore/NIST-Statistical-Test-Suite |
|
||||
| libtomcrypt | LibTom | Yes | https://github.com/libtom/libtomcrypt |
|
||||
| test-tlb | GPL-2.0 | Yes | https://github.com/torvalds/test-tlb |
|
||||
| tinycrypt | BSD 2-Clause | Yes | https://github.com/intel/tinycrypt |
|
||||
| unpv13e | [License](https://github.com/unpbook/unpv13e/blob/master/LICENSE) | No | https://github.com/unpbook/unpv13e |
|
||||
| wasm-micro-runtime | Apache License 2.0 | Yes | https://github.com/bytecodealliance/wasm-micro-runtime |
|
||||
| gemmlowp | Apache License 2.0 | No | https://github.com/google/gemmlowp |
|
||||
| kissfft | BSD-3-Clause | No | https://github.com/mborgerding/kissfft |
|
||||
| libtommath | LibTom | No | https://github.com/libtom/libtommath |
|
||||
| ruy | Apache License 2.0 | No | https://github.com/google/ruy |
|
||||
| CMSIS-NN | Apache License 2.0 | No | https://github.com/ARM-software/CMSIS-NN |
|
||||
| tflite-micro | Apache License 2.0 | Yes | https://github.com/tensorflow/tflite-micro |
|
||||
| connectedhomeip | Apache License 2.0 | Yes | https://github.com/project-chip/connectedhomeip |
|
||||
| nlassert | Apache License 2.0 | No | https://github.com/nestlabs/nlassert |
|
||||
| nlio | Apache License 2.0 | No | https://github.com/nestlabs/nlio |
|
||||
| nlunit-test | Apache License 2.0 | No | https://github.com/nestlabs/nlunit-test |
|
||||
| pigweed | Apache License 2.0 | No | https://github.com/google/pigweed |
|
||||
| jsoncpp | MIT License | Yes | https://github.com/open-source-parsers/jsoncpp |
|
||||
| flatbuffers | Apache License 2.0 | No | https://github.com/google/flatbuffers |
|
||||
| fff | MIT License | No | https://github.com/meekrosoft/fff |
|
||||
| libc-test | MIT License | No | https://github.com/AssemblyScript/libc-test |
|
||||
| ltp | GPL-2.0 | Yes | https://github.com/linux-test-project/ltp |
|
||||
| stressapptest | Apache License 2.0 | Yes | https://github.com/stressapptest/stressapptest |
|
||||
| abseil-cpp | Apache License 2.0 | No | https://github.com/abseil/abseil-cpp |
|
||||
| native | Apache License 2.0 | Yes | https://android.googlesource.com/platform/frameworks/native/ |
|
||||
| interfaces | Apache License 2.0 | No | https://android.googlesource.com/platform/hardware/interfaces/ |
|
||||
| libhardware | Apache License 2.0 | No | https://android.googlesource.com/platform/hardware/libhardware/ |
|
||||
| chre | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/chre/ |
|
||||
| core | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/core |
|
||||
| keymaster | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/keymaster |
|
||||
| libbase | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/libbase |
|
||||
| libcppbor | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/libcppbor |
|
||||
| libfmq | Apache License 2.0 | No | https://android.googlesource.com/platform/system/libfmq |
|
||||
| libhidl | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/libhidl |
|
||||
| libhwbinder | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/libhwbinder |
|
||||
| logging | Apache License 2.0 | No | https://android.googlesource.com/platform/system/logging |
|
||||
| security | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/security |
|
||||
| aidl | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/tools/aidl |
|
||||
| hidl | Apache License 2.0 | Yes | https://android.googlesource.com/platform/system/tools/hidl |
|
||||
| atomic_queue | MIT License | Yes | https://github.com/max0x7ba/atomic_queue |
|
||||
| auto-pts | GPL-2.0 | Yes | https://github.com/auto-pts/auto-pts |
|
||||
| c-ares | MIT License | Yes | https://github.com/c-ares/c-ares |
|
||||
| cmark-gfm | MIT License | Yes | https://github.com/github/cmark-gfm |
|
||||
| cpuid | ISC | No | https://github.com/tycho/cpuid |
|
||||
| dbus | GPL-2.0 | Yes | https://gitlab.freedesktop.org/dbus/dbus |
|
||||
| erpc | BSD-3-clause | Yes | https://github.com/EmbeddedRPC/erpc |
|
||||
| exfatprogs | GPL-2.0 | Yes | https://github.com/namjaejeon/exfatprogs |
|
||||
| fluoride | Apache License 2.0 | Yes | https://github.com/anchao/fluoride |
|
||||
| fmt | MIT License | Yes | https://github.com/fmtlib/fmt |
|
||||
| freetype | freetype license | Yes | https://gitlab.freedesktop.org/freetype/freetype |
|
||||
| dlg | Boost Software License - Version 1.0 | No | https://github.com/nyorain/dlg |
|
||||
| glib | LGPL-2.1 | Yes | https://github.com/GNOME/glib |
|
||||
| gvdb | LGPL-2.1 | No | https://github.com/GNOME/gvdb |
|
||||
| harfbuzz | "Old MIT" license | No | https://github.com/harfbuzz/harfbuzz |
|
||||
| ldns | Apache License 2.0 | Yes | https://github.com/NLnetLabs/ldns |
|
||||
| modp_b64 | BSD License | No | https://chromium.googlesource.com/chromium/src/third_party/modp_b64 |
|
||||
| libhelix-aac | Apache License 2.0 | Yes | https://github.com/pschatzmann/arduino-libhelix/tree/main/src/libhelix-aac |
|
||||
| libhelix-mp3 | Apache License 2.0 | Yes | https://github.com/pschatzmann/arduino-libhelix/tree/main/src/libhelix-mp3 |
|
||||
| libjpeg-turbo | libjpeg-turbo license | Yes | https://github.com/libjpeg-turbo/libjpeg-turbo |
|
||||
| libldac | Apache License 2.0 | Yes | https://android.googlesource.com/platform/external/libldac/ |
|
||||
| opencore-amr | Apache License 2.0 | Yes | https://sourceforge.net/projects/opencore-amr/ |
|
||||
| libssh-mirror | BSD 2-Clause | Yes | https://gitlab.com/libssh/libssh-mirror/ |
|
||||
| libtar | BSD | Yes | https://repo.or.cz/libtar.git |
|
||||
| libwebp | BSD-3-Clause license | Yes | https://chromium.googlesource.com/webm/libwebp |
|
||||
| lz4 | BSD | Yes | https://github.com/lz4/lz4 |
|
||||
| mdns | [License](https://github.com/mjansson/mdns/blob/main/LICENSE) | Yes | https://github.com/mjansson/mdns |
|
||||
| mmc-utils | GPL-2.0 | Yes | https://git.kernel.org/pub/scm/utils/mmc/mmc-utils.git |
|
||||
| mtp-responder | Apache License 2.0 | Yes | https://review.tizen.org/git/?p=framework/connectivity/mtp-responder.git |
|
||||
| ofono | GPL-2.0 license | Yes | https://github.com/ubports/ofono |
|
||||
| ell | LGPL-2.1 license | Yes | https://github.com/bryanperris/ell |
|
||||
| protobuf | [License](https://github.com/protocolbuffers/protobuf/blob/main/LICENSE) | No | https://github.com/protocolbuffers/protobuf |
|
||||
| rapidjson | MIT License | Yes | https://github.com/Tencent/rapidjson |
|
||||
| ril | Apache License 2.0 | Yes | https://android.googlesource.com/platform/hardware/ril/+/refs/tags/android-7.0.0_r7 |
|
||||
| rlottie | LGPL-v2.1 license | No | https://github.com/TelegramMessenger/rlottie |
|
||||
| silk-v3-decoder | Apache License 2.0 | Yes | https://github.com/kn007/silk-v3-decoder |
|
||||
| sqlite | BSD | No | https://github.com/sqlite/sqlite |
|
||||
| stress | GPL-2.0 | Yes | https://github.com/resurrecting-open-source-projects/stress |
|
||||
| sysklogd | GPL-2.0 | Yes | https://github.com/troglobit/sysklogd |
|
||||
| sil-kit | MIT License | No | https://github.com/vectorgrp/sil-kit |
|
||||
| sil-kit-adapters-qemu | MIT License | No | https://github.com/vectorgrp/sil-kit-adapters-qemu |
|
||||
| sil-kit-adapters-vcan | MIT License | No | https://github.com/vectorgrp/sil-kit-adapters-vcan |
|
||||
| yoga | MIT License | No | https://github.com/facebook/yoga |
|
||||
| zblue | Apache License 2.0 | Yes | https://github.com/zephyrproject-rtos/zephyr |
|
||||
| zint | GPL-3.0 | No | https://github.com/zint/zint |
|
||||
| nuttx | Apache License 2.0 | Yes | https://github.com/apache/nuttx |
|
||||
| SEGGER_SystemView | [License](https://github.com/RT-Thread-packages/SEGGER_SystemView/blob/master/SystemView_Src/License_SystemView.txt) | No | https://github.com/RT-Thread-packages/SEGGER_SystemView |
|
||||
| dtc | GPL-2.0 | No | https://github.com/dgibson/dtc |
|
||||
| libmcs | SPDX | No | https://gitlab.com/gtd-gmbh/libmcs |
|
||||
| newlib | LGPL | No | https://sourceware.org/pub/newlib |
|
||||
| libstdc++ | GPL-2.0 | No | https://github.com/gcc-mirror/gcc/tree/master/libstdc%2B%2B-v3/libsupc%2B%2B |
|
||||
| uClibc++ | LGPL-2.1 | No | [https://cxx.uclibc.org/src/](https://git.busybox.net/uClibc++) |
|
||||
| tlsf | BSD | Yes | https://github.com/mattconte/tlsf |
|
||||
| X-TRACK | MIT License | No | https://github.com/FASTSHIFT/X-TRACK |
|
||||
| wamr | Apache License 2.0 | No | https://github.com/bytecodealliance/wasm-micro-runtime |
|
||||
| libopencore-amr | Apache License 2.0 | Yes | https://github.com/BelledonneCommunications/opencore-amr/blob/master |
|
||||
| kconfig-frontends | GPL-2.0 | Yes | https://bitbucket.org/nuttx/tools/src/master/kconfig-frontends/ |
|
||||
| FFmpeg | LGPL v2.1+ | Yes | https://github.com/FFmpeg/FFmpeg.git |
|
||||
|
|
|
|||
|
|
@ -1,164 +1,168 @@
|
|||
| **组件** | **License** | **是否有修改** | **开源代码地址** |
|
||||
| --------------------- | ------------------ | -------------- | ------------------------------------------------------------ |
|
||||
| libsodium | ISC License | 否 | https://github.com/jedisct1/libsodium |
|
||||
| minmea | MIT License | 是 | https://github.com/kosma/minmea |
|
||||
| libyuv | BSD-3-Clause | 否 | https://chromium.googlesource.com/libyuv |
|
||||
| lvgl | MIT License | 是 | https://github.com/lvgl/lvgl |
|
||||
| lua | MIT License | 否 | https://github.com/lua/lua |
|
||||
| cJSON | MIT License | 是 | https://github.com/DaveGamble/cJSON |
|
||||
| MQTT-C | MIT License | 否 | https://github.com/LiamBindle/MQTT-C |
|
||||
| microADB | Apache License 2.0 | 是 | https://github.com/spiriou/microADB |
|
||||
| argtable3 | BSD-3-Clause | 否 | https://github.com/argtable/argtable3 |
|
||||
| libuv | MIT License | 是 | https://github.com/libuv/libuv |
|
||||
| Unity | MIT License | 否 | https://github.com/ThrowTheSwitch/Unity |
|
||||
| aac | Fraunhofer FDK AAC License | 是 | https://github.com/mstorsjo/fdk-aac |
|
||||
| avb | Apache License 2.0 | 是 | https://android.googlesource.com/platform/external/avb/ |
|
||||
| bzip2 | BSD | 否 | https://sourceware.org/bzip2/ |
|
||||
| cAT | MIT License | 是 | https://github.com/marcinbor85/cAT |
|
||||
| Chipmunk2D | MIT License | 是 | http://chipmunk2d.net https://github.com/slembcke/Chipmunk2D |
|
||||
| cmocka | Apache License 2.0 | 是 | https://gitlab.com/cmocka/cmocka |
|
||||
| cmsis | Apache License 2.0 | 是 | https://github.com/ARM-software/CMSIS_5 |
|
||||
| coremark | Apache License 2.0 | 是 | https://github.com/eembc/coremark |
|
||||
| curl | MIT License | 是 | https://curl.se https://github.com/curl/curl |
|
||||
| zlib | Zlib | 是 | http://www.zlib.org https://github.com/madler/zlib |
|
||||
| ddelta | BSD | 是 | https://github.com/julian-klode/ddelta |
|
||||
| dlg | BSL-1.0 | 否 | https://github.com/nyorain/dlg |
|
||||
| enet | MIT License | 否 | https://github.com/lsalzman/enet |
|
||||
| freetype | FreeType License | 是 | https://github.com/freetype/freetype |
|
||||
| googlebenchmark | Apache License 2.0 | 是 | https://github.com/google/benchmark |
|
||||
| googletest | BSD-3-Clause | 是 | https://google.github.io/googletest/ |
|
||||
| inipp | MIT License | 否 | https://github.com/mcmtroffaes/inipp |
|
||||
| iperf2 | MIT License | 否 | https://github.com/esnet/iperf |
|
||||
| iperf3 | MIT License | 是 | https://github.com/esnet/iperf |
|
||||
| json-c | BSD-3-Clause | 否 | https://github.com/json-c/json-c |
|
||||
| lc3 | Apache License 2.0 | 是 | https://www.bluetooth.com/specifications/specs/low-complexity-communication-codec-1-0/ |
|
||||
| libdivide | Zlib | 是 | https://github.com/ridiculousfish/libdivide |
|
||||
| libexpat | MIT License | 否 | https://github.com/libexpat/libexpat |
|
||||
| libfluoride-sbc | Apache License 2.0 | 否 | https://github.com/artem/libldac |
|
||||
| libpng | libpng-2.0 | 是 | https://github.com/pnggroup/libpng |
|
||||
| libtar | University of Illinois/NCSA Open Source License | 是 | https://repo.or.cz/w/libtar.git |
|
||||
| mbedtls | Apache License 2.0 | 是 | https://github.com/Mbed-TLS/mbedtls |
|
||||
| nanopb | Zlib | 否 | https://github.com/nanopb/nanopb |
|
||||
| Ne10 | BSD-3-Clause | 是 | https://github.com/projectNe10/Ne10 |
|
||||
| nghttp2 | MIT License | 否 | https://github.com/nghttp2/nghttp2 |
|
||||
| nng | MIT License | 是 | https://github.com/nanomsg/nng |
|
||||
| opus | BSD-3-Clause | 是 | https://opus-codec.org/ https://gitlab.xiph.org/xiph/opus |
|
||||
| protobuf-c | BSD-2-Clause | 否 | https://github.com/protobuf-c/protobuf-c |
|
||||
| quirc | ISC License | 是 | https://github.com/dlbeer/quirc |
|
||||
| rtos-benchmark | Apache License 2.0 | 是 | https://github.com/zephyrproject-rtos/rtos-benchmark |
|
||||
| thorvg | MIT License | 否 | https://github.com/thorvg/thorvg |
|
||||
| tinyxml2 | zlib License | 是 | https://github.com/leethomason/tinyxml2 |
|
||||
| unqlite | Apache License 2.0 | 是 | https://github.com/symisc/unqlite |
|
||||
| dhara | ISC License | 否 | https://github.com/dlbeer/dhara |
|
||||
| fatfs | FatFs License(BSD style) | 是 | http://elm-chan.org/fsw/ff/00index_e.html |
|
||||
| littlefs | BSD-3-Clause | 是 | https://github.com/littlefs-project/littlefs |
|
||||
| libsamplerate | BSD-2-Clause | 否 | https://github.com/libsndfile/libsamplerate |
|
||||
| openlibm | MIT License | 是 | https://github.com/JuliaMath/openlibm |
|
||||
| libcxx | Apache License 2.0 | 是 | https://github.com/llvm/llvm-project/tree/main/libcxx |
|
||||
| libcxxabi | MIT License | 是 | https://itanium-cxx-abi.github.io/cxx-abi |
|
||||
| tlsf | BSD | 否 | https://github.com/mattconte/tlsf |
|
||||
| libmetal | Apache License 2.0 | 是 | https://github.com/OpenAMP/libmetal |
|
||||
| open-amp | Apache License 2.0 | 是 | https://github.com/OpenAMP/open-amp |
|
||||
| apps | Apache License 2.0 | 是 | https://github.com/apache/nuttx-apps |
|
||||
| nuttx | Apache License 2.0 | 是 | https://github.com/apache/nuttx |
|
||||
| kmgk | Apache License 2.0 | 是 | https://github.com/linaro-swg/kmgk |
|
||||
| optee_client | BSD 2-clause | 是 | https://github.com/OP-TEE/optee_client |
|
||||
| optee_examples | BSD 2-clause | 否 | https://github.com/linaro-swg/optee_examples |
|
||||
| optee_os | BSD 2-Clause | 是 | https://github.com/OP-TEE/optee_os |
|
||||
| nist-sts | [License](https://unlicense.org/) | 是 | https://github.com/terrillmoore/NIST-Statistical-Test-Suite |
|
||||
| libtomcrypt | LibTom | 是 | https://github.com/libtom/libtomcrypt |
|
||||
| test-tlb | GPL-2.0 | 是 | https://github.com/torvalds/test-tlb |
|
||||
| tinycrypt | BSD 2-Clause | 是 | https://github.com/intel/tinycrypt |
|
||||
| unpv13e | [License](https://github.com/unpbook/unpv13e/blob/master/LICENSE) | 否 | https://github.com/unpbook/unpv13e |
|
||||
| wasm-micro-runtime | Apache License 2.0 | 是 | https://github.com/bytecodealliance/wasm-micro-runtime |
|
||||
| gemmlowp | Apache License 2.0 | 否 | https://github.com/google/gemmlowp |
|
||||
| kissfft | BSD-3-Clause | 否 | https://github.com/mborgerding/kissfft |
|
||||
| libtommath | LibTom | 否 | https://github.com/libtom/libtommath |
|
||||
| ruy | Apache License 2.0 | 否 | https://github.com/google/ruy |
|
||||
| CMSIS-NN | Apache License 2.0 | 否 | https://github.com/ARM-software/CMSIS-NN |
|
||||
| tflite-micro | Apache License 2.0 | 是 | https://github.com/tensorflow/tflite-micro |
|
||||
| connectedhomeip | Apache License 2.0 | 是 | https://github.com/project-chip/connectedhomeip |
|
||||
| nlassert | Apache License 2.0 | 否 | https://github.com/nestlabs/nlassert |
|
||||
| nlio | Apache License 2.0 | 否 | https://github.com/nestlabs/nlio |
|
||||
| nlunit-test | Apache License 2.0 | 否 | https://github.com/nestlabs/nlunit-test |
|
||||
| pigweed | Apache License 2.0 | 否 | https://github.com/google/pigweed |
|
||||
| jsoncpp | MIT License | 是 | https://github.com/open-source-parsers/jsoncpp |
|
||||
| flatbuffers | Apache License 2.0 | 否 | https://github.com/google/flatbuffers |
|
||||
| fff | MIT License | 否 | https://github.com/meekrosoft/fff |
|
||||
| libc-test | MIT License | 否 | https://github.com/AssemblyScript/libc-test |
|
||||
| ltp | GPL-2.0 | 是 | https://github.com/linux-test-project/ltp |
|
||||
| stressapptest | Apache License 2.0 | 是 | https://github.com/stressapptest/stressapptest |
|
||||
| abseil-cpp | Apache License 2.0 | 否 | https://github.com/abseil/abseil-cpp |
|
||||
| native | Apache License 2.0 | 是 | https://android.googlesource.com/platform/frameworks/native/ |
|
||||
| interfaces | Apache License 2.0 | 否 | https://android.googlesource.com/platform/hardware/interfaces/ |
|
||||
| libhardware | Apache License 2.0 | 否 | https://android.googlesource.com/platform/hardware/libhardware/ |
|
||||
| chre | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/chre/ |
|
||||
| core | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/core |
|
||||
| keymaster | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/keymaster |
|
||||
| libbase | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/libbase |
|
||||
| libcppbor | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/libcppbor |
|
||||
| libfmq | Apache License 2.0 | 否 | https://android.googlesource.com/platform/system/libfmq |
|
||||
| libhidl | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/libhidl |
|
||||
| libhwbinder | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/libhwbinder |
|
||||
| logging | Apache License 2.0 | 否 | https://android.googlesource.com/platform/system/logging |
|
||||
| security | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/security |
|
||||
| aidl | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/tools/aidl |
|
||||
| hidl | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/tools/hidl |
|
||||
| atomic_queue | MIT License | 是 | https://github.com/max0x7ba/atomic_queue |
|
||||
| auto-pts | GPL-2.0 | 是 | https://github.com/auto-pts/auto-pts |
|
||||
| c-ares | MIT License | 是 | https://github.com/c-ares/c-ares |
|
||||
| cmark-gfm | MIT License | 是 | https://github.com/github/cmark-gfm |
|
||||
| cpuid | ISC | 否 | https://github.com/tycho/cpuid |
|
||||
| dbus | GPL-2.0 | 是 | https://gitlab.freedesktop.org/dbus/dbus |
|
||||
| erpc | BSD-3-clause | 是 | https://github.com/EmbeddedRPC/erpc |
|
||||
| exfatprogs | GPL-2.0 | 是 | https://github.com/namjaejeon/exfatprogs |
|
||||
| fluoride | Apache License 2.0 | 是 | https://github.com/anchao/fluoride |
|
||||
| fmt | MIT License | 是 | https://github.com/fmtlib/fmt |
|
||||
| freetype | freetype license | 是 | https://gitlab.freedesktop.org/freetype/freetype |
|
||||
| dlg | Boost Software License - Version 1.0 | 否 | https://github.com/nyorain/dlg |
|
||||
| glib | LGPL-2.1 | 是 | https://github.com/GNOME/glib |
|
||||
| gvdb | LGPL-2.1 | 否 | https://github.com/GNOME/gvdb |
|
||||
| harfbuzz | "Old MIT" license | 否 | https://github.com/harfbuzz/harfbuzz |
|
||||
| ldns | Apache License 2.0 | 是 | https://github.com/NLnetLabs/ldns |
|
||||
| modp_b64 | BSD License | 否 | https://chromium.googlesource.com/chromium/src/third_party/modp_b64 |
|
||||
| libhelix-aac | Apache License 2.0 | 是 | https://github.com/pschatzmann/arduino-libhelix/tree/main/src/libhelix-aac |
|
||||
| libhelix-mp3 | Apache License 2.0 | 是 | https://github.com/pschatzmann/arduino-libhelix/tree/main/src/libhelix-mp3 |
|
||||
| libjpeg-turbo | libjpeg-turbo license | 是 | https://github.com/libjpeg-turbo/libjpeg-turbo |
|
||||
| libldac | Apache License 2.0 | 是 | https://android.googlesource.com/platform/external/libldac/ |
|
||||
| opencore-amr | Apache License 2.0 | 是 | https://sourceforge.net/projects/opencore-amr/ |
|
||||
| libssh-mirror | BSD 2-Clause | 是 | https://gitlab.com/libssh/libssh-mirror/ |
|
||||
| libtar | BSD | 是 | https://repo.or.cz/libtar.git |
|
||||
| libwebp | BSD-3-Clause license | 是 | https://chromium.googlesource.com/webm/libwebp |
|
||||
| lz4 | BSD | 是 | https://github.com/lz4/lz4 |
|
||||
| mdns | [License](https://github.com/mjansson/mdns/blob/main/LICENSE) | 是 | https://github.com/mjansson/mdns |
|
||||
| mmc-utils | GPL-2.0 | 是 | https://git.kernel.org/pub/scm/utils/mmc/mmc-utils.git |
|
||||
| mtp-responder | Apache License 2.0 | 是 | https://review.tizen.org/git/?p=framework/connectivity/mtp-responder.git |
|
||||
| ofono | GPL-2.0 license | 是 | https://github.com/ubports/ofono |
|
||||
| ell | LGPL-2.1 license | 是 | https://github.com/bryanperris/ell |
|
||||
| protobuf | [License](https://github.com/protocolbuffers/protobuf/blob/main/LICENSE) | 否 | https://github.com/protocolbuffers/protobuf |
|
||||
| rapidjson | MIT License | 是 | https://github.com/Tencent/rapidjson |
|
||||
| ril | Apache License 2.0 | 是 | https://android.googlesource.com/platform/hardware/ril/+/refs/tags/android-7.0.0_r7 |
|
||||
| rlottie | LGPL-v2.1 license | 否 | https://github.com/TelegramMessenger/rlottie |
|
||||
| silk-v3-decoder | Apache License 2.0 | 是 | https://github.com/kn007/silk-v3-decoder |
|
||||
| sqlite | BSD | 否 | https://github.com/sqlite/sqlite |
|
||||
| stress | GPL-2.0 | 是 | https://github.com/resurrecting-open-source-projects/stress |
|
||||
| sysklogd | GPL-2.0 | 是 | https://github.com/troglobit/sysklogd |
|
||||
| sil-kit | MIT License | 否 | https://github.com/vectorgrp/sil-kit |
|
||||
| sil-kit-adapters-qemu | MIT License | 否 | https://github.com/vectorgrp/sil-kit-adapters-qemu |
|
||||
| sil-kit-adapters-vcan | MIT License | 否 | https://github.com/vectorgrp/sil-kit-adapters-vcan |
|
||||
| yoga | MIT License | 否 | https://github.com/facebook/yoga |
|
||||
| zblue | Apache License 2.0 | 是 | https://github.com/zephyrproject-rtos/zephyr |
|
||||
| zint | GPL-3.0 | 否 | https://github.com/zint/zint |
|
||||
| nuttx | Apache License 2.0 | 是 | https://github.com/apache/nuttx |
|
||||
| SEGGER_SystemView | [License](https://github.com/RT-Thread-packages/SEGGER_SystemView/blob/master/SystemView_Src/License_SystemView.txt) | 否 | https://github.com/RT-Thread-packages/SEGGER_SystemView |
|
||||
| dtc | GPL-2.0 | 否 | https://github.com/dgibson/dtc |
|
||||
| libmcs | SPDX | 否 | https://gitlab.com/gtd-gmbh/libmcs |
|
||||
| newlib | LGPL | 否 | https://sourceware.org/pub/newlib |
|
||||
| libstdc++ | GPL-2.0 | 否 | https://github.com/gcc-mirror/gcc/tree/master/libstdc%2B%2B-v3/libsupc%2B%2B |
|
||||
| uClibc++ | LGPL-2.1 | 否 | [https://cxx.uclibc.org/src/](https://git.busybox.net/uClibc++) |
|
||||
| tlsf | BSD | 是 | https://github.com/mattconte/tlsf |
|
||||
| X-TRACK | MIT License | 否 | https://github.com/FASTSHIFT/X-TRACK |
|
||||
| wamr | Apache License 2.0 | 否 | https://github.com/bytecodealliance/wasm-micro-runtime |
|
||||
| libopencore-amr | Apache License 2.0 | 是 | https://github.com/BelledonneCommunications/opencore-amr/blob/master |
|
||||
| kconfig-frontends | GPL-2.0 | 是 | https://bitbucket.org/nuttx/tools/src/master/kconfig-frontends/ |
|
||||
| FFmpeg | LGPL v2.1+ | 是 | https://github.com/FFmpeg/FFmpeg.git |
|
||||
# 第三方开源软件说明
|
||||
|
||||
[ [English](./Third_Party_and_Open_Source_Components.md) | 简体中文 ]
|
||||
|
||||
| **组件** | **License** | **是否有修改** | **开源代码地址** |
|
||||
| --------------------- | -------------------------------------------------------------------------------------------------------------------- | -------------- | -------------------------------------------------------------------------------------- |
|
||||
| libsodium | ISC License | 否 | https://github.com/jedisct1/libsodium |
|
||||
| minmea | MIT License | 是 | https://github.com/kosma/minmea |
|
||||
| libyuv | BSD-3-Clause | 否 | https://chromium.googlesource.com/libyuv |
|
||||
| lvgl | MIT License | 是 | https://github.com/lvgl/lvgl |
|
||||
| lua | MIT License | 否 | https://github.com/lua/lua |
|
||||
| cJSON | MIT License | 是 | https://github.com/DaveGamble/cJSON |
|
||||
| MQTT-C | MIT License | 否 | https://github.com/LiamBindle/MQTT-C |
|
||||
| microADB | Apache License 2.0 | 是 | https://github.com/spiriou/microADB |
|
||||
| argtable3 | BSD-3-Clause | 否 | https://github.com/argtable/argtable3 |
|
||||
| libuv | MIT License | 是 | https://github.com/libuv/libuv |
|
||||
| Unity | MIT License | 否 | https://github.com/ThrowTheSwitch/Unity |
|
||||
| aac | Fraunhofer FDK AAC License | 是 | https://github.com/mstorsjo/fdk-aac |
|
||||
| avb | Apache License 2.0 | 是 | https://android.googlesource.com/platform/external/avb/ |
|
||||
| bzip2 | BSD | 否 | https://sourceware.org/bzip2/ |
|
||||
| cAT | MIT License | 是 | https://github.com/marcinbor85/cAT |
|
||||
| Chipmunk2D | MIT License | 是 | http://chipmunk2d.net https://github.com/slembcke/Chipmunk2D |
|
||||
| cmocka | Apache License 2.0 | 是 | https://gitlab.com/cmocka/cmocka |
|
||||
| cmsis | Apache License 2.0 | 是 | https://github.com/ARM-software/CMSIS_5 |
|
||||
| coremark | Apache License 2.0 | 是 | https://github.com/eembc/coremark |
|
||||
| curl | MIT License | 是 | https://curl.se https://github.com/curl/curl |
|
||||
| zlib | Zlib | 是 | http://www.zlib.org https://github.com/madler/zlib |
|
||||
| ddelta | BSD | 是 | https://github.com/julian-klode/ddelta |
|
||||
| dlg | BSL-1.0 | 否 | https://github.com/nyorain/dlg |
|
||||
| enet | MIT License | 否 | https://github.com/lsalzman/enet |
|
||||
| freetype | FreeType License | 是 | https://github.com/freetype/freetype |
|
||||
| googlebenchmark | Apache License 2.0 | 是 | https://github.com/google/benchmark |
|
||||
| googletest | BSD-3-Clause | 是 | https://google.github.io/googletest/ |
|
||||
| inipp | MIT License | 否 | https://github.com/mcmtroffaes/inipp |
|
||||
| iperf2 | MIT License | 否 | https://github.com/esnet/iperf |
|
||||
| iperf3 | MIT License | 是 | https://github.com/esnet/iperf |
|
||||
| json-c | BSD-3-Clause | 否 | https://github.com/json-c/json-c |
|
||||
| lc3 | Apache License 2.0 | 是 | https://www.bluetooth.com/specifications/specs/low-complexity-communication-codec-1-0/ |
|
||||
| libdivide | Zlib | 是 | https://github.com/ridiculousfish/libdivide |
|
||||
| libexpat | MIT License | 否 | https://github.com/libexpat/libexpat |
|
||||
| libfluoride-sbc | Apache License 2.0 | 否 | https://github.com/artem/libldac |
|
||||
| libpng | libpng-2.0 | 是 | https://github.com/pnggroup/libpng |
|
||||
| libtar | University of Illinois/NCSA Open Source License | 是 | https://repo.or.cz/w/libtar.git |
|
||||
| mbedtls | Apache License 2.0 | 是 | https://github.com/Mbed-TLS/mbedtls |
|
||||
| nanopb | Zlib | 否 | https://github.com/nanopb/nanopb |
|
||||
| Ne10 | BSD-3-Clause | 是 | https://github.com/projectNe10/Ne10 |
|
||||
| nghttp2 | MIT License | 否 | https://github.com/nghttp2/nghttp2 |
|
||||
| nng | MIT License | 是 | https://github.com/nanomsg/nng |
|
||||
| opus | BSD-3-Clause | 是 | https://opus-codec.org/ https://gitlab.xiph.org/xiph/opus |
|
||||
| protobuf-c | BSD-2-Clause | 否 | https://github.com/protobuf-c/protobuf-c |
|
||||
| quirc | ISC License | 是 | https://github.com/dlbeer/quirc |
|
||||
| rtos-benchmark | Apache License 2.0 | 是 | https://github.com/zephyrproject-rtos/rtos-benchmark |
|
||||
| thorvg | MIT License | 否 | https://github.com/thorvg/thorvg |
|
||||
| tinyxml2 | zlib License | 是 | https://github.com/leethomason/tinyxml2 |
|
||||
| unqlite | Apache License 2.0 | 是 | https://github.com/symisc/unqlite |
|
||||
| dhara | ISC License | 否 | https://github.com/dlbeer/dhara |
|
||||
| fatfs | FatFs License(BSD style) | 是 | http://elm-chan.org/fsw/ff/00index_e.html |
|
||||
| littlefs | BSD-3-Clause | 是 | https://github.com/littlefs-project/littlefs |
|
||||
| libsamplerate | BSD-2-Clause | 否 | https://github.com/libsndfile/libsamplerate |
|
||||
| openlibm | MIT License | 是 | https://github.com/JuliaMath/openlibm |
|
||||
| libcxx | Apache License 2.0 | 是 | https://github.com/llvm/llvm-project/tree/main/libcxx |
|
||||
| libcxxabi | MIT License | 是 | https://itanium-cxx-abi.github.io/cxx-abi |
|
||||
| tlsf | BSD | 否 | https://github.com/mattconte/tlsf |
|
||||
| libmetal | Apache License 2.0 | 是 | https://github.com/OpenAMP/libmetal |
|
||||
| open-amp | Apache License 2.0 | 是 | https://github.com/OpenAMP/open-amp |
|
||||
| apps | Apache License 2.0 | 是 | https://github.com/apache/nuttx-apps |
|
||||
| nuttx | Apache License 2.0 | 是 | https://github.com/apache/nuttx |
|
||||
| kmgk | Apache License 2.0 | 是 | https://github.com/linaro-swg/kmgk |
|
||||
| optee_client | BSD 2-clause | 是 | https://github.com/OP-TEE/optee_client |
|
||||
| optee_examples | BSD 2-clause | 否 | https://github.com/linaro-swg/optee_examples |
|
||||
| optee_os | BSD 2-Clause | 是 | https://github.com/OP-TEE/optee_os |
|
||||
| nist-sts | [License](https://unlicense.org/) | 是 | https://github.com/terrillmoore/NIST-Statistical-Test-Suite |
|
||||
| libtomcrypt | LibTom | 是 | https://github.com/libtom/libtomcrypt |
|
||||
| test-tlb | GPL-2.0 | 是 | https://github.com/torvalds/test-tlb |
|
||||
| tinycrypt | BSD 2-Clause | 是 | https://github.com/intel/tinycrypt |
|
||||
| unpv13e | [License](https://github.com/unpbook/unpv13e/blob/master/LICENSE) | 否 | https://github.com/unpbook/unpv13e |
|
||||
| wasm-micro-runtime | Apache License 2.0 | 是 | https://github.com/bytecodealliance/wasm-micro-runtime |
|
||||
| gemmlowp | Apache License 2.0 | 否 | https://github.com/google/gemmlowp |
|
||||
| kissfft | BSD-3-Clause | 否 | https://github.com/mborgerding/kissfft |
|
||||
| libtommath | LibTom | 否 | https://github.com/libtom/libtommath |
|
||||
| ruy | Apache License 2.0 | 否 | https://github.com/google/ruy |
|
||||
| CMSIS-NN | Apache License 2.0 | 否 | https://github.com/ARM-software/CMSIS-NN |
|
||||
| tflite-micro | Apache License 2.0 | 是 | https://github.com/tensorflow/tflite-micro |
|
||||
| connectedhomeip | Apache License 2.0 | 是 | https://github.com/project-chip/connectedhomeip |
|
||||
| nlassert | Apache License 2.0 | 否 | https://github.com/nestlabs/nlassert |
|
||||
| nlio | Apache License 2.0 | 否 | https://github.com/nestlabs/nlio |
|
||||
| nlunit-test | Apache License 2.0 | 否 | https://github.com/nestlabs/nlunit-test |
|
||||
| pigweed | Apache License 2.0 | 否 | https://github.com/google/pigweed |
|
||||
| jsoncpp | MIT License | 是 | https://github.com/open-source-parsers/jsoncpp |
|
||||
| flatbuffers | Apache License 2.0 | 否 | https://github.com/google/flatbuffers |
|
||||
| fff | MIT License | 否 | https://github.com/meekrosoft/fff |
|
||||
| libc-test | MIT License | 否 | https://github.com/AssemblyScript/libc-test |
|
||||
| ltp | GPL-2.0 | 是 | https://github.com/linux-test-project/ltp |
|
||||
| stressapptest | Apache License 2.0 | 是 | https://github.com/stressapptest/stressapptest |
|
||||
| abseil-cpp | Apache License 2.0 | 否 | https://github.com/abseil/abseil-cpp |
|
||||
| native | Apache License 2.0 | 是 | https://android.googlesource.com/platform/frameworks/native/ |
|
||||
| interfaces | Apache License 2.0 | 否 | https://android.googlesource.com/platform/hardware/interfaces/ |
|
||||
| libhardware | Apache License 2.0 | 否 | https://android.googlesource.com/platform/hardware/libhardware/ |
|
||||
| chre | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/chre/ |
|
||||
| core | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/core |
|
||||
| keymaster | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/keymaster |
|
||||
| libbase | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/libbase |
|
||||
| libcppbor | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/libcppbor |
|
||||
| libfmq | Apache License 2.0 | 否 | https://android.googlesource.com/platform/system/libfmq |
|
||||
| libhidl | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/libhidl |
|
||||
| libhwbinder | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/libhwbinder |
|
||||
| logging | Apache License 2.0 | 否 | https://android.googlesource.com/platform/system/logging |
|
||||
| security | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/security |
|
||||
| aidl | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/tools/aidl |
|
||||
| hidl | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/tools/hidl |
|
||||
| atomic_queue | MIT License | 是 | https://github.com/max0x7ba/atomic_queue |
|
||||
| auto-pts | GPL-2.0 | 是 | https://github.com/auto-pts/auto-pts |
|
||||
| c-ares | MIT License | 是 | https://github.com/c-ares/c-ares |
|
||||
| cmark-gfm | MIT License | 是 | https://github.com/github/cmark-gfm |
|
||||
| cpuid | ISC | 否 | https://github.com/tycho/cpuid |
|
||||
| dbus | GPL-2.0 | 是 | https://gitlab.freedesktop.org/dbus/dbus |
|
||||
| erpc | BSD-3-clause | 是 | https://github.com/EmbeddedRPC/erpc |
|
||||
| exfatprogs | GPL-2.0 | 是 | https://github.com/namjaejeon/exfatprogs |
|
||||
| fluoride | Apache License 2.0 | 是 | https://github.com/anchao/fluoride |
|
||||
| fmt | MIT License | 是 | https://github.com/fmtlib/fmt |
|
||||
| freetype | freetype license | 是 | https://gitlab.freedesktop.org/freetype/freetype |
|
||||
| dlg | Boost Software License - Version 1.0 | 否 | https://github.com/nyorain/dlg |
|
||||
| glib | LGPL-2.1 | 是 | https://github.com/GNOME/glib |
|
||||
| gvdb | LGPL-2.1 | 否 | https://github.com/GNOME/gvdb |
|
||||
| harfbuzz | "Old MIT" license | 否 | https://github.com/harfbuzz/harfbuzz |
|
||||
| ldns | Apache License 2.0 | 是 | https://github.com/NLnetLabs/ldns |
|
||||
| modp_b64 | BSD License | 否 | https://chromium.googlesource.com/chromium/src/third_party/modp_b64 |
|
||||
| libhelix-aac | Apache License 2.0 | 是 | https://github.com/pschatzmann/arduino-libhelix/tree/main/src/libhelix-aac |
|
||||
| libhelix-mp3 | Apache License 2.0 | 是 | https://github.com/pschatzmann/arduino-libhelix/tree/main/src/libhelix-mp3 |
|
||||
| libjpeg-turbo | libjpeg-turbo license | 是 | https://github.com/libjpeg-turbo/libjpeg-turbo |
|
||||
| libldac | Apache License 2.0 | 是 | https://android.googlesource.com/platform/external/libldac/ |
|
||||
| opencore-amr | Apache License 2.0 | 是 | https://sourceforge.net/projects/opencore-amr/ |
|
||||
| libssh-mirror | BSD 2-Clause | 是 | https://gitlab.com/libssh/libssh-mirror/ |
|
||||
| libtar | BSD | 是 | https://repo.or.cz/libtar.git |
|
||||
| libwebp | BSD-3-Clause license | 是 | https://chromium.googlesource.com/webm/libwebp |
|
||||
| lz4 | BSD | 是 | https://github.com/lz4/lz4 |
|
||||
| mdns | [License](https://github.com/mjansson/mdns/blob/main/LICENSE) | 是 | https://github.com/mjansson/mdns |
|
||||
| mmc-utils | GPL-2.0 | 是 | https://git.kernel.org/pub/scm/utils/mmc/mmc-utils.git |
|
||||
| mtp-responder | Apache License 2.0 | 是 | https://review.tizen.org/git/?p=framework/connectivity/mtp-responder.git |
|
||||
| ofono | GPL-2.0 license | 是 | https://github.com/ubports/ofono |
|
||||
| ell | LGPL-2.1 license | 是 | https://github.com/bryanperris/ell |
|
||||
| protobuf | [License](https://github.com/protocolbuffers/protobuf/blob/main/LICENSE) | 否 | https://github.com/protocolbuffers/protobuf |
|
||||
| rapidjson | MIT License | 是 | https://github.com/Tencent/rapidjson |
|
||||
| ril | Apache License 2.0 | 是 | https://android.googlesource.com/platform/hardware/ril/+/refs/tags/android-7.0.0_r7 |
|
||||
| rlottie | LGPL-v2.1 license | 否 | https://github.com/TelegramMessenger/rlottie |
|
||||
| silk-v3-decoder | Apache License 2.0 | 是 | https://github.com/kn007/silk-v3-decoder |
|
||||
| sqlite | BSD | 否 | https://github.com/sqlite/sqlite |
|
||||
| stress | GPL-2.0 | 是 | https://github.com/resurrecting-open-source-projects/stress |
|
||||
| sysklogd | GPL-2.0 | 是 | https://github.com/troglobit/sysklogd |
|
||||
| sil-kit | MIT License | 否 | https://github.com/vectorgrp/sil-kit |
|
||||
| sil-kit-adapters-qemu | MIT License | 否 | https://github.com/vectorgrp/sil-kit-adapters-qemu |
|
||||
| sil-kit-adapters-vcan | MIT License | 否 | https://github.com/vectorgrp/sil-kit-adapters-vcan |
|
||||
| yoga | MIT License | 否 | https://github.com/facebook/yoga |
|
||||
| zblue | Apache License 2.0 | 是 | https://github.com/zephyrproject-rtos/zephyr |
|
||||
| zint | GPL-3.0 | 否 | https://github.com/zint/zint |
|
||||
| nuttx | Apache License 2.0 | 是 | https://github.com/apache/nuttx |
|
||||
| SEGGER_SystemView | [License](https://github.com/RT-Thread-packages/SEGGER_SystemView/blob/master/SystemView_Src/License_SystemView.txt) | 否 | https://github.com/RT-Thread-packages/SEGGER_SystemView |
|
||||
| dtc | GPL-2.0 | 否 | https://github.com/dgibson/dtc |
|
||||
| libmcs | SPDX | 否 | https://gitlab.com/gtd-gmbh/libmcs |
|
||||
| newlib | LGPL | 否 | https://sourceware.org/pub/newlib |
|
||||
| libstdc++ | GPL-2.0 | 否 | https://github.com/gcc-mirror/gcc/tree/master/libstdc%2B%2B-v3/libsupc%2B%2B |
|
||||
| uClibc++ | LGPL-2.1 | 否 | [https://cxx.uclibc.org/src/](https://git.busybox.net/uClibc++) |
|
||||
| tlsf | BSD | 是 | https://github.com/mattconte/tlsf |
|
||||
| X-TRACK | MIT License | 否 | https://github.com/FASTSHIFT/X-TRACK |
|
||||
| wamr | Apache License 2.0 | 否 | https://github.com/bytecodealliance/wasm-micro-runtime |
|
||||
| libopencore-amr | Apache License 2.0 | 是 | https://github.com/BelledonneCommunications/opencore-amr/blob/master |
|
||||
| kconfig-frontends | GPL-2.0 | 是 | https://bitbucket.org/nuttx/tools/src/master/kconfig-frontends/ |
|
||||
| FFmpeg | LGPL v2.1+ | 是 | https://github.com/FFmpeg/FFmpeg.git |
|
||||
|
|
|
|||
|
|
@ -1,164 +0,0 @@
|
|||
| **套件** | **授權** | **是否有修改** | **開源程式碼位址** |
|
||||
| --------------------- | ------------------ | -------------- | ------------------------------------------------------------ |
|
||||
| libsodium | ISC License | 否 | https://github.com/jedisct1/libsodium |
|
||||
| minmea | MIT License | 是 | https://github.com/kosma/minmea |
|
||||
| libyuv | BSD-3-Clause | 否 | https://chromium.googlesource.com/libyuv |
|
||||
| lvgl | MIT License | 是 | https://github.com/lvgl/lvgl |
|
||||
| lua | MIT License | 否 | https://github.com/lua/lua |
|
||||
| cJSON | MIT License | 是 | https://github.com/DaveGamble/cJSON |
|
||||
| MQTT-C | MIT License | 否 | https://github.com/LiamBindle/MQTT-C |
|
||||
| microADB | Apache License 2.0 | 是 | https://github.com/spiriou/microADB |
|
||||
| argtable3 | BSD-3-Clause | 否 | https://github.com/argtable/argtable3 |
|
||||
| libuv | MIT License | 是 | https://github.com/libuv/libuv |
|
||||
| Unity | MIT License | 否 | https://github.com/ThrowTheSwitch/Unity |
|
||||
| aac | Fraunhofer FDK AAC License | 是 | https://github.com/mstorsjo/fdk-aac |
|
||||
| avb | Apache License 2.0 | 是 | https://android.googlesource.com/platform/external/avb/ |
|
||||
| bzip2 | BSD | 否 | https://sourceware.org/bzip2/ |
|
||||
| cAT | MIT License | 是 | https://github.com/marcinbor85/cAT |
|
||||
| Chipmunk2D | MIT License | 是 | http://chipmunk2d.net https://github.com/slembcke/Chipmunk2D |
|
||||
| cmocka | Apache License 2.0 | 是 | https://gitlab.com/cmocka/cmocka |
|
||||
| cmsis | Apache License 2.0 | 是 | https://github.com/ARM-software/CMSIS_5 |
|
||||
| coremark | Apache License 2.0 | 是 | https://github.com/eembc/coremark |
|
||||
| curl | MIT License | 是 | https://curl.se https://github.com/curl/curl |
|
||||
| zlib | Zlib | 是 | http://www.zlib.org https://github.com/madler/zlib |
|
||||
| ddelta | BSD | 是 | https://github.com/julian-klode/ddelta |
|
||||
| dlg | BSL-1.0 | 否 | https://github.com/nyorain/dlg |
|
||||
| enet | MIT License | 否 | https://github.com/lsalzman/enet |
|
||||
| freetype | FreeType License | 是 | https://github.com/freetype/freetype |
|
||||
| googlebenchmark | Apache License 2.0 | 是 | https://github.com/google/benchmark |
|
||||
| googletest | BSD-3-Clause | 是 | https://google.github.io/googletest/ |
|
||||
| inipp | MIT License | 否 | https://github.com/mcmtroffaes/inipp |
|
||||
| iperf2 | MIT License | 否 | https://github.com/esnet/iperf |
|
||||
| iperf3 | MIT License | 是 | https://github.com/esnet/iperf |
|
||||
| json-c | BSD-3-Clause | 否 | https://github.com/json-c/json-c |
|
||||
| lc3 | Apache License 2.0 | 是 | https://www.bluetooth.com/specifications/specs/low-complexity-communication-codec-1-0/ |
|
||||
| libdivide | Zlib | 是 | https://github.com/ridiculousfish/libdivide |
|
||||
| libexpat | MIT License | 否 | https://github.com/libexpat/libexpat |
|
||||
| libfluoride-sbc | Apache License 2.0 | 否 | https://github.com/artem/libldac |
|
||||
| libpng | libpng-2.0 | 是 | https://github.com/pnggroup/libpng |
|
||||
| libtar | University of Illinois/NCSA Open Source License | 是 | https://repo.or.cz/w/libtar.git |
|
||||
| mbedtls | Apache License 2.0 | 是 | https://github.com/Mbed-TLS/mbedtls |
|
||||
| nanopb | Zlib | 否 | https://github.com/nanopb/nanopb |
|
||||
| Ne10 | BSD-3-Clause | 是 | https://github.com/projectNe10/Ne10 |
|
||||
| nghttp2 | MIT License | 否 | https://github.com/nghttp2/nghttp2 |
|
||||
| nng | MIT License | 是 | https://github.com/nanomsg/nng |
|
||||
| opus | BSD-3-Clause | 是 | https://opus-codec.org/ https://gitlab.xiph.org/xiph/opus |
|
||||
| protobuf-c | BSD-2-Clause | 否 | https://github.com/protobuf-c/protobuf-c |
|
||||
| quirc | ISC License | 是 | https://github.com/dlbeer/quirc |
|
||||
| rtos-benchmark | Apache License 2.0 | 是 | https://github.com/zephyrproject-rtos/rtos-benchmark |
|
||||
| thorvg | MIT License | 否 | https://github.com/thorvg/thorvg |
|
||||
| tinyxml2 | zlib License | 是 | https://github.com/leethomason/tinyxml2 |
|
||||
| unqlite | Apache License 2.0 | 是 | https://github.com/symisc/unqlite |
|
||||
| dhara | ISC License | 否 | https://github.com/dlbeer/dhara |
|
||||
| fatfs | FatFs License(BSD style) | 是 | http://elm-chan.org/fsw/ff/00index_e.html |
|
||||
| littlefs | BSD-3-Clause | 是 | https://github.com/littlefs-project/littlefs |
|
||||
| libsamplerate | BSD-2-Clause | 否 | https://github.com/libsndfile/libsamplerate |
|
||||
| openlibm | MIT License | 是 | https://github.com/JuliaMath/openlibm |
|
||||
| libcxx | Apache License 2.0 | 是 | https://github.com/llvm/llvm-project/tree/main/libcxx |
|
||||
| libcxxabi | MIT License | 是 | https://itanium-cxx-abi.github.io/cxx-abi |
|
||||
| tlsf | BSD | 否 | https://github.com/mattconte/tlsf |
|
||||
| libmetal | Apache License 2.0 | 是 | https://github.com/OpenAMP/libmetal |
|
||||
| open-amp | Apache License 2.0 | 是 | https://github.com/OpenAMP/open-amp |
|
||||
| apps | Apache License 2.0 | 是 | https://github.com/apache/nuttx-apps |
|
||||
| nuttx | Apache License 2.0 | 是 | https://github.com/apache/nuttx |
|
||||
| kmgk | Apache License 2.0 | 是 | https://github.com/linaro-swg/kmgk |
|
||||
| optee_client | BSD 2-clause | 是 | https://github.com/OP-TEE/optee_client |
|
||||
| optee_examples | BSD 2-clause | 否 | https://github.com/linaro-swg/optee_examples |
|
||||
| optee_os | BSD 2-Clause | 是 | https://github.com/OP-TEE/optee_os |
|
||||
| nist-sts | [License](https://unlicense.org/) | 是 | https://github.com/terrillmoore/NIST-Statistical-Test-Suite |
|
||||
| libtomcrypt | LibTom | 是 | https://github.com/libtom/libtomcrypt |
|
||||
| test-tlb | GPL-2.0 | 是 | https://github.com/torvalds/test-tlb |
|
||||
| tinycrypt | BSD 2-Clause | 是 | https://github.com/intel/tinycrypt |
|
||||
| unpv13e | [License](https://github.com/unpbook/unpv13e/blob/master/LICENSE) | 否 | https://github.com/unpbook/unpv13e |
|
||||
| wasm-micro-runtime | Apache License 2.0 | 是 | https://github.com/bytecodealliance/wasm-micro-runtime |
|
||||
| gemmlowp | Apache License 2.0 | 否 | https://github.com/google/gemmlowp |
|
||||
| kissfft | BSD-3-Clause | 否 | https://github.com/mborgerding/kissfft |
|
||||
| libtommath | LibTom | 否 | https://github.com/libtom/libtommath |
|
||||
| ruy | Apache License 2.0 | 否 | https://github.com/google/ruy |
|
||||
| CMSIS-NN | Apache License 2.0 | 否 | https://github.com/ARM-software/CMSIS-NN |
|
||||
| tflite-micro | Apache License 2.0 | 是 | https://github.com/tensorflow/tflite-micro |
|
||||
| connectedhomeip | Apache License 2.0 | 是 | https://github.com/project-chip/connectedhomeip |
|
||||
| nlassert | Apache License 2.0 | 否 | https://github.com/nestlabs/nlassert |
|
||||
| nlio | Apache License 2.0 | 否 | https://github.com/nestlabs/nlio |
|
||||
| nlunit-test | Apache License 2.0 | 否 | https://github.com/nestlabs/nlunit-test |
|
||||
| pigweed | Apache License 2.0 | 否 | https://github.com/google/pigweed |
|
||||
| jsoncpp | MIT License | 是 | https://github.com/open-source-parsers/jsoncpp |
|
||||
| flatbuffers | Apache License 2.0 | 否 | https://github.com/google/flatbuffers |
|
||||
| fff | MIT License | 否 | https://github.com/meekrosoft/fff |
|
||||
| libc-test | MIT License | 否 | https://github.com/AssemblyScript/libc-test |
|
||||
| ltp | GPL-2.0 | 是 | https://github.com/linux-test-project/ltp |
|
||||
| stressapptest | Apache License 2.0 | 是 | https://github.com/stressapptest/stressapptest |
|
||||
| abseil-cpp | Apache License 2.0 | 否 | https://github.com/abseil/abseil-cpp |
|
||||
| native | Apache License 2.0 | 是 | https://android.googlesource.com/platform/frameworks/native/ |
|
||||
| interfaces | Apache License 2.0 | 否 | https://android.googlesource.com/platform/hardware/interfaces/ |
|
||||
| libhardware | Apache License 2.0 | 否 | https://android.googlesource.com/platform/hardware/libhardware/ |
|
||||
| chre | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/chre/ |
|
||||
| core | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/core |
|
||||
| keymaster | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/keymaster |
|
||||
| libbase | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/libbase |
|
||||
| libcppbor | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/libcppbor |
|
||||
| libfmq | Apache License 2.0 | 否 | https://android.googlesource.com/platform/system/libfmq |
|
||||
| libhidl | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/libhidl |
|
||||
| libhwbinder | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/libhwbinder |
|
||||
| logging | Apache License 2.0 | 否 | https://android.googlesource.com/platform/system/logging |
|
||||
| security | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/security |
|
||||
| aidl | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/tools/aidl |
|
||||
| hidl | Apache License 2.0 | 是 | https://android.googlesource.com/platform/system/tools/hidl |
|
||||
| atomic_queue | MIT License | 是 | https://github.com/max0x7ba/atomic_queue |
|
||||
| auto-pts | GPL-2.0 | 是 | https://github.com/auto-pts/auto-pts |
|
||||
| c-ares | MIT License | 是 | https://github.com/c-ares/c-ares |
|
||||
| cmark-gfm | MIT License | 是 | https://github.com/github/cmark-gfm |
|
||||
| cpuid | ISC | 否 | https://github.com/tycho/cpuid |
|
||||
| dbus | GPL-2.0 | 是 | https://gitlab.freedesktop.org/dbus/dbus |
|
||||
| erpc | BSD-3-clause | 是 | https://github.com/EmbeddedRPC/erpc |
|
||||
| exfatprogs | GPL-2.0 | 是 | https://github.com/namjaejeon/exfatprogs |
|
||||
| fluoride | Apache License 2.0 | 是 | https://github.com/anchao/fluoride |
|
||||
| fmt | MIT License | 是 | https://github.com/fmtlib/fmt |
|
||||
| freetype | freetype license | 是 | https://gitlab.freedesktop.org/freetype/freetype |
|
||||
| dlg | Boost Software License - Version 1.0 | 否 | https://github.com/nyorain/dlg |
|
||||
| glib | LGPL-2.1 | 是 | https://github.com/GNOME/glib |
|
||||
| gvdb | LGPL-2.1 | 否 | https://github.com/GNOME/gvdb |
|
||||
| harfbuzz | "Old MIT" license | 否 | https://github.com/harfbuzz/harfbuzz |
|
||||
| ldns | Apache License 2.0 | 是 | https://github.com/NLnetLabs/ldns |
|
||||
| modp_b64 | BSD License | 否 | https://chromium.googlesource.com/chromium/src/third_party/modp_b64 |
|
||||
| libhelix-aac | Apache License 2.0 | 是 | https://github.com/pschatzmann/arduino-libhelix/tree/main/src/libhelix-aac |
|
||||
| libhelix-mp3 | Apache License 2.0 | 是 | https://github.com/pschatzmann/arduino-libhelix/tree/main/src/libhelix-mp3 |
|
||||
| libjpeg-turbo | libjpeg-turbo license | 是 | https://github.com/libjpeg-turbo/libjpeg-turbo |
|
||||
| libldac | Apache License 2.0 | 是 | https://android.googlesource.com/platform/external/libldac/ |
|
||||
| opencore-amr | Apache License 2.0 | 是 | https://sourceforge.net/projects/opencore-amr/ |
|
||||
| libssh-mirror | BSD 2-Clause | 是 | https://gitlab.com/libssh/libssh-mirror/ |
|
||||
| libtar | BSD | 是 | https://repo.or.cz/libtar.git |
|
||||
| libwebp | BSD-3-Clause license | 是 | https://chromium.googlesource.com/webm/libwebp |
|
||||
| lz4 | BSD | 是 | https://github.com/lz4/lz4 |
|
||||
| mdns | [License](https://github.com/mjansson/mdns/blob/main/LICENSE) | 是 | https://github.com/mjansson/mdns |
|
||||
| mmc-utils | GPL-2.0 | 是 | https://git.kernel.org/pub/scm/utils/mmc/mmc-utils.git |
|
||||
| mtp-responder | Apache License 2.0 | 是 | https://review.tizen.org/git/?p=framework/connectivity/mtp-responder.git |
|
||||
| ofono | GPL-2.0 license | 是 | https://github.com/ubports/ofono |
|
||||
| ell | LGPL-2.1 license | 是 | https://github.com/bryanperris/ell |
|
||||
| protobuf | [License](https://github.com/protocolbuffers/protobuf/blob/main/LICENSE) | 否 | https://github.com/protocolbuffers/protobuf |
|
||||
| rapidjson | MIT License | 是 | https://github.com/Tencent/rapidjson |
|
||||
| ril | Apache License 2.0 | 是 | https://android.googlesource.com/platform/hardware/ril/+/refs/tags/android-7.0.0_r7 |
|
||||
| rlottie | LGPL-v2.1 license | 否 | https://github.com/TelegramMessenger/rlottie |
|
||||
| silk-v3-decoder | Apache License 2.0 | 是 | https://github.com/kn007/silk-v3-decoder |
|
||||
| sqlite | BSD | 否 | https://github.com/sqlite/sqlite |
|
||||
| stress | GPL-2.0 | 是 | https://github.com/resurrecting-open-source-projects/stress |
|
||||
| sysklogd | GPL-2.0 | 是 | https://github.com/troglobit/sysklogd |
|
||||
| sil-kit | MIT License | 否 | https://github.com/vectorgrp/sil-kit |
|
||||
| sil-kit-adapters-qemu | MIT License | 否 | https://github.com/vectorgrp/sil-kit-adapters-qemu |
|
||||
| sil-kit-adapters-vcan | MIT License | 否 | https://github.com/vectorgrp/sil-kit-adapters-vcan |
|
||||
| yoga | MIT License | 否 | https://github.com/facebook/yoga |
|
||||
| zblue | Apache License 2.0 | 是 | https://github.com/zephyrproject-rtos/zephyr |
|
||||
| zint | GPL-3.0 | 否 | https://github.com/zint/zint |
|
||||
| nuttx | Apache License 2.0 | 是 | https://github.com/apache/nuttx |
|
||||
| SEGGER_SystemView | [License](https://github.com/RT-Thread-packages/SEGGER_SystemView/blob/master/SystemView_Src/License_SystemView.txt) | 否 | https://github.com/RT-Thread-packages/SEGGER_SystemView |
|
||||
| dtc | GPL-2.0 | 否 | https://github.com/dgibson/dtc |
|
||||
| libmcs | SPDX | 否 | https://gitlab.com/gtd-gmbh/libmcs |
|
||||
| newlib | LGPL | 否 | https://sourceware.org/pub/newlib |
|
||||
| libstdc++ | GPL-2.0 | 否 | https://github.com/gcc-mirror/gcc/tree/master/libstdc%2B%2B-v3/libsupc%2B%2B |
|
||||
| uClibc++ | LGPL-2.1 | 否 | [https://cxx.uclibc.org/src/](https://git.busybox.net/uClibc++) |
|
||||
| tlsf | BSD | 是 | https://github.com/mattconte/tlsf |
|
||||
| X-TRACK | MIT License | 否 | https://github.com/FASTSHIFT/X-TRACK |
|
||||
| wamr | Apache License 2.0 | 否 | https://github.com/bytecodealliance/wasm-micro-runtime |
|
||||
| libopencore-amr | Apache License 2.0 | 是 | https://github.com/BelledonneCommunications/opencore-amr/blob/master |
|
||||
| kconfig-frontends | GPL-2.0 | 是 | https://bitbucket.org/nuttx/tools/src/master/kconfig-frontends/ |
|
||||
| FFmpeg | LGPL v2.1+ | 是 | https://github.com/FFmpeg/FFmpeg.git |
|
||||
|
|
@ -0,0 +1,695 @@
|
|||
# Developing an openvela UI Application
|
||||
|
||||
[ English | [简体中文](../../../zh-cn/app_dev/system_apps/Dev_UI_App.md) ]
|
||||
|
||||
## I. Prerequisites
|
||||
|
||||
1. Download the source code. Please refer to [Quick Start](./../../quickstart/openvela_ubuntu_quick_start.md).
|
||||
2. Before starting this tutorial, please obtain the example code from [music_player](../../../../../../packages_demos/tree/trunk-5.5/music_player).
|
||||
|
||||
## II. Preliminary Concepts
|
||||
|
||||
Before starting the tutorial, it is recommended to familiarize yourself with the following basic knowledge and tools to successfully complete the related development tasks:
|
||||
|
||||
1. **Makefile**: Understand the basic concepts and usage of Makefile. Makefile is the configuration file used by the build automation tool `make`, commonly used to define project compilation rules and dependency management.
|
||||
|
||||
2. **Kconfig**: Learn the basic principles and usages of Kconfig. Kconfig is a commonly used configuration system in Linux kernel and embedded development, helping developers flexibly define and choose software configuration options.
|
||||
|
||||
3. **LVGL**: Learn to use the LVGL embedded graphics library. LVGL is an open-source embedded graphics library widely used for developing high-performance user interfaces. Relevant documentation can be found in the [LVGL Official Documentation](https://docs.lvgl.io/).
|
||||
Understanding these concepts will help you complete the development tasks in the tutorial more efficiently.
|
||||
|
||||
## III. Introduction
|
||||
|
||||
This article describes how to write a simple music player in Openvela.
|
||||
|
||||
## IV. Project Structure
|
||||
|
||||
The project's code and resources are neatly organized in various directories and modules for efficient management and development. Below is the directory structure and file composition description of the `music_player` project.
|
||||
|
||||
### 1. Directory StructureThe core directory and file structure of the project is as follows:
|
||||
|
||||
```C++
|
||||
packages/demos/music_player
|
||||
├── res
|
||||
│ ├── fonts
|
||||
│ │ ├── MiSans-Normal.ttf
|
||||
│ │ └── MiSans-Semibold.ttf
|
||||
│ ├── icons
|
||||
│ │ ├── album_picture.png
|
||||
│ │ ├── audio.png
|
||||
│ │ ├── music.png
|
||||
│ │ ├── mute.png
|
||||
│ │ ├── next.png
|
||||
│ │ ├── nocover.png
|
||||
│ │ ├── pause.png
|
||||
│ │ ├── play.png
|
||||
│ │ ├── playlist.png
|
||||
│ │ └── previous.png
|
||||
│ ├── musics
|
||||
│ │ ├── manifest.json
|
||||
│ │ ├── UnamedRhythm.png
|
||||
│ │ └── UnamedRhythm.wav
|
||||
│ └── config.json
|
||||
├── audio_ctl.c
|
||||
├── audio_ctl.h
|
||||
├── Kconfig
|
||||
├── Make.defs
|
||||
├── Makefile
|
||||
├── music_player.c
|
||||
├── music_player.h
|
||||
├── music_player_main.c
|
||||
├── wifi.c
|
||||
└── wifi.h
|
||||
```
|
||||
|
||||
### 2. File Composition
|
||||
|
||||
The roles of each directory and file are as follows:
|
||||
|
||||
1. `res`:
|
||||
|
||||
Resource directory: containing the static resource files required for the project to run:
|
||||
|
||||
- `fonts`: Font file directory, containing the fonts used by the application.
|
||||
- `icons`: Icon file directory, containing various icons for interface display.
|
||||
- `musics`: Music resource directory, containing audio files and their corresponding configuration information.
|
||||
- `config.json`: Global configuration file, which stores the project’s configuration parameters.
|
||||
|
||||
2. `audio_ctl.c`/`audio_ctl.h`
|
||||
|
||||
Audio control module, responsible for implementing audio-related functions, including audio input, output, and volume adjustment operations.
|
||||
|
||||
3. `wifi.c`/`wifi.h`
|
||||
|
||||
Wi-Fi control module, responsible for implementing Wi-Fi connection management, initialization, and other functionalities.
|
||||
|
||||
4. `music_player.c`/`music_player.h`
|
||||
|
||||
Core logic of the music player, defining and implementing the main functionalities of music playback.
|
||||
|
||||
5. `music_player_main.c`
|
||||
|
||||
Main entry file of the program, responsible for initializing the music player and starting the main operational logic.
|
||||
|
||||
6. `Kconfig`, `Make.defs`, `Makefile` build system files:
|
||||
|
||||
- `Kconfig`: Defines the configuration information and build options for the project.
|
||||
- `Make.defs`: Definitions of compilation-related variables and dependency rules.
|
||||
- `Makefile`: Defines the build process and dependency management for the project.
|
||||
|
||||
## V. UI Application Development
|
||||
|
||||
### 1. Overview of UI Structure
|
||||
|
||||
The goal is to create a music player interface like this.
|
||||
|
||||

|
||||
|
||||
The user interface (UI) of the music player is organized into multiple modules in a grouped manner. Below is the complete hierarchy of the UI structure:
|
||||
|
||||
```C++
|
||||
TIME GROUP:
|
||||
TIME: 00:00:00
|
||||
DATE: 2024/03/21
|
||||
|
||||
PLAYER GROUP:
|
||||
ALBUM GROUP:
|
||||
ALBUM PICTURE
|
||||
ALBUM INFO:
|
||||
ALBUM NAME
|
||||
ALBUM ARTIST
|
||||
PROGRESS GROUP:
|
||||
CURRENT TIME: 00:00/00:00
|
||||
PLAYBACK PROGRESS BAR
|
||||
CONTROL GROUP:
|
||||
PLAYLIST
|
||||
PREVIOUS
|
||||
PLAY/PAUSE
|
||||
NEXT
|
||||
AUDIO
|
||||
|
||||
TOP Layer:
|
||||
VOLUME BAR
|
||||
PLAYLIST GROUP:
|
||||
TITLE
|
||||
LIST:
|
||||
ICON
|
||||
ALBUM NAME
|
||||
ALBUM ARTIST
|
||||
```
|
||||
|
||||
- TIME GROUP: Time display area.
|
||||
- PLAYER GROUP: Player core area.
|
||||
- ALBUM GROUP: Album information area.
|
||||
- PROGRESS GROUP: Playback progress area.
|
||||
- CONTROL GROUP: Playback control area.
|
||||
- TOP Layer: Top interface.
|
||||
- VOLUME BAR: Volume control bar.
|
||||
- PLAYLIST GROUP: Playlist area.
|
||||
|
||||
### 2. Data Structure Design
|
||||
|
||||
#### In-App Configuration
|
||||
|
||||
In-app configuration is primarily used to initialize necessary environment parameters, such as Wi-Fi network settings. It is important to note that sensitive information, like the Wi-Fi `ssid` (Service Set Identifier) and `psk` (Pre-Shared Key), should not be stored in plaintext. It is recommended to load them using secure methods, such as environment variables or external configuration files.
|
||||
|
||||
```cpp
|
||||
struct conf_s {
|
||||
#if WIFI_ENABLED
|
||||
wifi_conf_t wifi;
|
||||
#endif
|
||||
};
|
||||
```
|
||||
|
||||
- If the Wi-Fi feature is enabled (via the `WIFI_ENABLED` macro), it will allow the configuration of the Wi-Fi `ssid` and `psk`.
|
||||
- Avoid hard-coding the `ssid` and `psk` in the source code. Ensure that sensitive information is configured by referencing external encrypted storage or a dynamic loading mechanism.
|
||||
|
||||
#### Runtime State
|
||||
|
||||
Runtime state data represents the dynamic content of the application, primarily recording playback control and album information. The relevant data structures are designed as follows:
|
||||
|
||||
- Album (`album_info_t`) information.
|
||||
- Album switching mode (`switch_album_mode_t`).
|
||||
- Playback status (`play_status_t`).
|
||||
|
||||
```c
|
||||
// Album information
|
||||
typedef struct _album_info_t {
|
||||
const char* name; // Album name
|
||||
const char* artist; // Artist
|
||||
char path[LV_FS_MAX_PATH_LENGTH]; // Audio file path
|
||||
char cover[LV_FS_MAX_PATH_LENGTH]; // Album cover path
|
||||
uint64_t total_time; // Total duration (in milliseconds)
|
||||
lv_color_t color; // Album theme color
|
||||
} album_info_t;
|
||||
|
||||
// Album switching mode
|
||||
typedef enum _switch_album_mode_t {
|
||||
SWITCH_ALBUM_MODE_PREV, // Switch to the previous album
|
||||
SWITCH_ALBUM_MODE_NEXT, // Switch to the next album
|
||||
} switch_album_mode_t;
|
||||
|
||||
// Playback status
|
||||
typedef enum _play_status_t {
|
||||
PLAY_STATUS_STOP, // Playback stopped
|
||||
PLAY_STATUS_PLAY, // Playing
|
||||
PLAY_STATUS_PAUSE, // Playback paused
|
||||
} play_status_t;
|
||||
|
||||
// Player runtime state information
|
||||
struct ctx_s {
|
||||
bool resource_healthy_check; // System resource health check
|
||||
album_info_t* current_album; // Information of the currently playing album
|
||||
lv_obj_t* current_album_related_obj; // UI object associated with the album
|
||||
|
||||
uint16_t volume; // Current volume
|
||||
|
||||
play_status_t play_status_prev; // Previous playback status
|
||||
play_status_t play_status; // Current playback status
|
||||
uint64_t current_time; // Current playback time
|
||||
|
||||
struct {
|
||||
lv_timer_t* volume_bar_countdown; // Timer for auto-hiding the volume bar
|
||||
lv_timer_t* playback_progress_update; // Timer for updating playback progress
|
||||
} timers;
|
||||
|
||||
audioctl_s* audioctl; // Audio control handle for audio operations
|
||||
};
|
||||
```
|
||||
|
||||
#### Component Tree Structure
|
||||
|
||||
Based on the UI structure and its grouping design, the `resource_s` data structure will contain all UI controls, fonts, styles, and image resources.
|
||||
|
||||
```cpp
|
||||
struct resource_s {
|
||||
struct {
|
||||
lv_obj_t* time; // Time display
|
||||
lv_obj_t* date; // Date display
|
||||
lv_obj_t* player_group; // Player container
|
||||
|
||||
lv_obj_t* volume_bar; // Volume bar
|
||||
lv_obj_t* volume_bar_indic; // Volume indicator
|
||||
lv_obj_t* audio; // Audio object
|
||||
lv_obj_t* playlist_base; // Playlist base area
|
||||
|
||||
lv_obj_t* album_cover; // Album cover
|
||||
lv_obj_t* album_name; // Album name
|
||||
lv_obj_t* album_artist; // Artist name
|
||||
|
||||
lv_obj_t* play_btn; // Play button
|
||||
lv_obj_t* playback_group; // Playback progress container
|
||||
lv_obj_t* playback_progress; // Playback progress bar
|
||||
lv_span_t* playback_current_time; // Current playback time
|
||||
lv_span_t* playback_total_time; // Total duration
|
||||
|
||||
lv_obj_t* playlist; // Playlist object
|
||||
} ui;
|
||||
|
||||
struct {
|
||||
struct { lv_font_t* normal; } size_16;
|
||||
struct { lv_font_t* bold; } size_22;
|
||||
struct { lv_font_t* normal; } size_24;
|
||||
struct { lv_font_t* normal; } size_28;
|
||||
struct { lv_font_t* bold; } size_60;
|
||||
} fonts;
|
||||
|
||||
struct {
|
||||
lv_style_t button_default; // Default button style
|
||||
lv_style_t button_pressed; // Pressed button style
|
||||
lv_style_transition_dsc_t button_transition_dsc; // Button transition effect
|
||||
lv_style_transition_dsc_t transition_dsc; // General transition effect
|
||||
} styles;
|
||||
|
||||
struct {
|
||||
const char* playlist; // Playlist icon path
|
||||
const char* previous; // Previous icon path
|
||||
const char* play; // Play icon path
|
||||
const char* pause; // Pause icon path
|
||||
const char* next; // Next icon path
|
||||
const char* audio; // Audio icon path
|
||||
const char* mute; // Mute icon path
|
||||
const char* music; // Music icon path
|
||||
const char* nocover; // Placeholder icon for no cover
|
||||
} images;
|
||||
|
||||
album_info_t* albums; // All album information
|
||||
uint8_t album_count; // Number of albums
|
||||
};
|
||||
```
|
||||
|
||||
Component Tree Structure Description:
|
||||
|
||||
- `ui` module: Defines the properties and hierarchy of all interface controls.
|
||||
- `fonts` module: Sets fonts of different sizes and weights.
|
||||
- `styles` module: Encapsulates button effects and styles.
|
||||
- `images` module: Manages image resources centrally for easy dynamic loading.
|
||||
|
||||
### 3. Business Logic Design
|
||||
|
||||
#### Main Startup Flow
|
||||
|
||||

|
||||
|
||||
The `app_create` function is the initialization entry point for the music player application. It is responsible for the following tasks:
|
||||
|
||||
- Initialize the resource and runtime context structures.
|
||||
- Load configuration files.
|
||||
- Perform component initializations (e.g., resource health check, Wi-Fi connection).
|
||||
- Create the main interface and set the default state.
|
||||
- Start necessary background tasks (e.g., date and time update).
|
||||
|
||||
Below is the complete implementation and analysis of `app_create`:
|
||||
|
||||
```cpp
|
||||
void app_create(void)
|
||||
{
|
||||
// Initialize resource, context, and config structures
|
||||
lv_memzero(&R, sizeof(R)); // Clear the Resource struct
|
||||
lv_memzero(&C, sizeof(C)); // Clear the runtime Context struct
|
||||
lv_memzero(&CF, sizeof(CF)); // Clear the Config struct
|
||||
read_configs(); // Read the application's configuration files
|
||||
|
||||
#if WIFI_ENABLED
|
||||
CF.wifi.conn_delay = 2000000; // Set Wi-Fi delay (unit: microseconds, 2 seconds)
|
||||
wifi_connect(&CF.wifi); // Connect to Wi-Fi
|
||||
#endif
|
||||
|
||||
C.resource_healthy_check = init_resource(); // Check and initialize resources
|
||||
|
||||
if (!C.resource_healthy_check) { // If resource check fails
|
||||
app_create_error_page(); // Create an error page to notify the user
|
||||
return;
|
||||
}
|
||||
|
||||
app_create_main_page(); // Create the main page
|
||||
app_set_play_status(PLAY_STATUS_STOP); // Set the initial play status to "Stopped"
|
||||
app_switch_to_album(0); // Switch to the first album
|
||||
app_set_volume(30); // Set the default volume to 30
|
||||
|
||||
app_refresh_album_info(); // Update the album info display
|
||||
app_refresh_playlist(); // Update the playlist display
|
||||
app_refresh_volume_bar(); // Update the volume bar display
|
||||
|
||||
app_start_updating_date_time(); // Start the date and time update task
|
||||
}
|
||||
```
|
||||
|
||||
#### Runtime State Machine
|
||||
|
||||

|
||||
|
||||
`app_refresh_play_status` is the core function of the music player's runtime state machine. Its main purpose is to update the UI and the audio controller's state based on the playback status (`PLAY_STATUS_STOP`, `PLAY_STATUS_PLAY`, and `PLAY_STATUS_PAUSE`), thereby handling functions like play, pause, and stop. The following is the complete function and a step-by-step explanation of its key logic:
|
||||
|
||||
```cpp
|
||||
static void app_refresh_play_status(void)
|
||||
{
|
||||
if (C.timers.playback_progress_update == NULL) {
|
||||
C.timers.playback_progress_update = lv_timer_create(app_playback_progress_update_timer_cb, 1000, NULL);
|
||||
}
|
||||
switch (C.play_status) {
|
||||
case PLAY_STATUS_STOP:
|
||||
// Handle stop status
|
||||
lv_image_set_src(R.ui.play_btn, R.images.play); // Update play button icon to "play"
|
||||
lv_timer_pause(C.timers.playback_progress_update); // Pause the timer
|
||||
if (C.audioctl) {
|
||||
audio_ctl_stop(C.audioctl); // Stop audio playback
|
||||
audio_ctl_uninit_nxaudio(C.audioctl); // Deinitialize audio controller resources
|
||||
C.audioctl = NULL; // Clear the audio controller handle
|
||||
}
|
||||
break;
|
||||
|
||||
case PLAY_STATUS_PLAY:
|
||||
// Handle play status
|
||||
lv_image_set_src(R.ui.play_btn, R.images.pause); // Update play button icon to "pause"
|
||||
lv_timer_resume(C.timers.playback_progress_update); // Resume the timer
|
||||
if (C.play_status_prev == PLAY_STATUS_PAUSE) {
|
||||
audio_ctl_resume(C.audioctl); // Resume audio playback
|
||||
} else if (C.play_status_prev == PLAY_STATUS_STOP) {
|
||||
C.audioctl = audio_ctl_init_nxaudio(C.current_album->path); // Initialize the audio controller
|
||||
audio_ctl_start(C.audioctl); // Start playing audio
|
||||
}
|
||||
break;
|
||||
|
||||
case PLAY_STATUS_PAUSE:
|
||||
// Handle pause status
|
||||
lv_image_set_src(R.ui.play_btn, R.images.play); // Update play button icon to "play"
|
||||
lv_timer_pause(C.timers.playback_progress_update); // Pause the timer
|
||||
audio_ctl_pause(C.audioctl); // Pause audio playback
|
||||
break;
|
||||
|
||||
default:
|
||||
break;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4. API Design
|
||||
|
||||
1. **Initialization Functions**
|
||||
|
||||
Initialization functions are responsible for tasks such as resource configuration, UI creation, and loading configuration files when the application starts. The main function APIs are:
|
||||
|
||||
```cpp
|
||||
/* Init functions */
|
||||
static void read_configs(void);
|
||||
static bool init_resource(void);
|
||||
static void reload_music_config(void);
|
||||
static void app_create_error_page(void);
|
||||
static void app_create_main_page(void);
|
||||
static void app_create_top_layer(void);
|
||||
```
|
||||
|
||||
2. **Timer Start Functions**
|
||||
|
||||
Timer control tasks are used to start background processes that support dynamic UI updates, such as time display and playback progress updates.
|
||||
|
||||
```cpp
|
||||
/* Timer starting functions */
|
||||
static void app_start_updating_date_time(void);
|
||||
```
|
||||
|
||||
3. **Album Operation APIs**
|
||||
|
||||
Album operations are a core feature of the music player, supporting album sorting, switching, and related playback handling.
|
||||
|
||||
```cpp
|
||||
/* Album operations */
|
||||
static int32_t app_get_album_index(album_info_t* album);
|
||||
static void app_switch_to_album(int index);
|
||||
```
|
||||
|
||||
4. **Player Status APIs**
|
||||
|
||||
Player status APIs are used to set the player's runtime state, such as playing, pausing, changing volume, or adjusting playback time. The following APIs implement these features:
|
||||
|
||||
```cpp
|
||||
/* Player status operations */
|
||||
static void app_set_play_status(play_status_t status);
|
||||
static void app_set_playback_time(uint32_t current_time);
|
||||
static void app_set_volume(uint16_t volume);
|
||||
```
|
||||
|
||||
5. **UI Refresh Function APIs**
|
||||
|
||||
UI refresh APIs are responsible for dynamically updating UI components, such as the real-time display of album information, playback status, volume bar, and playback progress.
|
||||
|
||||
```cpp
|
||||
/* UI refresh functions */
|
||||
static void app_refresh_album_info(void);
|
||||
static void app_refresh_date_time(void);
|
||||
static void app_refresh_play_status(void);
|
||||
static void app_refresh_playback_progress(void);
|
||||
static void app_refresh_playlist(void);
|
||||
static void app_refresh_volume_bar(void);
|
||||
static void app_refresh_volume_countdown_timer(void);
|
||||
```
|
||||
|
||||
6. **Event Handler APIs**
|
||||
|
||||
Event handling is a crucial part of user interaction, responsible for processing events from buttons, playlists, the volume bar, and more.
|
||||
|
||||
```cpp
|
||||
/* Event handler functions */
|
||||
static void app_audio_event_handler(lv_event_t* e);
|
||||
static void app_play_status_event_handler(lv_event_t* e);
|
||||
static void app_playlist_btn_event_handler(lv_event_t* e);
|
||||
static void app_playlist_event_handler(lv_event_t* e);
|
||||
static void app_switch_album_event_handler(lv_event_t* e);
|
||||
static void app_volume_bar_event_handler(lv_event_t* e);
|
||||
static void app_playback_progress_bar_event_handler(lv_event_t* e);
|
||||
```
|
||||
|
||||
7. **Timer Callback Function APIs**
|
||||
|
||||
Timer-related callback functions are used to trigger tasks at fixed time intervals.
|
||||
|
||||
```cpp
|
||||
/* Timer callback functions */
|
||||
static void app_refresh_date_time_timer_cb(lv_timer_t* timer);
|
||||
static void app_playback_progress_update_timer_cb(lv_timer_t* timer);
|
||||
static void app_volume_bar_countdown_timer_cb(lv_timer_t* timer);
|
||||
```
|
||||
|
||||
### 5. Writing Project Configuration Files
|
||||
|
||||
- The purpose of configuring the build system files is to compile all source code in the directory into an executable product.
|
||||
- When a new application is added, it requires new configuration options to determine whether to enable it, how much stack to allocate, its process execution priority, and its name.
|
||||
- To add the music player, the build system configuration files, including Kconfig, Makefile, and Make.defs, must be updated.
|
||||
|
||||
#### Kconfig File
|
||||
|
||||
The following is the new Kconfig file for the application project, used to enable the feature and define the music player's data path:
|
||||
|
||||
```CMake
|
||||
config LVX_USE_DEMO_MUSIC_PLAYER
|
||||
bool "Music Player"
|
||||
default n
|
||||
|
||||
if LVX_USE_DEMO_MUSIC_PLAYER
|
||||
config LVX_MUSIC_PLAYER_DATA_ROOT
|
||||
string "Music Player Data Root"
|
||||
default "/sdcard"
|
||||
endif
|
||||
```
|
||||
|
||||
#### Makefile File
|
||||
|
||||
The `Makefile` controls the application's compilation rules and resources.
|
||||
|
||||
```Makefile
|
||||
include $(APPDIR)/Make.defs
|
||||
|
||||
ifeq ($(CONFIG_LVX_USE_DEMO_MUSIC_PLAYER), y)
|
||||
PROGNAME = music_player
|
||||
PRIORITY = 100
|
||||
STACKSIZE = 32768
|
||||
MODULE = $(CONFIG_LVX_USE_DEMO_MUSIC_PLAYER)
|
||||
|
||||
CSRCS = music_player.c audio_ctl.c wifi.c
|
||||
MAINSRC = music_player_main.c
|
||||
endif
|
||||
|
||||
include $(APPDIR)/Application.mk
|
||||
```
|
||||
|
||||
#### Make.defs File
|
||||
|
||||
The `Make.defs` file adds the new music player module to the system build.
|
||||
|
||||
```Makefile
|
||||
ifneq ($(CONFIG_LVX_USE_DEMO_MUSIC_PLAYER),)
|
||||
CONFIGURED_APPS += $(APPDIR)/packages/demos/music_player
|
||||
endif
|
||||
```
|
||||
|
||||
## VI. Compiling and Running
|
||||
|
||||
### 1. Configure the Project
|
||||
|
||||
1. Navigate to the root directory of the openvela repository and execute the following command to configure the music player.
|
||||
|
||||
The emulator's configuration file (defconfig) is located in `vendor/openvela/boards/vela/configs/goldfish-armeabi-v7a-ap/`. Use `build.sh` to configure and compile the board's code.
|
||||
|
||||
```Bash
|
||||
./build.sh vendor/openvela/boards/vela/configs/goldfish-armeabi-v7a-ap menuconfig
|
||||
```
|
||||
|
||||
- `build.sh`: A build script used to configure and compile openvela code.
|
||||
- `vendor/openvela/boards/vela/configs/*`: The configuration path.
|
||||
- `menuconfig`: Opens the menuconfig interface to modify project code configurations.
|
||||
|
||||
After execution, the following interface will appear:
|
||||
|
||||

|
||||
|
||||
2. Press the `/` key to search for and modify the following configurations one by one:
|
||||
|
||||
```Bash
|
||||
LVX_USE_DEMO_MUSIC_PLAYER=y
|
||||
LVX_MUSIC_PLAYER_DATA_ROOT="/data"
|
||||
```
|
||||
|
||||
The following steps use `LVX_USE_DEMO_MUSIC_PLAYER` as an example; the process for other configurations is the same.
|
||||
|
||||
1. Enter the configuration to search for, `LVX_USE_DEMO_MUSIC_PLAYER`. Fuzzy search, e.g., `music_player`, is supported. Find the corresponding configuration and press Enter to navigate to it.
|
||||
|
||||

|
||||
|
||||
2. Press the Spacebar. An asterisk `*` appearing in `[ ]` indicates that the option is enabled.
|
||||
|
||||

|
||||
|
||||
3. Set `LVX_MUSIC_PLAYER_DATA_ROOT` to `/data`. After modifying, press Enter to save the current configuration item.
|
||||
|
||||

|
||||
|
||||
4. Press the `Q` key. The following save and exit prompt will appear.
|
||||
|
||||

|
||||
|
||||
5. Press the `Y` key to save the configuration and exit the configuration interface.
|
||||
|
||||
### 2. Compile the Project
|
||||
|
||||
1. Navigate to the root directory of the openvela repository and execute the following commands in the terminal:
|
||||
|
||||
```Bash
|
||||
# Clean build artifacts
|
||||
./build.sh vendor/openvela/boards/vela/configs/goldfish-armeabi-v7a-ap distclean -j8
|
||||
|
||||
# Start the build
|
||||
./build.sh vendor/openvela/boards/vela/configs/goldfish-armeabi-v7a-ap -j8
|
||||
```
|
||||
|
||||
2. After a successful build, the following files will be generated:
|
||||
|
||||
```Bash
|
||||
./nuttx
|
||||
├── vela_ap.elf
|
||||
├── vela_ap.bin
|
||||
```
|
||||
|
||||
### 3. Start the Emulator and Push Resources
|
||||
|
||||
The font and image resources used by the music player are located in `apps/packages/demos/music_player/res`. To push these resources to the corresponding file path mounted by the emulator, follow these steps.
|
||||
|
||||
1. Navigate to the root directory of the openvela repository and start the emulator:
|
||||
|
||||
```Bash
|
||||
./emulator.sh vela
|
||||
```
|
||||
|
||||
2. Use the ADB tool supported by the emulator to push resources to the device. Open a new terminal in the root directory of the openvela repository and enter `adb push` followed by the file path to transfer the resources.
|
||||
|
||||
```Bash
|
||||
# Install adb
|
||||
sudo apt install android-tools-adb
|
||||
|
||||
# Push resources
|
||||
adb push apps/packages/demos/music_player/res /data/
|
||||
```
|
||||
|
||||
### 4. Start the Music Player
|
||||
|
||||
In the emulator's terminal environment `openvela-ap>`, enter the following command:
|
||||
|
||||
```Bash
|
||||
music_player &
|
||||
```
|
||||
|
||||
### 5. Exit the Demo
|
||||
|
||||
Close the emulator to exit the demo, as shown below:
|
||||
|
||||

|
||||
|
||||
## VII. FAQ
|
||||
|
||||
### 1. How to Customize the Music Player
|
||||
|
||||
1. Modify the relevant configurations under `apps/packages/demos/music_player/res`. Add new music media files to the `res/musics` directory. Currently, only the `*.wav` format is supported. You can convert media files from other formats like `*.mp3/aac/m4a` to `*.wav` format yourself. Then, modify the `res/musics/manifest.json` file in that directory:
|
||||
|
||||
```JSON
|
||||
{
|
||||
"musics": [
|
||||
{
|
||||
"path": "UnamedRhythm.wav",
|
||||
"name": "UnamedRhythm",
|
||||
"artist": "Benign X",
|
||||
"cover": "UnamedRhythm.png",
|
||||
"total_time": 12000,
|
||||
"color": "#114514"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
2. Add a new JSON object to the musics array for each song you want to add. Refer to the parameter descriptions below.
|
||||
|
||||
| Parameter | Description |
|
||||
| :--------- | :--------------------------------------------------------------------------- |
|
||||
| path | File path of the media to be played. |
|
||||
| name | Name of the media. |
|
||||
| artist | Name of the artist. |
|
||||
| cover | Path to the cover image. If not provided, a default cover will be displayed. |
|
||||
| total_time | The total duration of the media, in `milliseconds`. |
|
||||
| color | Theme color, currently not in use. |
|
||||
|
||||
Refer to this format to add the media you want to play to this configuration file.
|
||||
|
||||
For example, to add a song named `Happiness.wav` with a duration of `186,507 ms`, you can modify the file as follows:
|
||||
|
||||
```JSON
|
||||
{
|
||||
"musics": [
|
||||
{
|
||||
"path": "UnamedRhythm.wav",
|
||||
"name": "UnamedRhythm",
|
||||
"artist": "Benign X",
|
||||
"cover": "UnamedRhythm.png",
|
||||
"total_time": 12000,
|
||||
"color": "#114514"
|
||||
},
|
||||
{
|
||||
"path": "Happiness.wav",
|
||||
"name": "Xin",
|
||||
"artist": "Tang",
|
||||
"cover": "Good.png",
|
||||
"total_time": 186507,
|
||||
"color": "#252525"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
3. After modifying the configuration, you need to push the resources again. Execute the following command:
|
||||
|
||||
```Bash
|
||||
# Push resources
|
||||
adb push apps/packages/demos/music_player/res /data/
|
||||
```
|
||||
|
||||
4. Exit the emulator.
|
||||
|
||||
5. Re-run the steps from [Start the Emulator and Push Resources](#3-start-the-emulator-and-push-resources) and [Start the Music Player](#4-start-the-music-player).
|
||||
|
|
@ -1,15 +1,17 @@
|
|||
# Add Hello World Example
|
||||
# Running the Hello World Example
|
||||
|
||||
\[ English | [简体中文](../../../../zh-cn/app_dev/system_apps/hello_world/Hello_World.md) \]
|
||||
[ English | [简体中文](../../../../zh-cn/app_dev/system_apps/hello_world/Hello_World.md) ]
|
||||
|
||||
## I Overview
|
||||
## Overview
|
||||
|
||||
openvela is built based on the open-source operating system NuttX, which further provides a variety of complex system-level services. To make openvela more comprehensive and feature-rich, it is necessary to introduce a complete development framework or functional module. A complete development framework typically includes the following two components:
|
||||
This document is intended for developers and aims to provide a detailed introduction to adding, configuring, and running a new user application within the openvela operating system. openvela is built on the NuttX RTOS, and its modular design allows developers to easily integrate custom functions or third-party libraries.
|
||||
|
||||
- System Applications: Internally developed system applications, usually stored in folders such as `apps/` and others.
|
||||
- Third-Party System Libraries: Integration of third-party libraries and their adaptation, usually stored in folders such as `external/` and others.
|
||||
A typical functional module consists of the following parts:
|
||||
|
||||
The directory structure for new features and frameworks is shown in the figure below:
|
||||
- **System Application:** Part of the built-in system functions, typically stored in the `apps/` directory.
|
||||
- **Third-Party Library:** Introduced as an external dependency, typically stored in the `external/` directory.
|
||||
|
||||
The example directory structure is as follows:
|
||||
|
||||
```Bash
|
||||
└── vela
|
||||
|
|
@ -22,38 +24,34 @@ The directory structure for new features and frameworks is shown in the figure b
|
|||
└── libs_2
|
||||
```
|
||||
|
||||
## II Add Hello World Example
|
||||
This guide will use the `Hello, World!` example application to demonstrate the complete process from coding to building, running, and configuring auto-start.
|
||||
|
||||
This section describes how to add a `Hello World` example application in openvela, including the main framework, file contents, and related build configurations.
|
||||
## Step 1: Reviewing the Hello World Example Framework
|
||||
|
||||
This section introduces how to add an example application to openvela, including the main framework, file contents, and relevant build configurations.
|
||||
|
||||
### 1. Main Framework
|
||||
|
||||
The Hello World example application needs to include the following core files:
|
||||
The Hello World example application requires the following core files:
|
||||
|
||||
- `hello_main.c`: Defines the main logic of the application.
|
||||
- `Kconfig`: Defines conditional compilation macros for feature trimming.
|
||||
- `CMakeLists.txt`: Organizes the build system for openvela using `CMake`.
|
||||
- `Make.defs`: Indicates whether the current directory needs to be compiled and must be included by the parent directory.
|
||||
- `Makefile`: Defines the internal file compilation rules and compilation flags (FLAGS) for the library.
|
||||
- `hello_main.c`: The source code of the application, containing the `main` function entry point.
|
||||
- `Kconfig`: The configuration file for the build system, used to provide configurable compilation options in `menuconfig`.
|
||||
- `CMakeLists.txt`: The CMake build script used to define source code, dependencies, and compilation rules.
|
||||
|
||||
An example of the directory structure is shown below:
|
||||
The directory structure example is as follows, with Hello World currently added:
|
||||
|
||||
```Bash
|
||||
apps
|
||||
└── examples
|
||||
└── hello_main
|
||||
└── hello
|
||||
├── hello_main.c
|
||||
├── CMakeLists.txt
|
||||
├── Kconfig
|
||||
├── Make.defs
|
||||
└── Makefile
|
||||
```
|
||||
|
||||
### 2. File contents
|
||||
### 2. Writing Source Code (hello_main.c)
|
||||
|
||||
#### hello_main.c
|
||||
|
||||
The file `hello_main.c` should contain the basic C application logic:
|
||||
Examine the `hello_main.c` file, which is the execution logic entry point for the application:
|
||||
|
||||
```C
|
||||
#include <stdio.h>
|
||||
|
|
@ -65,7 +63,7 @@ int main(int argc, char *argv[])
|
|||
}
|
||||
```
|
||||
|
||||
To add a C++ application, the entry function (`main`) needs to use the `extern "C"` declaration to ensure compatibility with the higher-level interface:
|
||||
If you need to use C++, please ensure the `main` function uses the `extern "C"` declaration to guarantee C language linkage compatibility, ensuring it can be correctly called by the system:
|
||||
|
||||
```C++
|
||||
#include <iostream>
|
||||
|
|
@ -77,19 +75,21 @@ extern "C" int main(int argc, char *argv[])
|
|||
}
|
||||
```
|
||||
|
||||
#### Kconfig
|
||||
### 3. Creating the Kconfig Configuration File
|
||||
|
||||
Here's an example of what a `kconfig` file looks like:
|
||||
Examine the `Kconfig` file, which is used to define the compilation options for the application. These options will appear in the `menuconfig` graphical configuration interface, allowing users to enable or configure your application as needed:
|
||||
|
||||
```plaintext
|
||||
```makefile
|
||||
config EXAMPLES_HELLO
|
||||
tristate "\"Hello, World!\" example"
|
||||
default n
|
||||
---help---
|
||||
Enable the \"Hello, World!\" example
|
||||
|
||||
# The following options are only visible when EXAMPLES_HELLO is enabled
|
||||
if EXAMPLES_HELLO
|
||||
# The following directives default "hello" need to be run :
|
||||
|
||||
# Define the command name for the application in openvela
|
||||
config EXAMPLES_HELLO_PROGNAME
|
||||
string "Program name"
|
||||
default "hello"
|
||||
|
|
@ -97,10 +97,12 @@ config EXAMPLES_HELLO_PROGNAME
|
|||
This is the name of the program that will be used when the NSH ELF
|
||||
program is installed.
|
||||
|
||||
# Define the priority of the application task
|
||||
config EXAMPLES_HELLO_PRIORITY
|
||||
int "Hello task priority"
|
||||
default 100
|
||||
|
||||
# Define the stack size of the application task
|
||||
config EXAMPLES_HELLO_STACKSIZE
|
||||
int "Hello stack size"
|
||||
default DEFAULT_TASK_STACKSIZE
|
||||
|
|
@ -108,32 +110,37 @@ config EXAMPLES_HELLO_STACKSIZE
|
|||
endif
|
||||
```
|
||||
|
||||
#### CMakeLists.txt
|
||||
### 4. Creating the CMake Build Script
|
||||
|
||||
Here's an example of the contents of a `CMakeLists.txt` file, where all the configuration variables can be used directly:
|
||||
Examine the `CMakeLists.txt` file. The openvela build system automatically loads all macro definitions from the `.config` file as CMake variables, so you can directly use the configurations defined in `Kconfig`.
|
||||
|
||||
```CMake
|
||||
# All the configurations in .config are loaded into the CMake environment, so the variables can be used directly
|
||||
|
||||
# Enable Config, which replaces the configuration of the original Make.defs configured_apps
|
||||
if(CONFIG_EXAMPLES_HELLO) # If defconfig enables this feature, add it to compilation
|
||||
# call Add app module 'nuttx_add_application' Add hello as a builtin app.
|
||||
|
||||
nuttx_add_application(
|
||||
NAME #Parameter flags: the unique name of the application
|
||||
${CONFIG_EXAMPLES_HELLO_PROGNAME} #Parameter value: Set the value in hello kconfig as the name of the hello application
|
||||
SRCS #Parameter flags: Source file
|
||||
hello_main.c #Parameter value: The source file of the application, which can be multiple, and the main must be the first
|
||||
STACKSIZE #Parameter flags: STACK SIZE
|
||||
${CONFIG_EXAMPLES_HELLO_STACKSIZE} #Parameter value: takes the value set in Kconfig, and if you don't pass it, it is CONFIG_DEFAULT_TASK_STACKSIZE
|
||||
PRIORITY #Parameter flags: THE PRIORITY OF THE TASK
|
||||
${CONFIG_EXAMPLES_HELLO_PRIORITY}) #Parameter value: takes the value set in Kconfig, and if you don't pass it, it is SCHED_PRIORITY_DEFAULT
|
||||
# Check if 'EXAMPLES_HELLO' is enabled in .config
|
||||
if(CONFIG_EXAMPLES_HELLO) # If defconfig enables this feature, add it to the build
|
||||
|
||||
# Call the nuttx_add_application function to register the app as a built-in program
|
||||
nuttx_add_application(
|
||||
# NAME: Specify the unique name of the application, usually consistent with PROGNAME in Kconfig
|
||||
NAME
|
||||
${CONFIG_EXAMPLES_HELLO_PROGNAME}
|
||||
|
||||
# SRCS: Specify the list of source files; the file containing the main function should be first
|
||||
SRCS
|
||||
hello_main.c
|
||||
|
||||
# STACKSIZE: Specify the task stack size
|
||||
STACKSIZE
|
||||
${CONFIG_EXAMPLES_HELLO_STACKSIZE}
|
||||
|
||||
# PRIORITY: Specify the task priority; defaults to SCHED_PRIORITY_DEFAULT if not passed
|
||||
PRIORITY
|
||||
${CONFIG_EXAMPLES_HELLO_PRIORITY})
|
||||
endif()
|
||||
```
|
||||
|
||||
`nuttx_add_application()`
|
||||
#### `nuttx_add_application()` Function Definition
|
||||
|
||||
The CMake function is located in the `nuttx/cmake/nuttx_add_application.cmake` file and is used to add and configure the application.
|
||||
This CMake function is located in `nuttx/cmake/nuttx_add_application.cmake` and is used to add and configure applications.
|
||||
|
||||
```CMake
|
||||
nuttx/cmake/nuttx_add_application.cmake
|
||||
|
|
@ -158,193 +165,130 @@ nuttx/cmake/nuttx_add_application.cmake
|
|||
NO_MAIN_ALIAS : do not add a main=<app>_main alias(*)
|
||||
```
|
||||
|
||||
#### Makefile
|
||||
## Step 2: Verifying the Application
|
||||
|
||||
To add a new application in openvela, the core steps are to add the application’s entry source file to `MAINSRC` and to correctly define the following three essential parameters:
|
||||
After creating the files, you need to configure, compile, and run your application by following these steps.
|
||||
|
||||
- `PROGNAME`: The name of the application, used when launching under `nsh`.
|
||||
### 1. Cleaning the Build Environment (Optional)
|
||||
|
||||
- `PRIORITY`: The execution priority of the application.
|
||||
|
||||
- `STACKSIZE`: The stack size allocated to the application.
|
||||
|
||||
These three settings are mandatory for building and running the application.
|
||||
|
||||
Below is an example of a `Makefile` demonstrating how to configure them:
|
||||
|
||||
```Makefile
|
||||
include $(APPDIR)/Make.defs
|
||||
|
||||
# Program name: can be taken from the Kconfig setting, or defined directly
|
||||
PROGNAME = $(CONFIG_EXAMPLES_HELLO_PROGNAME)
|
||||
# Or: PROGNAME = hello
|
||||
|
||||
# Application priority
|
||||
PRIORITY = $(CONFIG_EXAMPLES_HELLO_PRIORITY)
|
||||
# Or: PRIORITY = 100 (adjust as needed)
|
||||
|
||||
# Stack size for the application
|
||||
STACKSIZE = $(CONFIG_EXAMPLES_HELLO_STACKSIZE)
|
||||
# Or: STACKSIZE = 4096 (adjust as needed)
|
||||
|
||||
# Enable this module
|
||||
MODULE = $(CONFIG_EXAMPLES_HELLO)
|
||||
|
||||
# Entry-point source file
|
||||
MAINSRC = hello_main.c
|
||||
|
||||
# If you need to include additional headers, add them here, for example:
|
||||
CFLAGS += ${INCDIR_PREFIX}$(APPDIR)/external/libs/include
|
||||
# Which is equivalent to:
|
||||
# CFLAGS += -I$(APPDIR)/external/libs/include
|
||||
|
||||
# For C++ projects, add include paths to CXXFLAGS:
|
||||
# CXXFLAGS
|
||||
|
||||
# To include other internally developed source files, append them here:
|
||||
CSRCS += device_example.c
|
||||
|
||||
# For C++ source files, similarly:
|
||||
# CXXSRCS += hello_main.cxx
|
||||
|
||||
# Finally, pull in openvela’s standard application build rules
|
||||
include $(APPDIR)/Application.mk
|
||||
```
|
||||
|
||||
When your project has multiple entry points, you can use #ifdef blocks or Kconfig-driven conditionals in the `Makefile` to select which MAINSRC (and related settings) to use. For example:
|
||||
If you have modified the Kconfig file or wish to perform a fresh compilation, it is recommended to perform a cleanup operation first:
|
||||
|
||||
```Bash
|
||||
ifeq ($(CONFIG_MAIN1),yes)
|
||||
PROGNAME += main1
|
||||
MAINSRC += main1.c
|
||||
endif
|
||||
|
||||
ifeq ($(CONFIG_MAIN2),yes)
|
||||
PROGNAME += main2
|
||||
MAINSRC += main2.c
|
||||
endif
|
||||
# Use distclean to clean all build artifacts and configurations
|
||||
./build.sh vendor/openvela/boards/vela/configs/goldfish-armeabi-v7a-ap --cmake distclean -j$(nproc)
|
||||
```
|
||||
|
||||
If the C++ source file in your project does not have a suffix of `.cxx`, you need to specify the suffix in `Makefile` with the `CXXEXT` parameter. For example:
|
||||
Alternatively, delete the CMake artifacts directly:
|
||||
|
||||
```Makefile
|
||||
CXXEXT := .cpp
|
||||
```bash
|
||||
# Or directly delete cmake artifacts
|
||||
rm -rf cmake_out/vela_goldfish-armeabi-v7a-ap
|
||||
```
|
||||
|
||||
#### Make.defs
|
||||
### 2. Graphical Configuration (menuconfig)
|
||||
|
||||
In the `Make.defs` file, you need to add the path of the application to the `CONFIGURED_APPS` so that the openvela build system can find the required path correctly:
|
||||
|
||||
```Makefile
|
||||
ifneq ($(CONFIG_EXAMPLES_HELLO),)
|
||||
CONFIGURED_APPS += $(APPDIR)/examples/hello_main
|
||||
endif
|
||||
```
|
||||
|
||||
## III Verification and Testing
|
||||
|
||||
The newly added application must be cleaned and rebuilt before it can take effect. Follow these steps to verify:
|
||||
|
||||
### 1. Clean the Build
|
||||
|
||||
Run the following command to perform a clean:
|
||||
Launch `menuconfig` to enable your new application in the graphical interface:
|
||||
|
||||
```Bash
|
||||
# clean the project
|
||||
./build.sh vendor/openvela/boards/vela/configs/goldfish-armeabi-v7a-ap distclean -j8
|
||||
# Start menuconfig
|
||||
./build.sh vendor/openvela/boards/vela/configs/goldfish-armeabi-v7a-ap --cmake menuconfig -j$(nproc)
|
||||
```
|
||||
|
||||
### 2. Configure via Menuconfig
|
||||
|
||||
Enable the new application in the `menuconfig`:
|
||||
|
||||
```Bash
|
||||
# 启动 menuconfig
|
||||
./build.sh vendor/openvela/boards/vela/configs/goldfish-armeabi-v7a-ap menuconfig -j8
|
||||
```
|
||||
|
||||
Inside `menuconfig`, navigate to and enable `hello_main`:
|
||||
In the `menuconfig` interface, find and enable your application via the following path: `Application Configuration` ---> `Examples` ---> `[*] "Hello, World!" example`.
|
||||
|
||||

|
||||
|
||||
## 3. Build and Run
|
||||
### 3. Build and Run
|
||||
|
||||
After saving the `menuconfig` configuration, execute the compilation.
|
||||
|
||||
```Bash
|
||||
# Build:
|
||||
./build.sh vendor/openvela/boards/vela/configs/goldfish-armeabi-v7a-ap -j8
|
||||
# Compile the firmware (-j`nproc` uses all CPU cores for parallel compilation)
|
||||
./build.sh vendor/openvela/boards/vela/configs/goldfish-armeabi-v7a-ap --cmake -j$(nproc)
|
||||
|
||||
# Run:
|
||||
# Copy the artifacts
|
||||
cp cmake_out/vela_goldfish-armeabi-v7a-ap/nuttx* nuttx/ &&
|
||||
cp cmake_out/vela_goldfish-armeabi-v7a-ap/vela_data.bin nuttx/ &&
|
||||
cp cmake_out/vela_goldfish-armeabi-v7a-ap/vela_system.bin nuttx/
|
||||
|
||||
# Start the emulator to run the firmware
|
||||
./emulator.sh vela
|
||||
```
|
||||
|
||||
After booting, at the serial console prompt type the program name (as defined in your `Kconfig`). For example:
|
||||
After the system boots, enter the program name you configured in `Kconfig` (default is `hello`) into the NSH command line and press Enter to see the program output:
|
||||
|
||||

|
||||
|
||||
## IV. Implementing Application Auto-Start
|
||||
## Step 3: Configuring Application Auto-Start
|
||||
|
||||
openvela uses the NuttShell (NSH) startup script mechanism to run applications automatically at boot. The process is as follows:
|
||||
openvela supports automatically running specific scripts upon system startup. You can implement application auto-start by editing the startup script.
|
||||
|
||||
1. During system startup, a pre-configured Read-Only File System (ROMFS) is mounted to the `/etc` directory.
|
||||
2. After the mount is complete, NSH automatically executes the `/etc/init.d/rcS` script file.
|
||||
3. To enable auto-start for an application, add its launch command to the `rcS` script.
|
||||
### 1. Auto-Start Mechanism and Configuration
|
||||
|
||||
### 1. Enabling the Auto-Start Feature
|
||||
The startup scripts for openvela are stored in the `/etc` directory. This directory is linked with the openvela binary files in the form of `romfs`. It is automatically mounted by `nshlib` after the system boots. The relevant configuration is as follows.
|
||||
|
||||
To use this feature, enable the following options in your build configuration using the Kconfig system.
|
||||
Ensure your board-level configuration enables the following `Kconfig` options:
|
||||
|
||||
| Configuration Option | Recommended Value | Description |
|
||||
| :------------------------- | :-------------------- | :---------------------------------------------------------------------------------------------- |
|
||||
| `CONFIG_FS_ROMFS` | `y` | Enables ROMFS support, which is required to store the startup script. |
|
||||
| `CONFIG_NSH_ROMFSETC` | `y` | Enables the automatic mounting of the ROMFS to the `/etc` directory at system startup. |
|
||||
| `CONFIG_NSH_ROMFSMOUNTPT` | `"/etc"` | Specifies the mount point path for the ROMFS. |
|
||||
| `CONFIG_NSH_SYSINITSCRIPT` | `"init.d/rc.sysinit"` | Specifies the path to the system-level initialization script. |
|
||||
| `CONFIG_NSH_INITSCRIPT` | `"init.d/rcS"` | Specifies the path to the user-level initialization script, which is the file you need to edit. |
|
||||
```makefile
|
||||
CONFIG_FS_ROMFS=y
|
||||
CONFIG_ETC_ROMFS=y
|
||||
CONFIG_ETC_ROMFSMOUNTPT="/etc"
|
||||
CONFIG_NSH_SYSINITSCRIPT="init.d/rc.sysinit"
|
||||
CONFIG_NSH_INITSCRIPT="init.d/rcS"
|
||||
```
|
||||
|
||||
### 2. Editing the User Startup Script
|
||||
### 2. Startup Script Location
|
||||
|
||||
#### Script Location
|
||||
|
||||
The file you need to modify is the user startup script, `rcS`.
|
||||
|
||||
- **User Script (Recommended to modify):** `vendor/openvela/boards/vela/src/etc/init.d/rcS`
|
||||
- **System Script (Do not modify):** `vendor/openvela/boards/vela/src/etc/init.d/rc.sysinit`
|
||||
This script handles core system initialization. Modifying it may prevent the system from booting.
|
||||
|
||||
#### Script Writing Example
|
||||
|
||||
The following is an example of an `rcS` script. NSH scripts support standard shell commands and are compatible with C preprocessor directives (e.g., `#ifdef`).
|
||||
The default user startup script is located in the board-level configuration directory:
|
||||
|
||||
```bash
|
||||
# NuttShell Script (rcS)
|
||||
vendor/openvela/boards/vela/src/etc/init.d/rc.sysinit # System initialization script
|
||||
vendor/openvela/boards/vela/src/etc/init.d/rcS # User script
|
||||
```
|
||||
|
||||
#include <nuttx/config.h>
|
||||
### 3. Editing the Startup Script
|
||||
|
||||
# Use a C preprocessor directive to check if Host File System (Host FS) is configured.
|
||||
Open the `rcS` file and add the execution command for your application.
|
||||
|
||||
```bash
|
||||
#ifdef CONFIG_FS_HOSTFS
|
||||
# If configured, mount the host directory to /data.
|
||||
mount -t hostfs -o fs=. /data
|
||||
mount -t hostfs -o fs=vendor/openvela/boards/vela/resource /host
|
||||
#endif
|
||||
|
||||
# Start an application named "hello" in the foreground.
|
||||
# The script blocks here until the hello program finishes execution.
|
||||
hello
|
||||
|
||||
# Start an application named "hello" in the background.
|
||||
# The "&" symbol runs the program in the background, allowing the script
|
||||
# to continue to the next command immediately.
|
||||
hello &
|
||||
```
|
||||
|
||||
#### Important Considerations
|
||||
The result after addition is shown in the figure below:
|
||||
|
||||
1. Task Creation Methods.
|
||||

|
||||
|
||||
We recommend the following methods for applications that need to run at system startup:
|
||||
### 4. Recompiling and Running
|
||||
|
||||
- **Start via NSH Script (Recommended)**: For most applications, the simplest and most robust method is to add the command to the `rcS` script and run it in the background using the `&` symbol.
|
||||
- **Start via Programmatic Interface**: For scenarios requiring complex initialization or dynamic task creation, you can use the standard POSIX function `pthread_create()` within your application to create new threads.
|
||||
```bash
|
||||
# Compile the firmware (-j`nproc` uses all CPU cores for parallel compilation)
|
||||
./build.sh vendor/openvela/boards/vela/configs/goldfish-armeabi-v7a-ap --cmake -j$(nproc)
|
||||
|
||||
2. Thread Management.
|
||||
# Copy the artifacts
|
||||
cp cmake_out/vela_goldfish-armeabi-v7a-ap/nuttx* nuttx/ &&
|
||||
cp cmake_out/vela_goldfish-armeabi-v7a-ap/vela_data.bin nuttx/ &&
|
||||
cp cmake_out/vela_goldfish-armeabi-v7a-ap/vela_system.bin nuttx/
|
||||
|
||||
If your main application creates child threads using `pthread_create()`, ensure the main thread waits for all child threads to exit safely before it terminates. Prematurely exiting the main thread can cause child threads to be terminated unexpectedly, leading to system instability or resource leaks.
|
||||
# Start the emulator to run the firmware
|
||||
./emulator.sh vela
|
||||
```
|
||||
|
||||
The result after startup is shown in the figure below:
|
||||
|
||||

|
||||
|
||||
**Note:**
|
||||
|
||||
- **Use POSIX Threads:** Within the application, it is recommended to use `pthread_create()` to create and manage child threads rather than directly calling the lower-level `task_create()`. This ensures better portability and compatibility.
|
||||
- **Guard the Main Thread:** If your main thread creates child threads, ensure the main thread only exits after all child threads have safely exited. Otherwise, the exit of the main thread may cause the entire process to be reclaimed, forcibly terminating the child threads.
|
||||
- **Create Background Services:** For services that need to run long-term, you can use `&` in the `rcS` script to run them in the background. Internally, the application typically enters a loop (such as `while(1)`) to handle events or execute periodic tasks.
|
||||
|
||||
## References
|
||||
|
||||
To help you better understand and add `CMakeLists.txt`, below are reference materials and tool information:
|
||||
|
||||
- For the openvela CMake build system, please refer to the [CMake Quick Start](../../../device_dev_guide/build/CMake_quick_start.md).
|
||||
|
After Width: | Height: | Size: 78 KiB |
|
After Width: | Height: | Size: 405 KiB |
|
|
@ -125,7 +125,7 @@ The following are the interrupt-related functions that vendors need to implement
|
|||
|
||||
### 2. Required Interrupt-Related Macros
|
||||
|
||||
Alongside the above function implementations, vendors need to define a series of interrupt-related macros, which describe the configuration of the NVIC (Nested Vectored Interrupt Controller). These macros should be defined in the `chips/chip_name/include/irq.h` file. Refer to the [RTL8720C example](../../../../../nuttx/blob/dev/arch/arm/src/rtl8720c/include/irq.h) for guidance.
|
||||
Alongside the above function implementations, vendors need to define a series of interrupt-related macros, which describe the configuration of the NVIC (Nested Vectored Interrupt Controller). These macros should be defined in the `chips/chip_name/include/irq.h` file. Refer to the [RTL8720C example](../../../../../nuttx/blob/trunk-5.5/arch/arm/src/rtl8720c/include/irq.h) for guidance.
|
||||
|
||||
The required macros and their descriptions are as follows:
|
||||
|
||||
|
|
@ -361,7 +361,7 @@ struct irq_info_s g_irqvector[CONFIG_ARCH_NUSER_INTERRUPTS];
|
|||
|
||||
Use `g_irqmap_count` to keep track of the number of interrupts currently in use, facilitating monitoring and debugging.
|
||||
|
||||
## 2. Configuration Example
|
||||
### 2. Configuration Example
|
||||
|
||||
Enable the optimization with the following macros:
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ To ensure the isolation and privacy security of vendor code, a dedicated directo
|
|||
Upon completing the code download, the overall directory structure is as follows:
|
||||
|
||||
```Shell
|
||||
djz:vela$ tree -L 1
|
||||
$ tree -L 1
|
||||
.
|
||||
├── apps
|
||||
├── build.sh -> nuttx/tools/build.sh
|
||||
|
|
@ -40,7 +40,7 @@ seven directories, one file
|
|||
The vendor directory is used to store the relevant code and configurations for each vendor. The layout of its contents is as follows:
|
||||
|
||||
```Shell
|
||||
djz:vendor$ tree -L 1
|
||||
$ tree -L 1
|
||||
.
|
||||
├── <vendor_name>
|
||||
├── Make.defs
|
||||
|
|
@ -61,11 +61,11 @@ When a vendor initially acquires the code, the layout of the vendor_name directo
|
|||
|
||||
```C
|
||||
// Directory location
|
||||
djz:vendor_name$ pwd
|
||||
/home/djz/workspace/velaos/vendor/<vendor_name>
|
||||
$ pwd
|
||||
/home/{namepath}/workspace/velaos/vendor/<vendor_name>
|
||||
|
||||
// Directory layout
|
||||
djz:vendor_name$ tree -l
|
||||
$ tree -l
|
||||
├── boards
|
||||
│ └── <chip_name>
|
||||
│ └── <board_name>
|
||||
|
|
|
|||
|
|
@ -166,15 +166,13 @@ void __start(void)
|
|||
...
|
||||
|
||||
#ifdef CONFIG_ARCH_PERF_EVENTS
|
||||
up_perf_init((void *)STM32_SYSCLK_FREQUENCY);
|
||||
|
||||
up_perf_init((void *)STM32_SYSCLK_FREQUENCY);
|
||||
#endif
|
||||
|
||||
/* Perform early serial initialization */
|
||||
|
||||
#ifdef USE_EARLYSERIALINIT
|
||||
arm_earlyserialinit();
|
||||
|
||||
arm_earlyserialinit();
|
||||
#endif
|
||||
|
||||
/* Bring up NuttX */
|
||||
|
|
@ -196,8 +194,9 @@ The chip usually contains multiple serial ports, and one serial port is usually
|
|||
#### Code location
|
||||
|
||||
- Reference implementation:
|
||||
|
||||
- [stm32_serial.c](https://github.com/open-vela/nuttx/blob/41545a4ca98165813908e5fe25d3ecdbfc5ab19a/arch/arm/src/stm32f7/stm32_serial.c)
|
||||
- [stm32_lowputc.c](https://github.com/open-vela/nuttx/blob/41545a4ca98165813908)
|
||||
- [stm32_lowputc.c](https://github.com/open-vela/nuttx/blob/41545a4ca98165813908e5fe25d3ecdbfc5ab19a/arch/arm/src/stm32f7/stm32_lowputc.c)
|
||||
|
||||
- Serial port related implementations are generally located in:
|
||||
|
||||
|
|
@ -327,9 +326,9 @@ Here is the reference implementation of the `up_timer_initialize` function, loca
|
|||
|
||||
void up_timer_initialize(void)
|
||||
{
|
||||
struct oneshot_lowerhalf_s *lower = xxx_oneshot_initialize();
|
||||
struct oneshot_lowerhalf_s *lower = xxx_oneshot_initialize();
|
||||
|
||||
up_alarm_set_lowerhalf(lower);
|
||||
up_alarm_set_lowerhalf(lower);
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -10,9 +10,7 @@ This document describes how to use the **clang-format** tool for code style chec
|
|||
|
||||
Different checking commands are executed depending on whether the `.clang-format` configuration file exists in the project.
|
||||
|
||||
> Note
|
||||
>
|
||||
> The openvela project uses **clang-format 14** version for code style checking.
|
||||
> **Note**: The openvela project uses **clang-format 14** version for code style checking.
|
||||
|
||||
### Scenario 1: Checking with Default Configuration File
|
||||
|
||||
|
|
|
|||
|
|
@ -1,15 +1,19 @@
|
|||
# openvela Documentation Development Process
|
||||
|
||||
\[ English | [简体中文](../../../zh-cn/contribute/process/doc_dev_process.md) \]
|
||||
[ English | [简体中文](../../../zh-cn/contribute/process/doc_dev_process.md) ]
|
||||
|
||||
## What Development Engineers Should Do
|
||||
## Flowchart
|
||||
|
||||

|
||||
|
||||
## I. What Development Engineers Should Do
|
||||
|
||||
### 1. Develop Documentation
|
||||
|
||||
If you are responsible for developing a particular feature, you need to collaborate with the documentation team to ensure that the corresponding documentation for the feature is completed before the version is released. Otherwise, features without accompanying documentation might be removed during release.
|
||||
|
||||
1. Contact the [documentation team's technical writer](./doc_reviewer.md) to discuss documentation design.
|
||||
2. Refer to the [documentation templates](https://github.com/open-vela/docs/tree/dev/zh-cn/contribute/template) to write the accompanying documentation.
|
||||
2. Refer to the [documentation templates](../template/) to write the accompanying documentation.
|
||||
3. Draft detailed documentation for the feature, submit a PR, and include links to the relevant requirement `Issue` in the PR description.
|
||||
|
||||
### 2. Submit PR for Review
|
||||
|
|
@ -27,10 +31,11 @@ If you are responsible for developing a particular feature, you need to collabor
|
|||
|
||||
- Self-translation is recommended.
|
||||
- To request translation support from the documentation team, submit a translation request after the Chinese documentation is finalized (post-review and testing). Include the following:
|
||||
1. Add new terms to the [Glossary](../../overview/glossary.md).
|
||||
2. Provide English screenshots.
|
||||
|
||||
## What Documentation Engineers Should Do
|
||||
- Add new terms to the [Glossary](../../overview/glossary.md).
|
||||
- Provide English screenshots.
|
||||
|
||||
## II. What Documentation Engineers Should Do
|
||||
|
||||
### 1. Review Documentation
|
||||
|
||||
|
|
@ -43,8 +48,11 @@ If you are responsible for developing a particular feature, you need to collabor
|
|||
#### Information Architecture
|
||||
|
||||
- When adding a new Markdown page:
|
||||
|
||||
- Use the appropriate content template.
|
||||
|
||||
- When modifying an existing Markdown page:
|
||||
|
||||
- Verify that changes do not break links to other community content (local checks recommended).
|
||||
|
||||
### 2. Test Documentation
|
||||
|
|
|
|||
|
After Width: | Height: | Size: 82 KiB |
|
Before Width: | Height: | Size: 18 KiB |
|
|
@ -20,7 +20,7 @@
|
|||
|
||||
_【Writing Requirement】**Required**_
|
||||
|
||||
_**Content Introduction:** The role of this system/module in the entire OpenVela architecture, the functions it implements, usage scenarios, and supported devices._
|
||||
_**Content Introduction:** The role of this system/module in the entire openvela architecture, the functions it implements, usage scenarios, and supported devices._
|
||||
|
||||
_**Notes:**_
|
||||
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ When compiling your code with GCC, you must add the `-g` flag. For the most deta
|
|||
gcc -g3 -o my_program my_program.c
|
||||
```
|
||||
|
||||
In the openvela build system, you can enable debugging options via Kconfig, and the system will automatically add the appropriate flags for the compiler.
|
||||
In the **openvela** build system, you can enable debugging options via Kconfig, and the system will automatically add the appropriate flags for the compiler.
|
||||
|
||||
### 2. Installing GDB
|
||||
|
||||
|
|
@ -101,7 +101,7 @@ When the program is paused, these commands help you investigate the source of th
|
|||
| `info locals` | Displays all **local variables** in the current stack frame. |
|
||||
| `info args` | Displays all **function arguments** in the current stack frame. |
|
||||
| `info registers` | Displays the current values of all CPU **registers**. |
|
||||
| `info threads` | In a multi-threaded program (like `openvela`), displays all threads and their IDs. |
|
||||
| `info threads` | In a multi-threaded program (like openvela), displays all threads and their IDs. |
|
||||
| `thread <id>` | Switches to the context of the specified thread ID. |
|
||||
| `ptype <expr>` | Displays the **data structure definition** of a variable or type. For example:<br> `ptype struct my_struct`.<br>The `ptype /o <type>` command displays the complete memory layout for a specified type, detailing the offset and size of each member. |
|
||||
| `set var <name>=<value>` | **Modifies the value of a variable** at runtime. <br>For example, `set var i = 10`. When there is no ambiguity, you can use `set i = 10` |
|
||||
|
|
@ -133,14 +133,14 @@ This section applies theory to practice, showing how to use GDB to solve specifi
|
|||
|
||||
#### Problem Description
|
||||
|
||||
The program crashes unexpectedly on the sim environment or a development board, resulting in an ASan error, segmentation fault, or a hardware exception (such as a Data Abort or Prefetch Abort).
|
||||
The program crashes unexpectedly on the `sim` environment or a development board, resulting in an ASan error, segmentation fault, or a hardware exception (such as a Data Abort or Prefetch Abort).
|
||||
|
||||
#### Debugging Strategy
|
||||
|
||||
1. **Reproduce the Issue**: Start a debugging session with `gdb ./nuttx`, then type `r` to run the program until it crashes.
|
||||
2. **Locate the Crash Point**: GDB will automatically pause when the program crashes. Use the `bt` command to view the call stack. The top-most frame is usually the direct cause of the crash.
|
||||
3. **Analyze the Context**: Use `frame <num>` to switch to a suspicious stack frame. Then, use `p <var>` and `info locals` to inspect variable values at that time to determine the cause of the crash.
|
||||
4. **Analyze Hardware Exceptions**: For hardware exceptions, it is crucial to check the values of registers such as PC (Program Counter) and LR (Link Register) using `info registers`. Use `disassemble /m <PC_value>` to view the assembly instruction being executed at the time of the crash and its corresponding source code line.
|
||||
1. Reproduce the Issue: Start a debugging session with `gdb ./nuttx`, then type `r` to run the program until it crashes.
|
||||
2. Locate the Crash Point: GDB will automatically pause when the program crashes. Use the `bt` command to view the call stack. The top-most frame is usually the direct cause of the crash.
|
||||
3. Analyze the Context: Use `frame <num>` to switch to a suspicious stack frame. Then, use `p <var>` and `info locals` to inspect variable values at that time to determine the cause of the crash.
|
||||
4. Analyze Hardware Exceptions: For hardware exceptions, it is crucial to check the values of registers such as PC (Program Counter) and LR (Link Register) using `info registers`. Use `disassemble /m <PC_value>` to view the assembly instruction being executed at the time of the crash and its corresponding source code line.
|
||||
|
||||
### Scenario 2: Program Hangs or Deadlocks
|
||||
|
||||
|
|
@ -150,14 +150,14 @@ The terminal becomes unresponsive after the program starts, and CPU usage is hig
|
|||
|
||||
#### Debugging Strategy
|
||||
|
||||
1. **Interrupt the Program**:
|
||||
1. Interrupt the Program:
|
||||
|
||||
- If the program is running in the foreground, press `Ctrl + C` in GDB.
|
||||
- If the program is running in the background, find its PID with `ps`, then execute `sudo gdb attach <PID>`. The program will pause automatically upon attachment.
|
||||
- For the `sim` environment, you can also execute `pkill -SIGSTOP nuttx` in a new terminal to pause the process.
|
||||
|
||||
2. **Check All Threads**: Enter `info threads` to view the status of all threads. Check if any threads are in an abnormal state or are all waiting for the same resource.
|
||||
3. **Analyze Each Thread**: Use `thread <id>` to switch to each thread one by one, then use `bt` to view its call stack to determine what task it is performing. This can often quickly pinpoint the location of the infinite loop or deadlock.
|
||||
2. Check All Threads: Enter `info threads` to view the status of all threads. Check if any threads are in an abnormal state or are all waiting for the same resource.
|
||||
3. Analyze Each Thread: Use `thread <id>` to switch to each thread one by one, then use `bt` to view its call stack to determine what task it is performing. This can often quickly pinpoint the location of the infinite loop or deadlock.
|
||||
|
||||
### Scenario 3: Tracking Unintended Variable Modifications
|
||||
|
||||
|
|
@ -167,9 +167,9 @@ A global variable's value is being incorrectly modified at some point, but there
|
|||
|
||||
#### Debugging Strategy
|
||||
|
||||
1. **Set a Watchpoint**: After starting GDB, set a write watchpoint on the variable using `watch my_global_variable` or `watch *<address_of_variable>`.
|
||||
2. **Run and Wait**: Type `run` or `continue` to start or resume program execution. The program will pause immediately when the variable's value is modified.
|
||||
3. **Locate the Modifier**: GDB will report the old and new values of the variable and stop at the line of code that modified it. Use `bt` to view the call stack to find the code responsible for the change.
|
||||
1. Set a Watchpoint: After starting GDB, set a write watchpoint on the variable using `watch my_global_variable` or `watch *<address_of_variable>`.
|
||||
2. Run and Wait: Type `run` or `continue` to start or resume program execution. The program will pause immediately when the variable's value is modified.
|
||||
3. Locate the Modifier: GDB will report the old and new values of the variable and stop at the line of code that modified it. Use `bt` to view the call stack to find the code responsible for the change.
|
||||
|
||||
### Scenario 4: Analyzing Compiler-Optimized Variables
|
||||
|
||||
|
|
@ -243,8 +243,8 @@ For more information, see [Debugging with GDB - Command Files (gnu.org)](https:/
|
|||
|
||||
### 2. Related Debugging Practices
|
||||
|
||||
- **IDE Integration**: For instructions on how to configure GDB in VSCode to debug the `sim` environment, please refer to [Debugging the sim environment in VSCode]()
|
||||
- **Thread-Aware Debugging**: To better view `openvela` thread information in GDB, you can use J-Link's GDB plugin. For details, see [Enhancing openvela Thread Debugging with the J-Link GDB Plugin](../crash/JLINK/J_Link.md).
|
||||
- **IDE Integration**: For instructions on how to configure GDB in VSCode to debug the `sim` environment, please refer to [Debugging the sim environment in VSCode](./VSCODE_debugging.md)
|
||||
- **Thread-Aware Debugging**: To better view openvela thread information in GDB, you can use J-Link's GDB plugin. For details, see [Enhancing openvela Thread Debugging with the J-Link GDB Plugin](../crash/JLINK/J_Link.md).
|
||||
|
||||
## VII. Troubleshooting
|
||||
|
||||
|
|
@ -256,9 +256,11 @@ This is typically caused by an incompatibility between the Python version GDB de
|
|||
|
||||
#### Solution
|
||||
|
||||
1. **Confirm the Python Version GDB Needs**: The error message often indicates the required version (for example, `python3.8`).
|
||||
2. **Install the Corresponding Version**: Ensure this version of Python is installed on your system. You can refer to guides such as [How to Install and Switch Python Versions](https://www.rosehosting.com/blog/how-to-install-and-switch-python-versions-on-ubuntu-20-04/).
|
||||
3. **Configure `PYTHONHOME`**: If the problem persists after installation, try setting the `PYTHONHOME` environment variable to force GDB to use the correct Python interpreter.
|
||||
1. Confirm the Python Version GDB Needs: The error message often indicates the required version (for example, `python3.8`).
|
||||
|
||||
2. Install the Corresponding Version: Ensure this version of Python is installed on your system. You can refer to guides such as [How to Install and Switch Python Versions](https://www.rosehosting.com/blog/how-to-install-and-switch-python-versions-on-ubuntu-20-04/).
|
||||
|
||||
3. Configure `PYTHONHOME`: If the problem persists after installation, try setting the `PYTHONHOME` environment variable to force GDB to use the correct Python interpreter.
|
||||
|
||||
## VIII. References
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
## I. Overview
|
||||
|
||||
This guide provides a detailed explanation of how to configure and use GDB in Visual Studio Code (VSCode) for graphical debugging of the openvela `sim` simulation environment. VSCode offers a modern debugging experience, including setting breakpoints, viewing the call stack, and monitoring variables and memory, which significantly enhances development and troubleshooting efficiency.
|
||||
This guide provides a detailed explanation of how to configure and use GDB in Visual Studio Code (VSCode) for graphical debugging of the **openvela** `sim` simulation environment. VSCode offers a modern debugging experience, including setting breakpoints, viewing the call stack, and monitoring variables and memory, which significantly enhances development and troubleshooting efficiency.
|
||||
|
||||
**The core workflow includes:**
|
||||
|
||||
|
|
@ -21,7 +21,7 @@ Before you begin debugging, ensure your development environment meets the follow
|
|||
|
||||
- **Visual Studio Code**: Must be installed.
|
||||
- **C/C++ Extension**: The core plugin from Microsoft that provides C/C++ language support and debugging capabilities in VSCode.
|
||||
- **Compiled `sim` Target**: The `sim` version of `openvela` must be successfully compiled, generating an executable (`nuttx`) that includes debugging information. The compilation must include the `-g` or `-g3` flag.
|
||||
- **Compiled `sim` Target**: The `sim` version of openvela must be successfully compiled, generating an executable (`nuttx`) that includes debugging information. The compilation must include the `-g` or `-g3` flag.
|
||||
|
||||
### 2. VSCode Environment Setup
|
||||
|
||||
|
|
@ -31,9 +31,9 @@ In the VSCode Marketplace, search for `C/C++` (published by Microsoft) and click
|
|||
|
||||
#### Step 2: Open the Project Workspace
|
||||
|
||||
Launch VSCode and use the menu `File > Add Folder to Workspace...` to add your `openvela` project root directory. This ensures that VSCode correctly resolves the `${workspaceFolder}` variable in `launch.json`.
|
||||
Launch VSCode and use the menu `File > Add Folder to Workspace...` to add your openvela project root directory. This ensures that VSCode correctly resolves the `${workspaceFolder}` variable in `launch.json`.
|
||||
|
||||
## III. Debug Configuration (launch.json)
|
||||
## III. Debug Configuration (`launch.json`)
|
||||
|
||||
The `launch.json` file is the core configuration file for VSCode's debugging functionality. It defines how to launch and attach to your program.
|
||||
|
||||
|
|
@ -150,7 +150,7 @@ You can instruct GDB to ignore this signal by creating a global GDB initializati
|
|||
|
||||
3. Save the file. GDB will automatically load and execute the commands in this file every time it starts, thus resolving the issue.
|
||||
|
||||
### 2. Acquiring Root Privileges for sim
|
||||
### 2. Acquiring Root Privileges for `sim`
|
||||
|
||||
#### Scenario
|
||||
|
||||
|
|
@ -160,7 +160,7 @@ Certain advanced features of the `sim` environment, especially those related to
|
|||
|
||||
The recommended approach is to configure `sudo` to allow your user account to run gdb as root without a password.
|
||||
|
||||
1. **Configure passwordless `sudo`**.
|
||||
1. Configure passwordless `sudo`.
|
||||
|
||||
For security and best practice, we will create a dedicated configuration file in the `/etc/sudoers.d/` directory. This method is safer than directly modifying the main `sudoers` file.
|
||||
|
||||
|
|
@ -171,7 +171,7 @@ The recommended approach is to configure `sudo` to allow your user account to ru
|
|||
echo "your_username ALL=(ALL) NOPASSWD: /usr/bin/gdb" | sudo tee /etc/sudoers.d/gdb-nopasswd
|
||||
```
|
||||
|
||||
2. **Create a GDB wrapper script**.
|
||||
2. Create a GDB wrapper script.
|
||||
|
||||
In your project's root directory (for example, `openvela/`), create a file named `sudo-gdb.sh` and add the following content:
|
||||
|
||||
|
|
@ -187,9 +187,9 @@ The recommended approach is to configure `sudo` to allow your user account to ru
|
|||
chmod +x sudo-gdb.sh
|
||||
```
|
||||
|
||||
3. **Modify `launch.json`**.
|
||||
3. Modify `launch.json`.
|
||||
|
||||
Modify the `.vscode/launch.json` file by adding the `"miDebuggerPath"` property to your debug configuration, pointing it to the script we just created.
|
||||
Modify the `.vscode/launch.json` file by adding the `"miDebuggerPath"` property to your debug configuration, pointing it to the script we just created.
|
||||
|
||||
```json
|
||||
{
|
||||
|
|
|
|||
|
|
@ -0,0 +1,352 @@
|
|||
# Debugging Memory Errors with AddressSanitizer
|
||||
|
||||
\[ English | [简体中文](./../../../../../zh-cn/debugging_tools/crash/memory/heap/ASan.md) \]
|
||||
|
||||
AddressSanitizer (ASan) is a compiler-based, high-performance memory error detection tool that helps developers accurately find and diagnose various memory issues at runtime. This guide details how to enable and use ASan on the openvela `simulator` platform.
|
||||
|
||||
**Note**: The AddressSanitizer feature is currently supported only on the `simulator` platform.
|
||||
|
||||
## I. Overview
|
||||
|
||||
AddressSanitizer (ASan) is a part of the [Google Sanitizer Tools](https://github.com/google/sanitizers). It works by instrumenting code at compile time and linking a dedicated runtime library. This mechanism allows it to efficiently capture a wide range of memory errors with a moderate performance overhead.
|
||||
|
||||
ASan can detect the following common issues:
|
||||
|
||||
- **Out-of-Bounds Access**: Accessing heap, stack, or global variables beyond their legal boundaries.
|
||||
- **Use-after-Free**: Accessing memory that has already been deallocated by `free()` or `delete`.
|
||||
- **Use-after-Return**: Accessing local variables on a function's stack frame after the function has returned.
|
||||
- **Use-after-Scope**: Accessing a local variable whose lifetime has ended within its scope (`{}`).
|
||||
- **Double-Free**: Calling `free()` twice on the same memory block.
|
||||
- **Invalid-Free**: Freeing an invalid or unallocated memory address.
|
||||
- **Memory Leaks**: Detected by the integrated LeakSanitizer (LSan), which finds memory that has been allocated but is no longer accessible.
|
||||
- **Initialization-Order-Fiasco**: Detects C++ global variable initialization order issues across different translation units.
|
||||
|
||||
## II. How ASan Works
|
||||
|
||||
ASan primarily relies on two components working together: the **compiler instrumentation** module and the **runtime library**.
|
||||
|
||||
### 1. Compiler Instrumentation
|
||||
|
||||
When ASan is enabled, the compiler automatically inserts check code before and after every memory access (read/write) in the program to verify its validity. The effect is illustrated below:
|
||||
|
||||

|
||||
|
||||
### 2. Runtime Library
|
||||
|
||||
The ASan runtime library (`libasan`) intercepts standard memory management functions (like `malloc` and `free`) and introduces **Shadow Memory** and **Memory Poisoning** mechanisms.
|
||||
|
||||
- **Shadow Memory**: ASan reserves a portion of the virtual address space as shadow memory. Each byte in the shadow memory describes the state of the corresponding 8 bytes in the main application memory (e.g., inaccessible, fully accessible, or partially accessible).
|
||||
|
||||
- **Memory Poisoning**:
|
||||
|
||||
- **On Allocation**: When `malloc` is called to allocate memory, the ASan runtime library allocates extra "Redzones" around the requested memory region. These redzones, along with any padding bytes from alignment, are marked as "poisoned." Any access to them is immediately reported as an error.
|
||||
- **On Deallocation**: When `free` is called, the entire memory region (including the original valid area and the redzones) is marked as "poisoned" and placed in a quarantine queue. This memory is not immediately reused, which effectively detects "use-after-free" errors.
|
||||
|
||||

|
||||
|
||||
### 3. Detection Algorithm
|
||||
|
||||
For each memory access, the compiler-inserted check code executes the following pseudo-code logic:
|
||||
|
||||
1. Calculates the corresponding shadow memory address `ShadowAddr` based on the access address `Addr`.
|
||||
2. Reads the value of the shadow byte `k`, which describes the state of the 8-byte aligned block containing `Addr`.
|
||||
3. Checks if the access is valid:
|
||||
|
||||
- If `k` is `0`, all 8 bytes are accessible.
|
||||
- If `k` is negative, the entire 8-byte block is inaccessible (e.g., a redzone or freed memory).
|
||||
- If `k` is positive (`1` to `7`), the first `k` bytes are accessible.
|
||||
- If the access crosses the boundary defined by `k`, it is flagged as a memory error.
|
||||
|
||||
```C
|
||||
// Pseudo-code for the detection logic
|
||||
ShadowAddr = (Addr >> 3) + Offset; // Calculate shadow address
|
||||
k = *ShadowAddr; // Read the shadow byte
|
||||
if (k != 0 && ((Addr & 7) + AccessSize > k)) {
|
||||
ReportAndCrash(Addr); // If the access is invalid, report an error and crash
|
||||
}
|
||||
```
|
||||
|
||||
## III. How to Use ASan in openvela
|
||||
|
||||
Enabling ASan on the `simulator` platform is a simple three-step process.
|
||||
|
||||
### Step 1: Enable the ASan Configuration
|
||||
|
||||
Enable the following Kconfig option via `menuconfig` or by directly modifying the `.config` file:
|
||||
|
||||
```Makefile
|
||||
# Enable Address Sanitizer for the sim platform
|
||||
CONFIG_SIM_ASAN=y
|
||||
```
|
||||
|
||||
**Note**: Enabling this option automatically adds the `-fsanitize=address` flag to the compiler and linker. To get clearer stack traces, the `-fno-omit-frame-pointer` flag is also typically included.
|
||||
|
||||
### Step 2: Compile and Run
|
||||
|
||||
Follow the standard compilation process, then start the `simulator` to run your application.
|
||||
|
||||
```Bash
|
||||
# Example of running the simulator
|
||||
./emulator.sh vela
|
||||
```
|
||||
|
||||
### Step 3: Analyze the Error Report
|
||||
|
||||
If ASan detects a memory error, the program will terminate immediately and print a detailed report. A typical ASan report contains the following key information:
|
||||
|
||||
```Bash
|
||||
# 1. Error Summary: Indicates the error type (heap-use-after-free) and the illegal access address.
|
||||
==9901==ERROR: AddressSanitizer: heap-use-after-free on address 0x60700000dfb5
|
||||
|
||||
# 2. Access Details and Stack Trace: Shows the illegal memory operation (READ of size 1) and where it occurred.
|
||||
READ of size 1 at 0x60700000dfb5 thread T0
|
||||
#0 0x45917a in main use-after-free.c:5
|
||||
#1 0x7fce9f25e76c in __libc_start_main ...
|
||||
|
||||
# 3. Memory Location Description: Explains which memory region the illegal address is in.
|
||||
0x60700000dfb5 is located 5 bytes inside of 80-byte region [0x60700000dfb0,0x60700000e000)
|
||||
|
||||
# 4. Deallocation Stack Trace: (If applicable) Shows where the memory block was freed.
|
||||
freed by thread T0 here:
|
||||
#0 0x4441ee in __interceptor_free ...
|
||||
#1 0x45914a in main use-after-free.c:4
|
||||
|
||||
# 5. Allocation Stack Trace: Shows where the memory block was originally allocated.
|
||||
previously allocated by thread T0 here:
|
||||
#0 0x44436e in __interceptor_malloc ...
|
||||
#1 0x45913f in main use-after-free.c:3
|
||||
|
||||
# 6. Final Summary: A concise summary of the entire error.
|
||||
SUMMARY: AddressSanitizer: heap-use-after-free use-after-free.c:5 main
|
||||
```
|
||||
|
||||
## IV. Common Error Types and Examples
|
||||
|
||||
The following are several typical memory errors that ASan can detect.
|
||||
|
||||
### 1. Heap-Use-after-Free
|
||||
|
||||
**Scenario**: Accessing heap memory that has already been deallocated by `free` or `delete`.
|
||||
|
||||
**Example Code**:
|
||||
|
||||
```C
|
||||
5 int main (int argc, char** argv)
|
||||
6 {
|
||||
7 int* array = new int[100];
|
||||
8 delete []array;
|
||||
9 return array[1]; // <-- ERROR: Accessing freed memory
|
||||
10 }
|
||||
```
|
||||
|
||||
**Error Report Summary**:
|
||||
|
||||
```Bash
|
||||
==3189==ERROR: AddressSanitizer: heap-use-after-free on address 0x61400000fe44
|
||||
...
|
||||
freed by thread T0 here:
|
||||
#1 0x4008b5 in main /home/ron/dev/as/use_after_free.cpp:8
|
||||
previously allocated by thread T0 here:
|
||||
#1 0x40089e in main /home/ron/dev/as/use_after_free.cpp:7
|
||||
```
|
||||
|
||||
### 2. Heap-Buffer-Overflow
|
||||
|
||||
**Scenario**: Accessing a heap-allocated memory region beyond its boundaries.
|
||||
|
||||
**Example Code**:
|
||||
|
||||
```C
|
||||
2 int main (int argc, char** argv)
|
||||
3 {
|
||||
4 int* array = new int[100];
|
||||
5 int res = array[100]; // <-- ERROR: Accessing the 101st element, out of bounds
|
||||
6 delete [] array;
|
||||
7 return res;
|
||||
8 }
|
||||
```
|
||||
|
||||
**Error Report Summary**:
|
||||
|
||||
```Bash
|
||||
==3322==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61400000ffd0
|
||||
...
|
||||
0x61400000ffd0 is located 0 bytes to the right of 400-byte region [0x61400000fe40,0x61400000ffd0)
|
||||
allocated by thread T0 here:
|
||||
#1 0x40089e in main /home/ron/dev/as/heap_buf_overflow.cpp:4
|
||||
```
|
||||
|
||||
### 3. Stack-Buffer-Overflow
|
||||
|
||||
**Scenario**: Accessing a stack-allocated local variable beyond its boundaries.
|
||||
|
||||
**Example Code**:
|
||||
|
||||
```C
|
||||
2 int main (int argc, char** argv)
|
||||
3 {
|
||||
4 int array[100];
|
||||
5 return array[100]; // <-- ERROR: Accessing the 101st element, out of bounds
|
||||
6 }
|
||||
```
|
||||
|
||||
**Error Report Summary**:
|
||||
|
||||
```Bash
|
||||
==3389==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffd061fa4a0
|
||||
...
|
||||
Address 0x7ffd061fa4a0 is located in stack of thread T0 at offset 432 in frame
|
||||
#0 0x400935 in main /home/ron/dev/as/stack_buf_overflow.cpp:3
|
||||
This frame has 1 object(s):
|
||||
[32, 432) 'array' <== Memory access at offset 432 overflows this variable
|
||||
```
|
||||
|
||||
### 4. Global-Buffer-Overflow
|
||||
|
||||
**Scenario**: Accessing a global or static variable beyond its boundaries.
|
||||
|
||||
**Example Code**:
|
||||
|
||||
```C
|
||||
2 int array[100];
|
||||
3
|
||||
4 int main (int argc, char** argv)
|
||||
5 {
|
||||
6 return array[100]; // <-- ERROR: Accessing the 101st element, out of bounds
|
||||
7 }
|
||||
```
|
||||
|
||||
**Error Report Summary**:
|
||||
|
||||
```Bash
|
||||
==3499==ERROR: AddressSanitizer: global-buffer-overflow on address 0x000000601270
|
||||
...
|
||||
0x000000601270 is located 0 bytes to the right of global variable 'array' defined in '...'
|
||||
```
|
||||
|
||||
### 5. Use-after-Return
|
||||
|
||||
**Scenario**: After a function returns, its stack frame is destroyed, but the program still accesses a local variable on that stack via a pointer.
|
||||
|
||||
**Example Code**:
|
||||
|
||||
```C
|
||||
int *ptr;
|
||||
__attribute__((noinline))
|
||||
void FunctionThatEscapesLocalObject() {
|
||||
int local[100];
|
||||
ptr = &local[0]; // ptr points to a local variable that is about to be destroyed
|
||||
}
|
||||
|
||||
int main(int argc, char **argv) {
|
||||
FunctionThatEscapesLocalObject();
|
||||
return ptr[argc]; // <-- ERROR: Accessing invalid stack memory
|
||||
}
|
||||
```
|
||||
|
||||
**Error Report Summary**:
|
||||
|
||||
```Bash
|
||||
==6268== ERROR: AddressSanitizer: stack-use-after-return on address 0x7fa19a8fc024
|
||||
```
|
||||
|
||||
### 6. Use-after-Scope
|
||||
|
||||
**Scenario**: A variable's lifetime ends within a scope (`{...}`), but it is still accessed from outside that scope.
|
||||
|
||||
**Example Code**:
|
||||
|
||||
```C
|
||||
volatile int *p = 0;
|
||||
|
||||
int main() {
|
||||
{
|
||||
int x = 0;
|
||||
p = &x;
|
||||
} // The scope of x ends here
|
||||
*p = 5; // <-- ERROR: Accessing invalid stack memory
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
|
||||
**Error Report Summary**:
|
||||
|
||||
```Bash
|
||||
==58237==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffc4d830880
|
||||
```
|
||||
|
||||
### 7. Initialization-Order-Fiasco
|
||||
|
||||
**Scenario**: This issue occurs mainly in C++. It happens when the initialization of a global variable in one translation unit (`.cpp` file) depends on another global variable in a different unit that has not yet been initialized.
|
||||
|
||||
**Example**:
|
||||
|
||||
```C++
|
||||
// a.cc
|
||||
extern int extern_global;
|
||||
int x = extern_global + 1; // <-- ERROR: Reading extern_global before it is initialized
|
||||
```
|
||||
|
||||
```C++
|
||||
// b.cc
|
||||
int extern_global = 42;
|
||||
```
|
||||
|
||||
**Error Report Summary**:
|
||||
|
||||
```Bash
|
||||
==ERROR: AddressSanitizer: initialization-order-fiasco on address 0x...
|
||||
READ of size 4 at 0x...
|
||||
... is located 0 bytes inside of global variable 'extern_global' from 'b.cc'
|
||||
```
|
||||
|
||||
### 8. Memory Leak
|
||||
|
||||
**Scenario**: Heap memory allocated (via `malloc` or `new`) is not properly deallocated when no longer needed, leading to a gradual increase in memory consumption. This feature is provided by LeakSanitizer (LSan), which is integrated with ASan by default.
|
||||
|
||||
**Example Code**:
|
||||
|
||||
```C
|
||||
4 void* p;
|
||||
5
|
||||
6 int main ()
|
||||
7 {
|
||||
8 p = malloc (7);
|
||||
9 p = 0; // <-- ERROR: The original pointer is lost, leaking 7 bytes of memory
|
||||
10 return 0;
|
||||
11 }
|
||||
```
|
||||
|
||||
**Error Report Summary**:
|
||||
|
||||
```Bash
|
||||
==4088==ERROR: LeakSanitizer: detected memory leaks
|
||||
|
||||
Direct leak of 7 byte(s) in 1 object(s) allocated from:
|
||||
#0 0x7ff9ae510602 in malloc (...)
|
||||
#1 0x4008d3 in main /home/ron/dev/as/mem_leak.cpp:8
|
||||
```
|
||||
|
||||
**Note on Memory Leak Detection in RTOS Environments**
|
||||
|
||||
- In an RTOS like openvela, when a task exits, the memory it dynamically allocated is typically not automatically reclaimed by the system. This differs from the behavior of processes in desktop operating systems.
|
||||
|
||||
- LeakSanitizer detects leaks by tracking whether a pointer is lost. If a pointer is still reachable when the task ends, LSan may not report it as a leak, even if the memory has not been freed.
|
||||
|
||||
- Therefore, developers must ensure that all dynamically allocated memory is explicitly freed when it is no longer needed.
|
||||
|
||||
## V. Advanced Debugging with GDB
|
||||
|
||||
When ASan detects an error and terminates the program, you might want to perform interactive debugging at the exact point of failure. To do this, you can set a breakpoint on ASan's reporting function in GDB. Use the following command in GDB:
|
||||
|
||||
```C
|
||||
# Set a breakpoint at ASan's error reporting function
|
||||
b __asan::ReportGenericError
|
||||
```
|
||||
|
||||
When the program triggers a memory error, execution will halt at the breakpoint. At this point, you can use standard GDB commands (like `bt`, `p`, and `info locals`) to inspect the call stack, variable values, and program state, allowing for a more in-depth analysis of the problem's root cause.
|
||||
|
||||
## VI. References
|
||||
|
||||
- **Google Sanitizers Project Wiki**: [https://github.com/google/sanitizers/wiki/AddressSanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizer)
|
||||
- **Clang Documentation on AddressSanitizer**: [https://clang.llvm.org/docs/AddressSanitizer.html](https://clang.llvm.org/docs/AddressSanitizer.html)
|
||||
|
After Width: | Height: | Size: 302 KiB |
|
After Width: | Height: | Size: 64 KiB |
|
After Width: | Height: | Size: 148 KiB |
|
|
@ -4,7 +4,7 @@
|
|||
|
||||
This document provides guidance on enabling and using the **Allsyms** feature in the openvela system. By enabling this feature, you can compile a complete symbol table into the firmware image, enabling the system to resolve function addresses into human-readable function names during runtime. This enhances on-device debugging efficiency, especially for analyzing crash stacks.
|
||||
|
||||
## Prerequisites
|
||||
## I. Prerequisites
|
||||
|
||||
Before compiling firmware that includes the **Allsyms** feature, you must ensure the following Python packages are installed in your development environment. The build system uses these tools to parse **ELF** files and generate the symbol table.
|
||||
|
||||
|
|
@ -14,7 +14,7 @@ Run the following command in your terminal to install them:
|
|||
pip3 install pyelftools cxxfilt
|
||||
```
|
||||
|
||||
## How to Enable Allsyms
|
||||
## II. How to Enable Allsyms
|
||||
|
||||
> **Warning**
|
||||
>
|
||||
|
|
@ -30,15 +30,15 @@ The underlying implementation for this feature is located at the following path
|
|||
|
||||
`nuttx/libs/libc/symtab`
|
||||
|
||||
## Usage
|
||||
## III. Usage
|
||||
|
||||
After enabling **Allsyms**, you can utilize the symbol table for debugging in the following ways.
|
||||
|
||||
### Automatically Display Function Names in Backtraces
|
||||
### 1. Automatically Display Function Names in Backtraces
|
||||
|
||||
This is the primary use case for **Allsyms**. When the system crashes or you manually call functions like `dumpstack` or `sched_dumpstack`, the printed backtrace will no longer show raw addresses. Instead, it will display the resolved function names, helping you to locate issues quickly.
|
||||
|
||||
### Format Symbol Output in printf
|
||||
### 2. Format Symbol Output in `printf`
|
||||
|
||||
You can use the `%pS` format specifier in `printf-family` functions to directly print the symbol information corresponding to a specific address. If a matching symbol is not found, the system will print the original address.
|
||||
|
||||
|
|
@ -54,18 +54,18 @@ void my_debug_function(void)
|
|||
}
|
||||
```
|
||||
|
||||
### Manually Query Symbols Using APIs
|
||||
### 3. Manually Query Symbols Using APIs
|
||||
|
||||
openvela provides two core APIs that allow you to convert between function names and addresses in your code:
|
||||
|
||||
- `allsyms_findbyname()`: Finds the address of a function based on its name.
|
||||
- `allsyms_findbyvalue()`: Finds the closest function name based on an address.
|
||||
|
||||
## API Reference
|
||||
## IV. API Reference
|
||||
|
||||
The following are the core data structures and function prototypes related to the **Allsyms** feature.
|
||||
|
||||
### `struct symtab_s`
|
||||
### 1. `struct symtab_s`
|
||||
|
||||
This structure defines a single entry in the symbol table.
|
||||
|
||||
|
|
@ -91,7 +91,7 @@ struct symtab_s
|
|||
};
|
||||
```
|
||||
|
||||
### `allsyms_findbyname()`
|
||||
### 2. `allsyms_findbyname()`
|
||||
|
||||
Finds a symbol table entry by its name.
|
||||
|
||||
|
|
@ -112,7 +112,7 @@ FAR const struct symtab_s *allsyms_findbyname(FAR const char *name,
|
|||
FAR size_t *size);
|
||||
```
|
||||
|
||||
### `allsyms_findbyvalue()`
|
||||
### 3. `allsyms_findbyvalue()`
|
||||
|
||||
Finds a symbol table entry by its value (address).
|
||||
|
||||
|
|
@ -136,9 +136,9 @@ FAR const struct symtab_s *allsyms_findbyvalue(FAR void *value,
|
|||
FAR size_t *size);
|
||||
```
|
||||
|
||||
## FAQ
|
||||
## V. FAQ
|
||||
|
||||
### Compile-time error indicates missing `elftools` or `cxxfilt` modules
|
||||
### 1. Compile-time error indicates missing `elftools` or `cxxfilt` modules
|
||||
|
||||
#### Problem Description
|
||||
|
||||
|
|
@ -146,12 +146,12 @@ FAR const struct symtab_s *allsyms_findbyvalue(FAR void *value,
|
|||
|
||||
#### Cause Analysis
|
||||
|
||||
This error occurs because the build process for the **Allsyms** feature relies on these two Python tools to process ELF files and extract symbol information.
|
||||
This error occurs because the build process for the **Allsyms** feature relies on these two Python tools to process **ELF** files and extract symbol information.
|
||||
|
||||
#### Solution
|
||||
|
||||
Please refer to the [Prerequisites](#prerequisites) section of this document and use the `pip3` command to install them.
|
||||
|
||||
## Related Documents
|
||||
## VI. Related Documents
|
||||
|
||||
- [Backtrace Usage Guide](./backtrace.md)
|
||||
|
|
|
|||
|
|
@ -96,7 +96,7 @@ CONFIG_FRAME_POINTER=y
|
|||
CONFIG_SCHED_BACKTRACE=y
|
||||
```
|
||||
|
||||
For more information, refer to: [RISC-V Backtrace Implementation](../../../../../../nuttx/blob/dev/arch/risc-v/src/common/riscv_backtrace.c).
|
||||
For more information, refer to: [RISC-V Backtrace Implementation](../../../../../../nuttx/blob/trunk-5.5/arch/risc-v/src/common/riscv_backtrace.c).
|
||||
|
||||
### 4. Xtensa
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,96 @@
|
|||
# Using Dhrystone to Evaluate CPU Integer Performance
|
||||
|
||||
\[ English | [简体中文](./../../../../zh-cn/debugging_tools/performance/Benchmark/Dhrystone.md) \]
|
||||
|
||||
## I. Overview
|
||||
|
||||
Dhrystone is an industry-standard benchmark program specifically designed to evaluate a processor's integer and logical operation performance. It simulates typical program behavior by executing a predefined series of computationally intensive operations that do not involve floating-point calculations.
|
||||
|
||||
The test results are typically measured using two key metrics:
|
||||
|
||||
- **Dhrystones per Second**: Represents the number of times the processor can complete the main Dhrystone loop in one second. A higher value indicates better performance.
|
||||
- **DMIPS (Dhrystone Million Instructions Per Second)**: A standardized performance metric derived by comparing the **Dhrystones per Second** value against a baseline (the performance of a VAX 11/780 computer). It provides a relative performance reference across different platforms and architectures.
|
||||
|
||||
## II. Enabling Dhrystone
|
||||
|
||||
To use the Dhrystone benchmark tool, you must set the following Kconfig option in your openvela board-level configuration file.
|
||||
|
||||
```Makefile
|
||||
# Enable the Dhrystone benchmark
|
||||
CONFIG_BENCHMARK_DHRYSTONE=y
|
||||
```
|
||||
|
||||
## III. Executing the Test
|
||||
|
||||
After configuring and compiling the firmware, you can run the test in the openvela NSH (NuttShell) terminal.
|
||||
|
||||
### Command
|
||||
|
||||
In the terminal, execute the following command to start the test:
|
||||
|
||||
```Bash
|
||||
dhrystone
|
||||
```
|
||||
|
||||
### Sample Output
|
||||
|
||||
The program first attempts a small number of runs. If the execution time is too short, it automatically increases the number of runs to obtain a more accurate measurement. After the test completes, it prints the final performance data.
|
||||
|
||||
```Bash
|
||||
nsh> dhrystone
|
||||
|
||||
Dhrystone Benchmark, Version C, Version 2.2
|
||||
Program compiled without 'register' attribute
|
||||
Using MSC clock(), HZ=100
|
||||
|
||||
Trying 50000 runs through Dhrystone:
|
||||
Measured time too small to obtain meaningful results
|
||||
|
||||
Trying 500000 runs through Dhrystone:
|
||||
Final values of the variables used in the benchmark:
|
||||
|
||||
Int_Glob: 5
|
||||
should be: 5
|
||||
Bool_Glob: 1
|
||||
should be: 1
|
||||
... (Detailed intermediate variable verification output omitted) ...
|
||||
Str_2_Loc: DHRYSTONE PROGRAM, 2'ND STRING
|
||||
should be: DHRYSTONE PROGRAM, 2'ND STRING
|
||||
|
||||
Microseconds for one run through Dhrystone: 8.5
|
||||
Dhrystones per Second: 117647
|
||||
```
|
||||
|
||||
## IV. Interpreting the Results
|
||||
|
||||
After the test is complete, the program outputs detailed verification data and two key performance metrics.
|
||||
|
||||
### Key Performance Metrics
|
||||
|
||||
| **Metric** | **Description** |
|
||||
| :------------------------------------------- | :------------------------------------------------------------------------------------------- |
|
||||
| `Microseconds for one run through Dhrystone` | The average time required to execute one main Dhrystone loop, measured in microseconds (µs). |
|
||||
| `Dhrystones per Second` | The number of main Dhrystone loops the processor can execute per second. |
|
||||
|
||||
### Calculating DMIPS
|
||||
|
||||
DMIPS is a more valuable standardized metric. It compares the test results with the performance of a VAX 11/780 computer (defined as 1 MIPS), which has a Dhrystone score of **1757** Dhrystones/sec.
|
||||
|
||||
You can use the following formula to convert the test result to DMIPS:
|
||||
|
||||
**DMIPS = Dhrystones per Second / 1757**
|
||||
|
||||
Based on the sample output above:
|
||||
|
||||
- **Dhrystones per Second** = 117647
|
||||
- **DMIPS** = 117647 / 1757 ≈ **66.96**
|
||||
|
||||
#### Normalized Performance (DMIPS/MHz)
|
||||
|
||||
To make a fair comparison between processors with different clock frequencies, **DMIPS/MHz** is often used as a normalized metric.
|
||||
|
||||
**DMIPS/MHz = DMIPS / Processor Clock Frequency (MHz)**
|
||||
|
||||
For example, if the processor runs at 100 MHz, its normalized performance is:
|
||||
|
||||
- **DMIPS/MHz** = 66.96 / 100 ≈ **0.67**
|
||||
|
|
@ -0,0 +1,107 @@
|
|||
# A Guide to the CacheSpeed Tool
|
||||
|
||||
\[ English | [简体中文](./../../../../zh-cn/debugging_tools/performance/Benchmark/cachespeed.md) \]
|
||||
|
||||
## I. Overview
|
||||
|
||||
`cachespeed` is a command-line benchmark tool designed to precisely measure the performance of cache operations in the openvela system. It quantifies the execution time of `invalidate`, `flush`, and `clean` operations on the Instruction Cache (I-Cache) and Data Cache (D-Cache). To provide comprehensive performance data, the tool covers both memory-aligned and unaligned test scenarios.
|
||||
|
||||
### Technical Terminology Explained
|
||||
|
||||
- **`clean` (Write back)**: Writes modified ("dirty") data from the cache back to main memory, but the data remains in the cache.
|
||||
- **`invalidate`**: Marks data in the cache as invalid without writing it back to main memory. The next time this data is accessed, the CPU is forced to reload it from main memory.
|
||||
- **`flush`**: Typically a combination of `clean` and `invalidate`. It first writes dirty data back to main memory and then invalidates the corresponding cache line.
|
||||
|
||||
### Target Audience
|
||||
|
||||
This document is intended for developers who need to perform performance analysis and optimization on the openvela Real-Time Operating System (RTOS), including:
|
||||
|
||||
- **System Performance Engineers**: Responsible for evaluating and tuning overall system performance.
|
||||
- **Embedded Kernel Developers**: Responsible for developing or maintaining low-level code related to memory management and processor architecture.
|
||||
- **Board Support Package (BSP) Engineers**: Responsible for porting openvela to new hardware platforms and verifying its performance.
|
||||
|
||||
## II. Prerequisites
|
||||
|
||||
The tool relies on the `up_perf_gettime()` function for high-precision timing. Before running the test, you must ensure that the system's performance counter is correctly configured.
|
||||
|
||||
For platforms based on the ARMv8-M architecture, you need to enable the Cycle Counter by setting the following registers. Typically, you can execute these commands in a debugger or a system startup script.
|
||||
|
||||
```Plain
|
||||
// Example: Please verify based on your target chip's specifications.
|
||||
mw 0xe000edfc=0x01100000
|
||||
mw 0xe0001000=0x48000001
|
||||
```
|
||||
|
||||
## III. Build Configuration
|
||||
|
||||
To ensure the accuracy of the benchmark results, apply the following settings in your build configuration file. These configurations minimize system overhead that could interfere with the test.
|
||||
|
||||
```Makefile
|
||||
# --- Performance & Optimization ---
|
||||
DEBUG_CUSTOMOPT=y # Enable custom optimization options
|
||||
DEBUG_OPTLEVEL=-O3 # Set compiler optimization level to -O3 to ensure code runs with maximum efficiency
|
||||
|
||||
# --- Disable Monitoring & Security Checks ---
|
||||
CONFIG_SCHED_INSTRUMENTATION=n # Disable scheduler instrumentation
|
||||
CONFIG_SCHED_IRQMONITOR=n # Disable interrupt monitoring
|
||||
CONFIG_SCHED_CRITMONITOR=n # Disable critical section monitoring
|
||||
CONFIG_STACK_CANARIES=n # Disable stack canaries. This option has a significant impact on performance,
|
||||
# especially in short function call scenarios, potentially causing a performance gap of up to 3x.
|
||||
CONFIG_WATCHDOG=n # Disable the watchdog to prevent system resets during long tests
|
||||
|
||||
# --- Enable Test Tool ---
|
||||
CONFIG_BENCHMARK_CACHESPEED=y # Compile the cachespeed tool
|
||||
```
|
||||
|
||||
## IV. Running the Test
|
||||
|
||||
The source code for this tool is located in the `apps/benchmarks/cachespeed` directory. Execute the `cachespeed` command in the system shell to run the test.
|
||||
|
||||
### Example Output
|
||||
|
||||
```Bash
|
||||
cachespeed
|
||||
CACHE Speed: address src: 38506ec0
|
||||
** dcache invalidate [rate, avg, cost] in nanoseconds(bytes/nesc) align **
|
||||
64 Bytes: 0.045714, 1400, 14000
|
||||
128 Bytes: 0.116364, 1100, 11000
|
||||
192 Bytes: 0.128000, 1500, 15000
|
||||
256 Bytes: 0.182857, 1400, 14000
|
||||
320 Bytes: 0.213333, 1500, 15000
|
||||
384 Bytes: 0.256000, 1500, 15000
|
||||
448 Bytes: 0.320000, 1400, 14000
|
||||
...
|
||||
```
|
||||
|
||||
## V. Interpreting the Results
|
||||
|
||||
The test process typically starts with a single cache line size and progressively increases the data block size until it approaches or exceeds the cache capacity. **Focus on the `avg` value during analysis**; `rate` and `cost` provide supplementary perspectives but can be easily influenced by sample size and measurement methods.
|
||||
|
||||
The meaning of each column in the output is as follows:
|
||||
|
||||
| **Metric** | **Unit** | **Description** |
|
||||
| :--------- | :--------------- | :----------------------------------------------------------------------------- |
|
||||
| `rate` | bytes/nanosecond | The processing rate, calculated as `(test data size) / avg`. |
|
||||
| `avg` | nanoseconds | **(Key Metric)** The average time taken to perform a single cache operation. |
|
||||
| `cost` | nanoseconds | The total time taken to complete all test iterations for a specific data size. |
|
||||
|
||||
## VI. How It Works
|
||||
|
||||
Understanding the underlying mechanisms of cache operations will help you correctly interpret the performance data.
|
||||
|
||||
### 1. Invalidate
|
||||
|
||||
- **Observation**: The `invalidate` operation's rate (`rate`) typically increases as the test data size grows.
|
||||
- **Reasoning**: The core overhead of an `invalidate` operation (e.g., the CPU finding the cache tag and marking it as invalid) is relatively fixed and has little to do with the size of the data block being invalidated. When this relatively fixed time (`avg`) is used to process a larger data block (`size`), the calculated average rate (`rate = size / avg`) naturally increases.
|
||||
|
||||
### 2. Clean & Flush
|
||||
|
||||
- **Observation**: When the size of the test data exceeds the total capacity of the physical D-Cache, the average time (`avg`) for `clean` and `flush` operations tends to stabilize.
|
||||
- **Reasoning**: `clean` and `flush` operations need to write dirty (modified) data from the cache back to main memory. Once the test data is too large to fit entirely in the cache, the performance bottleneck shifts from the cache's internal execution speed to the much slower **memory bus bandwidth**. Since the bus bandwidth is fixed, the rate at which the system writes data back to main memory becomes constant. Consequently, the average time per operation (`avg`) no longer changes significantly with increasing data size.
|
||||
|
||||
Conclusion: When analyzing the `cachespeed` output, focus on `avg` and perform root cause analysis by considering the target platform's cache size, cache line size, and memory bandwidth.
|
||||
|
||||
## VII. Further Reading
|
||||
|
||||
- [ARM Architecture Reference Manual (ARMv8-M)](https://developer.arm.com/documentation/ddi0553/latest/)
|
||||
- Consult this manual to find authoritative technical specifications for low-level hardware modules such as the Data Watchpoint and Trace unit (DWT) and cache controllers.
|
||||
|
|
@ -0,0 +1,73 @@
|
|||
# Executing the CoreMark Benchmark
|
||||
|
||||
\[ English | [简体中文](./../../../../zh-cn/debugging_tools/performance/Benchmark/coremark.md) \]
|
||||
|
||||
## I. Overview
|
||||
|
||||
CoreMark is an industry-standard benchmark designed specifically to measure the performance of a central processing unit (CPU) in embedded systems. It was developed in 2009 by Shay Gal-on of the EEMBC (Embedded Microprocessor Benchmark Consortium) to provide a more realistic and comprehensive performance evaluation standard than Dhrystone.
|
||||
|
||||
The benchmark is written entirely in C, and its workload primarily simulates common operations that a CPU performs in real-world applications. It includes the following core algorithms:
|
||||
|
||||
- **List Processing:** Involves finding, sorting, inserting, and deleting items in a linked list.
|
||||
- **Matrix Manipulation:** Performs common operations such as matrix multiplication.
|
||||
- **State Machine:** Processes an input data stream through state transitions.
|
||||
- **Cyclic Redundancy Check (CRC):** Calculates a checksum on the data to verify the correctness of the results from the preceding algorithms.
|
||||
|
||||
## II. Enabling the Feature
|
||||
|
||||
You can enable the CoreMark feature by setting the following Kconfig option:
|
||||
|
||||
```Makefile
|
||||
CONFIG_BENCHMARK_COREMARK=y
|
||||
```
|
||||
|
||||
## III. Executing the Test
|
||||
|
||||
CoreMark can be used to evaluate the core performance of both single-core and multi-core processors. After enabling the feature and compiling the firmware, you can run the test directly in the openvela shell.
|
||||
|
||||
```Bash
|
||||
ap> coremark
|
||||
2K performance run parameters for coremark.
|
||||
CoreMark Size : 666
|
||||
Total ticks : 207740
|
||||
Total time (secs): 20.774000
|
||||
Iterations/Sec : 529.508039
|
||||
Iterations : 11000
|
||||
Compiler version : GCC11.3.1 20220712
|
||||
Compiler flags : -Wstrict-prototypes -nostdlib -pipe -O3 -fno-strict-aliasing -fomit-frame-pointer -mthumb -Wa,-mthumb -Wa,-mimplicit-it=always -fno-common -Wall -Wshadow -x
|
||||
Memory location : Please put data memory location here
|
||||
(e.g. code in flash, data on heap, etc)
|
||||
seedcrc : 0xe9f5
|
||||
[0]crclist : 0xe714
|
||||
[0]crcmatrix : 0x1fd7
|
||||
[0]crcstate : 0x8e3a
|
||||
[0]crcfinal : 0x33ff
|
||||
Correct operation validated. See README.md for run and reporting rules.
|
||||
CoreMark 1.0 : 529.508039 / GCC11.3.1 20220712 -Wstrict-prototypes -nostdlib -pipe -O3 -fno-strict-aliasing -fomit-frame-pointer -mthumb -Wa,-mthumb -Wa,-mimplicit-it=always p
|
||||
```
|
||||
|
||||
## IV. Interpreting the Results
|
||||
|
||||
After the command is executed, it outputs detailed performance data and validation information. The table below explains the key output parameters:After the command is executed, it outputs detailed performance data and validation information. The table below explains the key output parameters:
|
||||
|
||||
| **Parameter** | **Description** | **Example Value** |
|
||||
| :------------------- | :----------------------------------------------------------------------------------------------------------------------------- | :-------------------------------- |
|
||||
| `Run Type` | The run type and parameters for the test. | `2K performance run...` |
|
||||
| `CoreMark Size` | The size of the data buffer used for the test. | `666` |
|
||||
| `Total ticks` | The total number of system clock ticks consumed to complete all iterations. | `207740` |
|
||||
| `Total time (secs)` | The total time taken to complete the test, in seconds. | `20.774000` |
|
||||
| **`Iterations/Sec`** | **The core performance score. This value is the key metric for CPU performance; a higher value indicates better performance.** | **`529.508039`** |
|
||||
| `Iterations` | The total number of iterations performed during the test. | `11000` |
|
||||
| `Compiler version` | The version of the compiler used to build the test code. | `GCC11.3.1 20220712` |
|
||||
| `Compiler flags` | The flags used during compilation and linking, which can significantly impact the final performance score. | `-O3 -fno-strict-aliasing...` |
|
||||
| `seedcrc` | The initial seed value used for the three sets of CRC calculations. | `0xe9f5` |
|
||||
| `[0]crclist` | The CRC checksum for the list processing algorithm, used to validate the correctness of the results. | `0xe714` |
|
||||
| `[0]crcmatrix` | The CRC checksum for the matrix manipulation algorithm. | `0x1fd7` |
|
||||
| `[0]crcstate` | The CRC checksum for the state machine algorithm. | `0x8e3a` |
|
||||
| `[0]crcfinal` | The final combined CRC checksum after three iterations, used to ensure the validity of the test. | `0x33ff` |
|
||||
| `Final Score` | A compact summary of the final score, appended with environmental information such as the compiler version and flags. | `CoreMark 1.0 : 529.508039 / ...` |
|
||||
|
||||
## V. References
|
||||
|
||||
- [Official CoreMark Website (EEMBC)](https://www.eembc.org/coremark/)
|
||||
- [CoreMark GitHub Repository](https://github.com/eembc/coremark)
|
||||
|
After Width: | Height: | Size: 29 KiB |
|
|
@ -0,0 +1,161 @@
|
|||
# ramspeed Memory Performance Benchmarking Guide
|
||||
|
||||
\[ English | [简体中文](./../../../../zh-cn/debugging_tools/performance/Benchmark/ramspeed.md) \]
|
||||
|
||||
This document provides a comprehensive guide for developers and performance engineers on using the `ramspeed` benchmark tool in the `openvela` system. The tool accurately evaluates the performance of `memcpy` and `memset` functions by executing a series of standard memory operations under various loads.
|
||||
|
||||
## I. Overview
|
||||
|
||||
`ramspeed` is a command-line tool designed to assess memory performance. It measures memory read/write throughput for various block sizes by repeatedly executing `memcpy` (memory copy) and `memset` (memory fill) operations on a specified memory region.
|
||||
|
||||
The benchmark results help developers:
|
||||
|
||||
- Assess the real-world performance of memory operation functions in the system's C library (`libc`).
|
||||
- Analyze the impact of various compiler optimization options on performance.
|
||||
- Identify potential system-level performance bottlenecks.
|
||||
|
||||
To ensure accurate and reproducible results, please carefully read the configuration requirements and best practices in this document before testing.
|
||||
|
||||
## II. System Configuration
|
||||
|
||||
To obtain reliable benchmark data, you must properly configure the system to eliminate performance overhead caused by non-essential system activities and debugging features.
|
||||
|
||||
### 1. Kconfig Configuration
|
||||
|
||||
In your `defconfig` file, verify and apply the following settings. These options maximize code execution efficiency and disable debugging or monitoring features that could interfere with performance measurements.
|
||||
|
||||
```makefile
|
||||
# Enable custom optimization flags
|
||||
CONFIG_DEBUG_CUSTOMOPT=y
|
||||
# Set compiler optimization level to -O3 for maximum performance
|
||||
CONFIG_DEBUG_OPTLEVEL=-O3
|
||||
|
||||
# --- Disable the following performance-impacting options ---
|
||||
# Disable scheduler instrumentation
|
||||
CONFIG_SCHED_INSTRUMENTATION=n
|
||||
# Disable interrupt monitor
|
||||
CONFIG_SCHED_IRQMONITOR=n
|
||||
# Disable critical section monitor
|
||||
CONFIG_SCHED_CRITMONITOR=n
|
||||
# Disable stack canaries. This has a significant performance impact,
|
||||
# especially for short function calls, potentially causing up to a 3x difference!
|
||||
CONFIG_STACK_CANARIES=n
|
||||
# Disable the watchdog to prevent assertions during long tests
|
||||
CONFIG_WATCHDOG=n
|
||||
|
||||
# --- Enable the ramspeed test suite ---
|
||||
# Enable the ramspeed tool
|
||||
CONFIG_BENCHMARK_RAMSPEED=y
|
||||
# Enable floating-point support, required by ramspeed for rate calculation
|
||||
CONFIG_LIBC_FLOATINGPOINT=y
|
||||
```
|
||||
|
||||
## III. Usage
|
||||
|
||||
You can run the `ramspeed` tool from the command-line interface, using various arguments to control its behavior.
|
||||
|
||||
### 1. Command Syntax
|
||||
|
||||
```bash
|
||||
nsh> ramspeed -h
|
||||
RAM Speed: Missing required arguments
|
||||
|
||||
Usage: ramspeed -a -r <hex-address> -w <hex-address> -s <decimal-size> -v <hex-value>[0x00] -n <decimal-repeat number>[100] -i
|
||||
|
||||
Where:
|
||||
-a allocate RW buffers on heap. Overwrites -r and -w option.
|
||||
-r <hex-address> read address.
|
||||
-w <hex-address> write address.
|
||||
-s <decimal-size> number of memory locations (in bytes).
|
||||
-v <hex-value> value to fill in memory [default value: 0x00].
|
||||
-n <decimal-repeat num> number of repetitions [default value: 100].
|
||||
-i turn off interrupts while testing [default value: false].
|
||||
```
|
||||
|
||||
### 2. Parameter Description
|
||||
|
||||
| **Argument** | **Description** | **Required** |
|
||||
| --------------------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------ |
|
||||
| `-a` | **Allocate Memory Automatically**.<br>Allocates read/write buffers on the heap. This option overrides `-r` and `-w`. | Choose `-a` or `-r`/`-w` |
|
||||
| `-r <hex-address>` | **Specify Read Address**.<br>Sets the source memory address for `memcpy`. | No |
|
||||
| `-w <hex-address>` | **Specify Write Address**.<br>Sets the destination address for `memcpy` or the target address for `memset`. | No |
|
||||
| `-s <decimal-size>` | **Set Maximum Test Size** (in bytes).<br>The test starts from 32 bytes and increases by powers of two up to this limit. | Yes |
|
||||
| `-v <hex-value>` | The hexadecimal value to fill memory with during the `memset` test. Defaults to `0x00`. | No |
|
||||
| `-n <decimal-repeat>` | The **number of repetitions** for each block size test.<br>Defaults to 100. | No |
|
||||
| `-i` | **Disable Interrupts**.<br>Enters a critical section during the test to prevent interrupt interference. | No |
|
||||
|
||||
**Operating Modes:**
|
||||
|
||||
- **`memcpy` Test**: Requires both read and write addresses. You can use `-a` for automatic allocation or specify them manually with `-r` and `-w`.
|
||||
- **`memset` Test**: Requires only a write address. You can use `-a` for automatic allocation (the read buffer is ignored) or specify it manually with `-w`.
|
||||
|
||||
### 3. Example Command
|
||||
|
||||
The following command automatically allocates 512 KB (524288 bytes) of memory and repeats each block size test 10,000 times.
|
||||
|
||||
```bash
|
||||
ramspeed -a -s 524288 -n 10000
|
||||
```
|
||||
|
||||
## IV. Interpreting and Analyzing the Output
|
||||
|
||||
The test results present performance data for `memcpy` and `memset` separately.
|
||||
|
||||

|
||||
|
||||
### 1. Sample Output
|
||||
|
||||
```shell
|
||||
vela> ramspeed -a -s 524288 -n 10000
|
||||
RAM Speed: Allocate RW buffers on heap
|
||||
RAM Speed: Write address: 0xed95d800
|
||||
RAM Speed: Read address: 0xed57f800
|
||||
RAM Speed: Size: 524288 bytes
|
||||
RAM Speed: Value: 0x00
|
||||
RAM Speed: Repeat number: 10000
|
||||
RAM Speed: Interrupts disabled: false
|
||||
______memcpy performance______
|
||||
______Perform 32 Bytes access ______
|
||||
RAM Speed: system memcpy(): Rate = 781250.000 KB/s [cost: 0.400 ms]
|
||||
RAM Speed: internal memcpy(): Rate = 781250.000 KB/s [cost: 0.400 ms]
|
||||
______Perform 64 Bytes access ______
|
||||
RAM Speed: system memcpy(): Rate = 892857.143 KB/s [cost: 0.700 ms]
|
||||
RAM Speed: internal memcpy(): Rate = 781250.000 KB/s [cost: 0.800 ms]
|
||||
______Perform 128 Bytes access ______
|
||||
RAM Speed: system memcpy(): Rate = 1041666.667 KB/s [cost: 1.200 ms]
|
||||
RAM Speed: internal memcpy(): Rate = 833333.333 KB/s [cost: 1.500 ms]
|
||||
______Perform 256 Bytes access ______
|
||||
...
|
||||
```
|
||||
|
||||
### 2. Analysis of Results
|
||||
|
||||
The output log contains two key sets of performance metrics:
|
||||
|
||||
- **`system memxxx()`**
|
||||
|
||||
- **Meaning**: Calls the `memcpy`/`memset` functions provided by the standard C library (`libc`). Its performance is directly affected by the compiler version, optimization flags, and `libc` implementation.
|
||||
- **Purpose**: Reflects the memory operation performance of the system in a real-world application context.
|
||||
|
||||
- **`internal memxxx()`**
|
||||
|
||||
- **Meaning**: Calls a basic C-language implementation of `memcpy`/`memset` built into the `ramspeed` tool. This implementation serves as a performance baseline, designed to reduce loop overhead by processing more data per cycle (e.g., using 32-bit or 64-bit word-sized operations).
|
||||
- **Purpose**: Provides a stable and controlled performance reference.
|
||||
|
||||
**Performance Diagnostics:** Typically, the performance of `system memxxx()` should be close to or better than `internal memxxx()`. If you observe that the `system` performance is significantly lower than the `internal` one, investigate the following causes:
|
||||
|
||||
1. **Compiler Optimizations are Inactive**: Return to Section II and double-check that the optimization-related settings in `defconfig` are correctly enabled.
|
||||
2. **Compiler-Specific Optimizations**: Newer GCC toolchains may apply vectorization optimizations (e.g., using the Arm MVE instruction set) to the C implementation of `memcpy`. This can lead to the `internal` implementation outperforming the `system` one in some tests, which is normal. You can confirm this by analyzing the disassembly.
|
||||
|
||||
## V. Best Practices
|
||||
|
||||
Follow these recommendations to obtain accurate and reproducible performance data:
|
||||
|
||||
- **Isolate the Test Environment**: Before running the benchmark, shut down all non-essential applications and background tasks. Ensure that only core system processes are running to minimize contention for the CPU and memory bus.
|
||||
- **Mitigate Cache Effects**: Use a large memory test size (`-s` argument, 512 KB or larger is recommended). This reduces the impact of cache hits on small-block tests, providing a more realistic measurement of DDR/SRAM performance.
|
||||
- **Increase the Sample Size**: Use a high number of repetitions (`-n` argument, 1000 or more is recommended). This helps to average out performance jitter from single runs and makes the statistical results more reliable.
|
||||
- **Eliminate Interrupt Interference**: For latency-critical analysis, use the `-i` flag to disable interrupts during the test. This measures the pure CPU-to-Memory performance without external interference.
|
||||
|
||||
## VI. References
|
||||
|
||||
- **[How Memory Usage Patterns Can Derail Real-time Performance](https://interrupt.memfault.com/blog/memory-debugging)**: An in-depth article exploring how memory usage patterns can affect real-time performance.
|
||||
|
|
@ -0,0 +1,113 @@
|
|||
# Analyzing Memory Performance with Tinymembench
|
||||
|
||||
\[ English | [简体中文](./../../../../zh-cn/debugging_tools/performance/Benchmark/tinymembench.md) \]
|
||||
|
||||
## I. Overview
|
||||
|
||||
`tinymembench` is a lightweight, cross-platform benchmarking tool that you can use to precisely measure your system's memory bandwidth and random-access latency. This tool provides critical data for analyzing and optimizing the performance of an embedded system's memory subsystem.
|
||||
|
||||
The main features of `tinymembench` include:
|
||||
|
||||
- **Official Source Code**: https://github.com/ssvb/tinymembench
|
||||
|
||||
- **Supported Processor Architectures**:
|
||||
|
||||
- AArch64
|
||||
- ARM
|
||||
- amd64
|
||||
- MIPS32
|
||||
|
||||
- **Supported Vector Instruction Sets**:
|
||||
|
||||
- SSE2 (Streaming SIMD Extensions 2)
|
||||
- NEON
|
||||
|
||||
## II. Usage Instructions
|
||||
|
||||
You can enable and run `tinymembench` in the openvela environment with simple configuration and commands.
|
||||
|
||||
### 1. Enabling `tinymembench`
|
||||
|
||||
Enable the `tinymembench` application in your project's configuration.
|
||||
|
||||
1. Enter the openvela configuration menu (e.g., by running `make menuconfig`).
|
||||
|
||||
2. Navigate to `Application Configuration` -> `BenchMarks`.
|
||||
|
||||
3. Select the `tinymembench` option.
|
||||
|
||||
```Makefile
|
||||
CONFIG_BENCHMARKS_TINYMEMBENCH=y
|
||||
```
|
||||
|
||||
4. Save the configuration and recompile your project.
|
||||
|
||||
The source code for `tinymembench` is located in the `apps/benchmarks/tinymembench` directory.
|
||||
|
||||
### 2. Running the Benchmark
|
||||
|
||||
In the command line (NuttShell), simply execute the `tinymembench` command to start the test. The command requires no arguments.
|
||||
|
||||
```Bash
|
||||
nsh> tinymembench
|
||||
```
|
||||
|
||||
## III. Analyzing Test Results
|
||||
|
||||
The output of `tinymembench` is divided into two main parts: memory bandwidth tests and memory latency tests.
|
||||
|
||||
### 1. Interpreting Core Metrics
|
||||
|
||||
The basic principles for performance evaluation are straightforward:
|
||||
|
||||
- **Higher memory bandwidth is better**: It indicates that more data can be transferred per unit of time.
|
||||
- **Lower memory latency is better**: It indicates that a single memory access takes less time.
|
||||
|
||||
### 2. Example Output
|
||||
|
||||
After the test is complete, `tinymembench` will print a detailed performance report, as shown below:
|
||||
|
||||
```Bash
|
||||
nsh> tinymembench
|
||||
tinymembench v0.4.9 (simple benchmark for memory throughput and latency)
|
||||
|
||||
==========================================================================
|
||||
== Memory bandwidth tests ==
|
||||
... (Detailed output for bandwidth tests omitted) ...
|
||||
C copy : 7153.3 MB/s (3.7%)
|
||||
standard memcpy : 13278.0 MB/s (7.2%)
|
||||
standard memset : 5833.2 MB/s (1.0%)
|
||||
SSE2 copy : 12823.8 MB/s (6.8%)
|
||||
|
||||
==========================================================================
|
||||
== Memory latency test ==
|
||||
... (Detailed output for latency tests omitted) ...
|
||||
==========================================================================
|
||||
|
||||
block size : single random read / dual random read
|
||||
1024 : 0.1 ns / 0.1 ns
|
||||
...
|
||||
16777216 : 66.7 ns / 84.9 ns
|
||||
33554432 : 73.6 ns / 99.8 ns
|
||||
67108864 : 69.4 ns / 94.7 ns
|
||||
```
|
||||
|
||||
### 3. Key Factors Affecting Memory Performance
|
||||
|
||||
Memory performance is influenced by a combination of hardware and software configurations. When analyzing the results, consider the following key factors:
|
||||
|
||||
- **Data Cache**: Enabling the data cache can significantly reduce average memory access latency, thereby improving overall performance.
|
||||
- **Memory Management Unit (MMU)**: Enabling the MMU introduces overhead for virtual-to-physical address translation, increasing both average and worst-case memory access times. With multi-level page tables (e.g., 4-level tables), the worst-case memory access latency can increase significantly. In contrast, using a Memory Protection Unit (MPU) for block-based address translation has a smaller impact on performance.
|
||||
- **Translation Lookaside Buffer (TLB)**: The TLB is the MMU's address translation cache. Enabling the TLB can effectively accelerate the address translation process, reducing the average memory access latency when the MMU is active.
|
||||
- **Cacheable Attribute of Page Table Entries**: If a memory region is configured as Non-Cacheable, the CPU bypasses the cache and accesses main memory directly. This increases the average access time but may slightly reduce worst-case latency jitter.
|
||||
- **Virtualization Environment**: Running in a virtualized environment typically introduces an additional layer of address translation (e.g., Intermediate Physical Address to Host Physical Address), which slightly increases average access time and can significantly increase worst-case access time.
|
||||
- **DDR Memory Timings**: The physical characteristics of DDR (Double Data Rate) SDRAM directly impact performance.
|
||||
|
||||
- **Refresh Cycle**: During a memory refresh period (defined by parameters like `t_REF` and `t_REFI`), the memory controller pauses responses to access requests, which directly affects the worst-case access time.
|
||||
- **Access Timings**: Other key timing parameters, such as `t_CL` (CAS Latency) and `t_RCD` (RAS to CAS Delay), also affect average and worst-case access times.
|
||||
|
||||
## IV. openvela Porting Notes
|
||||
|
||||
During the process of porting `tinymembench` to `openvela`, a key modification was made:
|
||||
|
||||
- The `__attribute__((weak))` modifier was added to the `fmin` function to resolve potential symbol conflicts with a function of the same name in the standard library.
|
||||
|
|
@ -0,0 +1,108 @@
|
|||
# A Guide to the Whetstone CPU Performance Benchmark
|
||||
|
||||
\[ English | [简体中文](./../../../../zh-cn/debugging_tools/performance/Benchmark/whetstone.md) \]
|
||||
|
||||
This document provides a detailed guide for developers and performance engineers on the openvela system to use the `whetstone` benchmark tool. `whetstone` is a classic comprehensive benchmark program designed to accurately evaluate a system's floating-point and integer arithmetic performance by executing a series of standardized computational tasks.
|
||||
|
||||
## I. Overview
|
||||
|
||||
`whetstone` is a command-line tool used to evaluate a processor's arithmetic performance. It derives a standardized performance score by executing a mixed set of computational tasks, including floating-point operations, integer operations, function calls, and array access.
|
||||
|
||||
The test results can help developers:
|
||||
|
||||
- Quantitatively evaluate the performance of the processor's Floating-Point Unit (FPU).
|
||||
- Analyze the impact of different compiler optimization levels (`-O2`, `-O3`, etc.) on code execution efficiency.
|
||||
- Compare arithmetic performance across different hardware platforms or system configurations.
|
||||
|
||||
## II. System Configuration
|
||||
|
||||
Before running the test, you must enable the following Kconfig options in your `defconfig` file to ensure the `whetstone` test suite and its dependencies are compiled correctly.
|
||||
|
||||
```Makefile
|
||||
# Compile the Whetstone benchmark tool
|
||||
CONFIG_BENCHMARK_WHETSTONE=y
|
||||
|
||||
# The core of the Whetstone test is floating-point arithmetic, so C library floating-point support must be enabled
|
||||
CONFIG_LIBC_FLOATINGPOINT=y
|
||||
```
|
||||
|
||||
## III. Usage
|
||||
|
||||
The `whetstone` tool is launched via a simple command-line interface and supports parameters to control the test load.
|
||||
|
||||
### 1. Command Syntax
|
||||
|
||||
```Bash
|
||||
whetstone [-c <iterations>] [<loops>]
|
||||
```
|
||||
|
||||
### 2. Parameter Description
|
||||
|
||||
| **Parameter** | **Description** | **Required** | **Default Value** |
|
||||
| :---------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :----------- | :---------------- |
|
||||
| `[<loops>]` | **Module Loop Count**. A positional argument that sets the number of execution loops for each internal test module. Increasing this value significantly increases the computational load and execution time of a single test module. | No | 1000 |
|
||||
| `-c <iterations>` | **Total Test Rounds**. An optional parameter that sets the number of times the entire `whetstone` test suite is repeated. | No | 1 |
|
||||
|
||||
### 3. Execution Examples
|
||||
|
||||
1. Run a standard test: Uses default parameters, with each module looping 1,000 times and the entire test running for 1 round.
|
||||
|
||||
```Bash
|
||||
whetstone
|
||||
```
|
||||
|
||||
2. Increase the computational load of each module: Each module loops 100,000 times, and the entire test runs for 1 round. This is suitable for scenarios requiring longer run times to obtain a stable average.
|
||||
|
||||
```Bash
|
||||
whetstone 100000
|
||||
```
|
||||
|
||||
3. Repeat the test multiple times: Each module loops 100,000 times, and the entire test suite is repeated for 10 rounds.
|
||||
|
||||
```Bash
|
||||
whetstone 100000 -c 10
|
||||
```
|
||||
|
||||
## IV. Interpreting the Results
|
||||
|
||||
After the test is complete, `whetstone` outputs the test configuration, total time elapsed, and the final performance score.
|
||||
|
||||
### 1. Example Output
|
||||
|
||||
```Bash
|
||||
ap> whetstone 100000
|
||||
Loops: 100000, Iterations: 1, Duration: 5 sec.
|
||||
C Converted Double Precision Whetstones: 2.00 MWIPS
|
||||
```
|
||||
|
||||
- `Loops: 100000`: Each module executed 100,000 loops.
|
||||
- `Iterations: 1`: The entire test suite was executed for 1 round.
|
||||
- `Duration: 5 sec`: Total execution time was 5 seconds.
|
||||
- `C Converted Double Precision Whetstones: 2.00 MWIPS`: The final performance score is 2.00 MWIPS.
|
||||
|
||||
### 2. Key Metrics Explained
|
||||
|
||||
- **MWIPS / KWIPS**
|
||||
|
||||
- **Meaning**: The performance units for `whetstone`, which stand for **MWIPS** (Mega Whetstone Instructions Per Second) and **KWIPS** (Kilo Whetstone Instructions Per Second).
|
||||
- **Calculation**: This value is calculated based on a fixed benchmark workload, the number of test loops (`loops` and `-c` parameters), and the total execution time. It is a standardized score; the higher the score, the stronger the processor's arithmetic performance.
|
||||
- **Unit Conversion**: When the score is below 1 MWIPS (i.e., 1000 KWIPS), the result is displayed in KWIPS.
|
||||
|
||||
## V. Test Module Details
|
||||
|
||||
The `whetstone` benchmark consists of 11 carefully designed computational modules that comprehensively cover different types of operations:
|
||||
|
||||
- Modules 1-4: Basic floating-point operations, array operations, and conditional judgments
|
||||
- Module 5: Omitted integer arithmetic module
|
||||
- Module 6: Complex integer arithmetic
|
||||
- Module 7: Trigonometric function calculations (including inverse trigonometric functions)
|
||||
- Module 8: Procedure call test
|
||||
- Module 9: Array indexing test
|
||||
- Module 10: Simple integer arithmetic
|
||||
- Module 11: Chained mathematical function calls
|
||||
|
||||
## VI. openvela Porting Notes
|
||||
|
||||
This version of `whetstone` has been critically optimized for embedded real-time systems.
|
||||
|
||||
- **Optimized Timer Precision**: The original `whetstone` could only produce results when the test duration reached the second level. The version ported to openvela provides precise output even at the millisecond level. This allows for quick, stable, and accurate performance data even with fewer loop iterations on high-performance embedded CPUs.
|
||||
|
|
@ -0,0 +1,116 @@
|
|||
# Analyzing CPU Load with cpuload
|
||||
|
||||
\[ English | [简体中文](./../../../../zh-cn/debugging_tools/performance/analysis/cpuload.md) \]
|
||||
|
||||
In embedded systems development, analyzing CPU load is a critical step for identifying performance bottlenecks, optimizing task scheduling, and managing power consumption. This document details how to configure and use the `cpuload` feature in the openvela OS and how to perform in-depth performance analysis using advanced tools.
|
||||
|
||||
## I. cpuload Configuration Methods
|
||||
|
||||
openvela provides three different modes for CPU load statistics. Developers can choose the most suitable option based on precision requirements and available hardware resources.
|
||||
|
||||
### Method 1: System Clock-Based Sampling (Default)
|
||||
|
||||
This mode utilizes the system tick timer interrupt to sample the currently running task at each clock tick, thereby estimating CPU usage.
|
||||
|
||||
- **Principle**: Accumulates the execution time of the active task within the system clock's interrupt service routine.
|
||||
- **Pros and Cons**:
|
||||
|
||||
- **Pros**: Simplest to configure and has no dependency on extra hardware timers.
|
||||
- **Cons**: Statistical precision is limited by the system clock frequency and may fail to accurately capture short-running tasks.
|
||||
|
||||
- **Configuration Option**:
|
||||
|
||||
```Makefile
|
||||
CONFIG_SCHED_CPULOAD_SYSCLK=y
|
||||
```
|
||||
|
||||
### Method 2: External High-Precision Timer-Based Sampling (Recommended)
|
||||
|
||||
This mode uses a separate hardware timer (External Timer) to sample tasks at a higher frequency, providing more accurate CPU load data than the system clock method.
|
||||
|
||||
- **Principle**: Configures a dedicated hardware timer to trigger interrupts at a frequency higher than the system clock, sampling the active task within the interrupt service routine.
|
||||
- **Pros and Cons**:
|
||||
|
||||
- **Pros**: Higher statistical precision, providing a more accurate reflection of a task's instantaneous CPU usage.
|
||||
- **Cons**: Requires an additional hardware timer and corresponding driver adaptation in the Board Support Package (BSP).
|
||||
|
||||
- **Configuration Option**:
|
||||
|
||||
```Makefile
|
||||
CONFIG_SCHED_CPULOAD_EXTCLK=y
|
||||
```
|
||||
|
||||
### Method 3: High-Precision Calculation Based on Actual Task Execution Time (Recommended)
|
||||
|
||||
This mode, the most accurate of the three, uses the `SCHED_CRITMONITOR` module to precisely record the start and stop timestamps of each task to calculate its exact cumulative execution time.
|
||||
|
||||
- **Principle**: Leverages the Performance Monitor to log the precise moments of context switches, calculating CPU usage by accumulating the actual execution duration of each task.
|
||||
- **Pros and Cons**:
|
||||
|
||||
- **Pros**: Highest statistical precision, independent of sampling frequency, and truly reflects the CPU consumption of each task.
|
||||
- **Cons**: Introduces slight performance overhead due to the extra time-stamping required during context switches.
|
||||
|
||||
- **Configuration Options**:
|
||||
|
||||
**Note**: Before using this mode, you must ensure that the Board Support Package (BSP) has correctly implemented the performance counter and that it has been initialized by calling the `up_perf_init()` function.
|
||||
|
||||
```Makefile
|
||||
CONFIG_SCHED_CRITMONITOR=y
|
||||
CONFIG_SCHED_CPULOAD_CRITMONITOR=y
|
||||
```
|
||||
|
||||
## II. Viewing and Accessing CPU Load Data
|
||||
|
||||
Once any `cpuload` configuration is enabled, you can retrieve CPU load information in several ways.
|
||||
|
||||
### 1. Using the ps Command
|
||||
|
||||
在 shell 终端中执行 `ps` 命令,可以直接查看到每个线程 (thread) 的 CPU 占用率(`CPU` 列)。
|
||||
|
||||
Executing the `ps` command in the shell terminal directly displays the CPU usage (`CPU` column) for each thread.
|
||||
|
||||

|
||||
|
||||
If you only want to view information for specific threads, you can pass one or more thread IDs (PIDs) to the `ps` command.
|
||||
|
||||
```Bash
|
||||
# Example: View information for threads with PIDs 14 and 23
|
||||
ps 14 23
|
||||
```
|
||||
|
||||

|
||||
|
||||
### 2. Accessing Through Programming Interfaces
|
||||
|
||||
#### Userspace
|
||||
|
||||
Applications can obtain CPU load data by reading virtual files in the `/proc` filesystem.
|
||||
|
||||
- **To get the total system load**: `/proc/cpuload`
|
||||
- **To get the load of a specific thread**: `/proc/${pid}/cpuload`
|
||||
|
||||
#### Kernel Space
|
||||
|
||||
In kernel-space code, you can directly call the following API function to get CPU load information for a specific thread.
|
||||
|
||||
```C
|
||||
#include <nuttx/clock.h>
|
||||
|
||||
int clock_cpuload(int pid, FAR struct cpuload_s *cpuload)
|
||||
```
|
||||
|
||||
## III. Analysis with Advanced Tools
|
||||
|
||||
For scenarios requiring more detailed and visual performance analysis, the `ps` command may not be sufficient. In such cases, professional system analysis tools can be used.
|
||||
|
||||
### 1. Using SEGGER SystemView
|
||||
|
||||
SystemView is a powerful visual trace and diagnostics tool. Through a J-Link debugger, it can capture and display detailed openvela kernel scheduling events in real time, including context switches, interrupts, and API calls.
|
||||
|
||||
Compared to the `ps` command, SystemView provides higher time resolution and richer contextual information, enabling you to:
|
||||
|
||||
- Precisely measure the execution time of each thread's individual time slice.
|
||||
- Visually observe interactions and preemption relationships between tasks.
|
||||
- Analyze the overall system load within specific time frames.
|
||||
|
||||

|
||||
|
After Width: | Height: | Size: 47 KiB |
|
After Width: | Height: | Size: 153 KiB |
|
After Width: | Height: | Size: 30 KiB |
|
After Width: | Height: | Size: 398 KiB |
|
|
@ -0,0 +1,64 @@
|
|||
# Evaluating Hardware Performance
|
||||
|
||||
\[ English | [简体中文](./../../../../zh-cn/debugging_tools/performance/analysis/hardware-performance.md) \]
|
||||
|
||||
Before analyzing and optimizing software performance, you must first establish a hardware performance baseline. Hardware specifications define the upper limit of system performance (i.e., the "performance ceiling"). Confirming that the hardware capabilities meet project requirements is the starting point for all performance-related work.
|
||||
|
||||
## I. Core Hardware Performance Metrics
|
||||
|
||||
When evaluating hardware, focus on the following core metrics. These directly impact the system's computing, storage, and graphics processing capabilities.
|
||||
|
||||
### Processing Core
|
||||
|
||||
- **CPU Frequency**: Determines the processor's fundamental operational speed.
|
||||
- **Floating-Point Unit (FPU)**: Assess whether it is supported and the precision it handles (single-precision/double-precision).
|
||||
- **DSP Instruction Set**: Verify support for Digital Signal Processing instructions, which is crucial for compute-intensive tasks like audio/video processing and communications.
|
||||
|
||||
### Memory and Cache
|
||||
|
||||
- **Instruction Cache (I-Cache)**, **Data Cache (D-Cache)**, **External Cache**: The size and speed of caches are key factors affecting actual CPU performance.
|
||||
- **RAM Frequency**: Affects the overall data throughput of the memory subsystem.
|
||||
- **SRAM Bandwidth**: On-chip SRAM provides high-speed data access, and its bandwidth is critical for real-time tasks.
|
||||
- **PSRAM Bandwidth**: As an external RAM extension, PSRAM bandwidth directly impacts the efficiency of processing large amounts of data.
|
||||
|
||||
### Storage
|
||||
|
||||
- **Flash Memory Performance**: Includes code execution speed (Execute-in-Place) and data read/write throughput.
|
||||
- **eMMC/SD Performance**: Affects file system operations and data storage speed.
|
||||
|
||||
### Multimedia & Graphics Acceleration
|
||||
|
||||
- **2D Graphics Acceleration**: Confirm if the hardware supports Bit Blit or other 2D acceleration features, which significantly impacts UI fluency.
|
||||
- **Graphics Processing Unit (GPU)**: Evaluate the GPU's 3D rendering capabilities and parallel computing performance.
|
||||
- **Hardware Video Codec**: Verify if a hardware codec is integrated for efficient video stream processing.
|
||||
|
||||
## II. Quantify Performance with Benchmarking Tools
|
||||
|
||||
You can use industry-standard benchmarking tools to quantify the key performance of the chip.
|
||||
|
||||
- **[Dhrystone]**: Evaluates processor performance for integer operations. For details, see [Using Dhrystone to Evaluate CPU Integer Performance](./../Benchmark/Dhrystone.md).
|
||||
- **[CoreMark]**: Comprehensively evaluates the computational performance of the CPU core. It is a widely used cross-platform benchmark. For details, see [Executing the CoreMark Benchmark](./../Benchmark/coremark.md).
|
||||
- **[CacheSpeed]**: Tests and quantifies the read/write speed of the cache and memory subsystem. For details, see [A Guide to the CacheSpeed Tool](./../Benchmark/cachespeed.md).
|
||||
- **[RAMSpeed]**: Specifically used to evaluate RAM data throughput and access latency. For details, see [ramspeed Memory Performance Benchmarking Guide](./../Benchmark/ramspeed.md).
|
||||
|
||||
## III. Key Analysis and Optimization Strategies
|
||||
|
||||
Based on hardware metrics and test data, you can adopt the following strategies for in-depth analysis and initial optimization.
|
||||
|
||||
### 1. Comparative Analysis
|
||||
|
||||
Compare the core metrics of the target hardware against similar products or existing projects. This approach helps you quickly identify the performance strengths and weaknesses of the current hardware, providing direction for subsequent performance optimization.
|
||||
|
||||
### 2. Optimize Floating-Point Operations
|
||||
|
||||
**Note**: Some microcontrollers (e.g., those based on the Arm Cortex-M4 core) only have native support for single-precision floating-point operations. Performing double-precision calculations on these platforms will cause the compiler to fall back to a software library for emulation, leading to a sharp decline in performance.
|
||||
|
||||
- **Action Item**: Be sure to consult the chip's datasheet to confirm its FPU-supported precision. In your code, prioritize using the natively supported floating-point type.
|
||||
- **Reference**: [Be Aware: Floating Point Operations on Arm Cortex-M4(F)](https://mcuoneclipse.com/2019/03/29/be-aware-floating-point-operations-on-arm-cortex-m4f/)
|
||||
|
||||
### 3. Optimize Code and Data Placement
|
||||
|
||||
Placing frequently executed "hot code" and frequently accessed critical data into faster memory regions (like SRAM) is a highly effective optimization technique in embedded systems.
|
||||
|
||||
- **Action Item**: After analyzing the program's performance bottlenecks, you can use a linker script to redirect specific functions or variables from slower memory (like Flash) to run in high-speed memory (like SRAM).
|
||||
- **Reference**: [Putting Code of Files into Special Section with the GNU Linker](https://mcuoneclipse.com/2014/10/06/putting-code-of-files-into-special-section-with-the-gnu-linker/)
|
||||
|
|
@ -0,0 +1,230 @@
|
|||
# Using irqinfo and critmon for Interrupt and Critical Section Monitoring
|
||||
|
||||
\[ English | [简体中文](./../../../../zh-cn/debugging_tools/performance/analysis/irqinfo_critmon.md) \]
|
||||
|
||||
This document provides a detailed guide for embedded developers on using the two core tools, `irqinfo` and `critmon`, on the `openvela` system. You will learn how to monitor interrupt performance, analyze critical section execution time, and track the maximum hold time of the scheduler lock, enabling you to identify system performance bottlenecks and optimize real-time behavior.
|
||||
|
||||
## I. Overview
|
||||
|
||||
`irqinfo` and `critmon` are two powerful command-line tools provided by the `openvela` system for real-time performance analysis.
|
||||
|
||||
- `irqinfo`: Focuses on Interrupt (IRQ) monitoring. It collects statistics on the trigger frequency, number of occurrences, and maximum execution time of the Interrupt Service Routine (ISR) for each interrupt. This is crucial for identifying "interrupt storms" or excessively long interrupt handling.
|
||||
- `critmon`: Focuses on monitoring the execution time of critical sections and scheduler locks. It tracks the longest time each thread spends with interrupts disabled (in a critical section) or with the scheduler disabled, helping you discover the key code paths that cause system response delays.
|
||||
|
||||
## II. System Configuration
|
||||
|
||||
To use these monitoring tools, you must enable the corresponding kernel configuration options in your `defconfig` file and ensure that the `procfs` file system is properly mounted.
|
||||
|
||||
### 1. General Configuration: Mounting `procfs`
|
||||
|
||||
Both `irqinfo` and `critmon` rely on the `procfs` file system to expose their statistical data. Please ensure that `CONFIG_FS_PROCFS=y` is enabled in your system and execute the following command to mount `procfs` after system startup:
|
||||
|
||||
```Bash
|
||||
mount -t procfs /proc
|
||||
```
|
||||
|
||||
### 2. `irqinfo` Specific Configuration
|
||||
|
||||
To enable interrupt frequency and execution time statistics, set the following Kconfig options:
|
||||
|
||||
```Makefile
|
||||
# Enable interrupt monitoring feature
|
||||
CONFIG_SCHED_IRQMONITOR=y
|
||||
|
||||
# Enable procfs file system support
|
||||
CONFIG_FS_PROCFS=y
|
||||
```
|
||||
|
||||
### 3. `critmon` Specific Configuration
|
||||
|
||||
To enable statistics for critical sections, scheduler locks, and thread execution time, set the following Kconfig options:
|
||||
|
||||
```Makefile
|
||||
# Enable critical section and scheduler lock monitoring
|
||||
CONFIG_SCHED_CRITMONITOR=y
|
||||
|
||||
# Enable the critmon user-space command-line tool
|
||||
CONFIG_SYSTEM_CRITMONITOR=y
|
||||
|
||||
# Enable procfs file system support
|
||||
CONFIG_FS_PROCFS=y
|
||||
```
|
||||
|
||||
**Important Note**: After enabling `CONFIG_SCHED_CRITMONITOR`, the following two options have a default value of `-1` (disabled). You must change them to `0` to enable the statistics feature.
|
||||
|
||||
```Makefile
|
||||
# Set to 0 to enable critical section execution time statistics
|
||||
CONFIG_SCHED_CRITMONITOR_MAXTIME_CSECTION=0
|
||||
|
||||
# Set to 0 to enable scheduler lock execution time statistics
|
||||
CONFIG_SCHED_CRITMONITOR_MAXTIME_PREEMPTION=0
|
||||
```
|
||||
|
||||
## III. Using `irqinfo` for Interrupt Analysis
|
||||
|
||||
The `irqinfo` tool helps you gain deep insights into your system's interrupt behavior.
|
||||
|
||||
### 1. Usage
|
||||
|
||||
Simply execute the `irqinfo` command in the shell to view the statistics.
|
||||
|
||||
```Bash
|
||||
irqinfo
|
||||
```
|
||||
|
||||
- **First execution**: Displays cumulative interrupt statistics from system boot to the current time.
|
||||
- **Subsequent executions**: Displays incremental interrupt statistics since the last `irqinfo` command was executed.
|
||||
|
||||
The statistical data is automatically cleared after each read, which facilitates segmented observation.
|
||||
|
||||
### 2. Interpreting the Output
|
||||
|
||||
```Bash
|
||||
ap> irqinfo
|
||||
IRQ HANDLER ARGUMENT COUNT RATE TIME (us)
|
||||
--- -------- -------- ----- ------ ---------
|
||||
11 2c604591 00000000 233 0.000 12
|
||||
39 0005753d 2c786451 18 2.395 83
|
||||
43 0005753d 00057455 759 0.000 143
|
||||
```
|
||||
|
||||
| **Column Name** | **Description** |
|
||||
| :-------------- | :------------------------------------------------------------------------------------------------------------------ |
|
||||
| `IRQ` | **Interrupt Number**. A unique numerical identifier to distinguish different interrupt sources. |
|
||||
| `HANDLER` | **Interrupt Handler Address**. A memory address pointing to the Interrupt Service Routine (ISR) for this interrupt. |
|
||||
| `ARGUMENT` | **Argument passed to the handler**. Usually `0` or a pointer to a specific device instance. |
|
||||
| `COUNT` | **Number of Occurrences**. The total number of times the interrupt was triggered during the statistical period. |
|
||||
| `RATE` | **Interrupt Frequency (times/sec)**. The average number of triggers per second during the statistical period. |
|
||||
| `TIME` | **Maximum Execution Time (μs)**. The longest time a single execution of the ISR took, in microseconds. |
|
||||
|
||||
### 3. Analysis Techniques
|
||||
|
||||
#### Resolving the Interrupt Handler (HANDLER)
|
||||
|
||||
You can use the `addr2line` tool to convert the `HANDLER` address into a specific file name and line number, thereby locating the ISR source code.
|
||||
|
||||
```Bash
|
||||
addr2line -fe <your_elf_file> <address>
|
||||
addr2line -fe nuttx 0005753d
|
||||
```
|
||||
|
||||
Example output:
|
||||
|
||||
```Bash
|
||||
up_irq_handler
|
||||
/path/to/nuttx_os.c:55
|
||||
```
|
||||
|
||||
**Note**: In many ARM architecture implementations, peripheral interrupts share a top-level entry point (like `up_irq_handler`). In such cases, you need to use the `IRQ` number to further distinguish the specific interrupt source.
|
||||
|
||||
#### Resolving the Interrupt Number (IRQ)
|
||||
|
||||
The meaning of an `IRQ` number is highly dependent on the hardware platform and architecture.
|
||||
|
||||
- **ARM Platforms**
|
||||
|
||||
- **0-15**: Typically system-level interrupts (e.g., SVC, PendSV). The corresponding interrupt can be found via the interrupt handler (HANDLER).
|
||||
- **> 15**: Hardware interrupts. To map them to the `IRQn` enum defined in the board-level header file, use the formula: `enum value = IRQ number - 16`.
|
||||
|
||||
- **Xtensa Platforms**
|
||||
|
||||
- IRQ definitions are usually located in a platform-specific board-level header file. Please consult it directly.
|
||||
|
||||
**Example Analysis and Code Mapping:**
|
||||
|
||||
The following `irqinfo` output demonstrates how to map an IRQ number to its definition in a BSP header file.
|
||||
|
||||
```Bash
|
||||
ap> irqinfo
|
||||
IRQ HANDLER ARGUMENT COUNT RATE TIME
|
||||
11 2c604591 00000000 8 0.205 7 # System interrupt, SVC
|
||||
39 0005753d 2c786451 37 0.948 62 # Hardware interrupt, 39-16=23 -> UART0_IRQn
|
||||
43 0005753d 00057455 3862 99.015 73 # Hardware interrupt, 43-16=27 -> Timer11 Interrupt
|
||||
```
|
||||
|
||||
```C
|
||||
/* Example: framework/services/platform/cmsis/inc/best1600.h */
|
||||
typedef enum IRQn {
|
||||
// ...
|
||||
UART0_IRQn = 23, /*!< UART0 Interrupt */
|
||||
// ...
|
||||
SYS_TIMER11_IRQn = 27, /*!< Timer11 Interrupt */
|
||||
// ...
|
||||
} IRQn_Type;
|
||||
```
|
||||
|
||||
## IV. Using `critmon` for Critical Section and Scheduler Lock Analysis
|
||||
|
||||
The `critmon` tool helps you monitor the longest time a thread spends with interrupts or scheduling disabled.
|
||||
|
||||
### 1. Usage
|
||||
|
||||
`critmon` provides a set of commands to control and display statistics.
|
||||
|
||||
- **`critmon`**:
|
||||
|
||||
Displays statistics. Similar to `irqinfo`, the first execution shows cumulative data, while subsequent executions show incremental data. The data is automatically cleared after being read.
|
||||
|
||||
- **`critmon_start`**:
|
||||
|
||||
Starts a background task that automatically prints `critmon` statistics at an interval defined by `CONFIG_SYSTEM_CRITMONITOR_INTERVAL` (default is 2 seconds).
|
||||
|
||||
- **`critmon_stop`**:
|
||||
|
||||
Stops the background auto-printing task.
|
||||
|
||||
### 2. Interpreting the Output
|
||||
|
||||
```Bash
|
||||
ap> critmon
|
||||
PRE-EMPTION CALLER CSECTION CALLER RUN TIME PID DESCRIPTION
|
||||
----------- ---------- ----------- ---------- ----------- ----------- --- -----------
|
||||
1.392849000 0.004460000 ----------- ----------- ---- CPU 0
|
||||
0.000039000 0x81f88a7 0.000021000 0x81bf457 0.000631000 0.012379000 1 hpwork
|
||||
0.001204000 0x81ccc6d 0.000029000 0x81bcfa1 0.001750000 0.108839000 3 nsh_main
|
||||
```
|
||||
|
||||
| **Column Name** | **Description** |
|
||||
| :----------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `PRE-EMPTION` & `CALLER` | **Longest preemption-off time (seconds)** and **Caller address**.<br>Records the longest duration a thread disabled the scheduler via `sched_lock()` or similar functions. |
|
||||
| `CSECTION` & `CALLER` | **Longest critical section time (seconds)** and **Caller address**.<br>Records the longest duration a thread entered a critical section via `enter_critical_section()`. |
|
||||
| `RUN` | **Longest single run time (seconds)**.<br>The longest continuous time a thread ran between two preemptions. |
|
||||
| `TIME` | **Total run time (seconds)**. The total time the thread held the CPU during the statistical period. |
|
||||
| `PID` | **Thread ID**. |
|
||||
| `DESCRIPTION` | **Thread Name**. |
|
||||
|
||||
### 3. Analyzing a Single Thread's Execution Time
|
||||
|
||||
You can also retrieve monitoring data for a single thread by reading the corresponding node in the `/proc` file system. This is very useful for writing automated test scripts or for fine-grained analysis.
|
||||
|
||||
- **Command**: `cat /proc/<pid>/critmon`
|
||||
- **Function**: Gets the longest single run time and total run time for the specified PID.
|
||||
|
||||

|
||||
|
||||
## V. Implementation Principles
|
||||
|
||||
- **Interrupt Monitoring (`irqinfo`)**: The system records a timestamp each time it enters and exits an ISR. By calculating the difference, it obtains the single execution time and compares it with the recorded maximum value to update it if necessary. A counter is incremented each time the interrupt is triggered.
|
||||
- **Critical Section/Scheduler Lock Monitoring (`critmon`)**:
|
||||
|
||||
- **Disabling/Enabling Interrupts**: The `enter_critical_section()` and `leave_critical_section()` functions have built-in timing logic to calculate and update the maximum time the current thread has disabled interrupts. It records the MAX value for the critical section time. Timing starts at boot, is cleared upon reading, and then restarts.
|
||||
- **Disabling/Enabling Scheduler**: The `sched_lock()` and `sched_unlock()` functions also contain timing logic to calculate and update the maximum time the current thread has disabled the scheduler. The tool records the MAX time for this as well, using the same principle.
|
||||
|
||||
## Appendix: Key Concept Explanations
|
||||
|
||||
- **Interrupt (IRQ) and Interrupt Service Routine (ISR)**
|
||||
|
||||
- **Interrupt (IRQ)**: A signal sent by hardware or software to the CPU, indicating an urgent event that needs immediate attention.
|
||||
- **Interrupt Service Routine (ISR)**: A piece of code specifically designed to handle a particular interrupt event. When an interrupt occurs, the CPU suspends its current task and executes the corresponding ISR.
|
||||
|
||||
- **Critical Section**
|
||||
|
||||
- Refers to a segment of code that must be executed atomically, meaning it cannot be interrupted or preempted by other tasks during its execution. In `openvela`/NuttX, this is typically achieved by **disabling all interrupts**. The `CSECTION` column in `critmon` monitors the time a thread holds this highest-priority lock. Occupying a critical section for a long time can severely impact the system's real-time responsiveness.
|
||||
|
||||
- **Scheduler Lock**
|
||||
|
||||
- A lighter-weight lock than a critical section. It **only disables the task scheduler**, preventing the OS from switching to other tasks, but it **does not disable hardware interrupts**. This means that while a scheduler lock is held, interrupts can still occur and be processed. The `PRE-EMPTION` column in `critmon` monitors the time a thread holds the scheduler lock.
|
||||
|
||||
- **`procfs` (Process File System)**
|
||||
|
||||
- A virtual file system that does not reside on a physical disk but is dynamically generated by the kernel in memory. It provides a user interface that allows users to view and modify the kernel's internal data structures and state by reading and writing files. `irqinfo` and `critmon` use `procfs` to expose the statistical data from the kernel to user-space command-line tools.
|
||||
|
|
@ -0,0 +1,97 @@
|
|||
# blktest Block Device I/O Test Guide
|
||||
|
||||
\[ English | [简体中文](./../../../zh-cn/debugging_tools/stress_testing/blktest.md) \]
|
||||
|
||||
This guide provides developers and test engineers with instructions for using the `blktest` test suite on the openvela system. The `blktest` suite validates the stability, data integrity, and performance of block and Flash storage device drivers by executing a series of I/O operations.
|
||||
|
||||
## I. Overview
|
||||
|
||||
`blktest` is a driver test suite built on the CMocka framework that performs low-level I/O functional verification on storage devices. The suite interacts directly with device nodes to simulate file system read and write behavior, which allows you to effectively evaluate the robustness of a target driver.
|
||||
|
||||
The test supports the following device types:
|
||||
|
||||
- **Block Devices**: Such as RAM disks (`/dev/ram*`) and SD cards (`/dev/sd*`).
|
||||
- **MTD (Flash) Devices**: Such as NAND or SPI-NOR Flash, which are accessed through a Flash Translation Layer (FTL) and a Block-to-Character (BCH) conversion layer.
|
||||
|
||||
`blktest` executes three core test cases that cover multiple scenarios, from full-disk stress tests to specific I/O patterns.
|
||||
|
||||
> **Note**: Block devices perform read and write operations in fixed-size units called blocks or pages. Common block sizes range from 512 bytes to 32,768 bytes.
|
||||
|
||||
## II. System Configuration
|
||||
|
||||
Before you run the test, you must enable the following Kconfig options in your `defconfig` file. This ensures that the system correctly compiles and integrates the `blktest` suite and its dependencies.
|
||||
|
||||
```ini
|
||||
# Enables the BCH driver, required for accessing MTD devices
|
||||
CONFIG_BCH=y
|
||||
|
||||
# Enables the driver test collection, which includes blktest
|
||||
CONFIG_TESTING_DRIVER_TEST=y
|
||||
|
||||
# Enables the CMocka test framework, which provides the runtime for blktest
|
||||
CONFIG_TESTING_CMOCKA=y
|
||||
```
|
||||
|
||||
**Configuration Details:**
|
||||
|
||||
- `CONFIG_BCH=y`: Enables the Block-to-Character (BCH) translation driver. This layer is required when testing MTD devices.
|
||||
- `CONFIG_TESTING_DRIVER_TEST=y`: Enables the base driver test suite.
|
||||
- `CONFIG_TESTING_CMOCKA=y`: Enables the CMocka unit testing framework, on which the `blktest` test cases are built.
|
||||
|
||||
## III. Running the Test
|
||||
|
||||
### 1. Command Syntax
|
||||
|
||||
Run the `blktest` suite using the `cmocka_driver_block` command.
|
||||
|
||||
```bash
|
||||
cmocka_driver_block -m <device_path>
|
||||
```
|
||||
|
||||
- **`device_path`**
|
||||
- The path to the target device node. For example, use `/dev/ram10` for a block device or `/dev/mtdblock0` for an MTD device.
|
||||
|
||||
### 2. Example
|
||||
|
||||
The following command runs the test on a RAM disk device located at `/dev/ram10`:
|
||||
|
||||
```bash
|
||||
cmocka_driver_block -m /dev/ram10
|
||||
```
|
||||
|
||||
> **Note**: The test traverses large sections of the device for read and write operations. The duration of the test depends on the device type and size, so please allow sufficient time for it to complete.
|
||||
|
||||
## IV. Test Case Details
|
||||
|
||||
The `cmocka_driver_block` command executes the following three test cases in sequence:
|
||||
|
||||
| Test Case Name | Purpose and Behavior |
|
||||
| ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `blktest_stress` | **Full-Disk Stress and Data Integrity Test**. <br>This test traverses every block on the device, writes random data to each block, and then immediately reads it back. It performs a CRC32 checksum to verify data integrity. For Flash devices, this operation goes through the FTL and BCH layers. |
|
||||
| `blktest_single_write` | **Single-Block Write Test**. <br>This test simulates a file system operation by writing a single block (or page) to the device. It verifies the driver's ability to process a basic write request. |
|
||||
| `blktest_cachesize_write` | **Cache-Sized Write Test**. <br>This test simulates a file system operation by writing a number of blocks equal to the device's cache size in a single operation. It validates the driver's ability to handle buffered I/O and bulk write operations. |
|
||||
|
||||
## V. Expected Output
|
||||
|
||||
A successful test run produces output similar to the following example. Each line containing `[ OK ]` indicates that a test case passed.
|
||||
|
||||
```bash
|
||||
ap> cmocka_driver_block -m /dev/ram10
|
||||
[ INFO] [ap] [==========] tests: Running 1 test(s).
|
||||
[ INFO] [ap] [ RUN ] blktest_stress
|
||||
[ INFO] [ap] [ OK ] blktest_stress
|
||||
[ INFO] [ap] [ RUN ] blktest_single_write
|
||||
[ INFO] [ap] [ OK ] blktest_single_write
|
||||
[ INFO] [ap] [ RUN ] blktest_cachesize_write
|
||||
[ INFO] [ap] [ OK ] blktest_cachesize_write
|
||||
[ INFO] [ap] [==========] tests: 1 test(s) run.
|
||||
[ INFO] [ap] [ PASSED ] 1 test(s).
|
||||
ap>
|
||||
```
|
||||
|
||||
## VI. References
|
||||
|
||||
`blktest` is part of the open-source Apache NuttX project. For more information, see the following resources:
|
||||
|
||||
- **[Apache NuttX Official Website](https://nuttx.apache.org/)**: Find the latest updates, features, and community resources for the NuttX RTOS.
|
||||
- **[CMocka Official Website](https://cmocka.org/)**: The official website for the unit testing framework used by `blktest`.
|
||||
|
After Width: | Height: | Size: 17 KiB |
|
After Width: | Height: | Size: 12 KiB |
|
|
@ -0,0 +1,108 @@
|
|||
# fstest Filesystem Stress Testing Tool Guide
|
||||
|
||||
\[ English | [简体中文](./../../../zh-cn/debugging_tools/stress_testing/fstest.md) \]
|
||||
|
||||
## I. Overview
|
||||
|
||||
`fstest` is a command-line tool designed for stress testing filesystem performance and stability.
|
||||
|
||||
By simulating high-load file operations (such as concurrent creation, writing, reading, and deletion of files) on a specified mount point, it comprehensively tests the entire I/O stack, from the upper-level filesystem down to the drivers for underlying storage media (like eMMC, SD cards, and on-board flash). This tool is crucial for evaluating filesystem performance on a specific hardware platform, identifying I/O bottlenecks, and verifying the stability of storage drivers.
|
||||
|
||||
## II. Command Details
|
||||
|
||||
Run `fstest -h` in the openvela system shell to get the complete command-line options.
|
||||
|
||||
### 1. Command Syntax
|
||||
|
||||
```bash
|
||||
fstest [OPTIONS]
|
||||
```
|
||||
|
||||
### 2. Parameter Descriptions
|
||||
|
||||
| **Option** | **Argument** | **Description** | **Default** |
|
||||
| :--------- | :----------- | :------------------------------------------------------------------------------------------------------------------------------------- | :---------- |
|
||||
| `-h` | N/A | Displays this help message and exits. | N/A |
|
||||
| `-n` | `[count]` | Specifies the number of test loops. Each loop executes a complete cycle of file creation, writing, reading, and deletion. | 100 |
|
||||
| `-m` | `[path]` | **(Required)** Specifies the target mount point (path) for the test. The tool will create and operate on test files in this directory. | N/A |
|
||||
| `-o` | `[num]` | Specifies the total number of files to create and operate on within a single test loop. | 512 |
|
||||
| `-s` | `[size]` | Specifies the size of each test file in bytes. | 8192 |
|
||||
|
||||
### 3. Raw Help Message
|
||||
|
||||
The following is the raw output of the `fstest -h` command in the terminal for your reference.
|
||||
|
||||
```bash
|
||||
ap>fstest -h
|
||||
|
||||
Usage:fstest [OPTION [ARG]] ...
|
||||
-h show this help statement
|
||||
-n num of test loop e.g. [100]
|
||||
-m mount point to be tested e.g. []
|
||||
-o num of open file e.g
|
||||
-s size of every file e.g
|
||||
|
||||
Note: The product of the values for -o and -s must be less than the total size of the partition.
|
||||
```
|
||||
|
||||
## III. Prerequisites
|
||||
|
||||
Before running the test, you must ensure that the target partition has enough free space to accommodate all test files. The total space required is determined by the **number of files** (`-o`) and the **size of each file** (`-s`), and must satisfy the following condition:
|
||||
|
||||
```text
|
||||
(Number of files × Size per file) < Available space on the target partition
|
||||
```
|
||||
|
||||
If there is insufficient space, the test will fail because it cannot create the files.
|
||||
|
||||
## IV. Execution and Examples
|
||||
|
||||
### 1. Test Command Examples
|
||||
|
||||
The following examples demonstrate how to run `fstest` on different mount points.
|
||||
|
||||
```Bash
|
||||
# Run 100 test loops in the /tmp directory
|
||||
fstest -n 100 -m /tmp
|
||||
|
||||
# Run 100 test loops in the /data directory
|
||||
fstest -n 100 -m /data
|
||||
```
|
||||
|
||||
### 2. Example Output
|
||||
|
||||
After the test runs, you will see output logs similar to the following. The log displays the test configuration and prints the time taken for each phase of file operations.
|
||||
|
||||
- Test output after running `fstest -n 100 -m /tmp`:
|
||||
|
||||

|
||||
|
||||
- Test output after running `fstest -n 100 -m /data`:
|
||||
|
||||

|
||||
|
||||
### 3. Interpreting the Results
|
||||
|
||||
The output log from `fstest` consists of two main parts: **performance data** and a **memory usage report**.
|
||||
|
||||
#### Memory Usage Report
|
||||
|
||||
The `Final memory usage` table at the end of the log is key for diagnosing memory leaks. It shows the changes in the openvela kernel memory heap before and after the test run.
|
||||
|
||||
- **`BEFORE` / `AFTER`**: Represent the snapshot values of a memory metric before the test task starts and after it ends, respectively.
|
||||
- **`DELTA`**: The difference between `AFTER` and `BEFORE`. **For a healthy system, the `DELTA` value should be `0`**, indicating that all memory dynamically allocated during the test was correctly freed upon completion.
|
||||
- **Key Metric Descriptions**:
|
||||
|
||||
- `arena`: Total heap size.
|
||||
- `ordblks`: Number of free memory blocks (Free Chunks).
|
||||
- `uordblks`: Total size of allocated memory blocks (Allocated Chunks).
|
||||
- `fordblks`: Total size of free memory blocks.
|
||||
|
||||
If a non-zero value appears in the `DELTA` column, it usually indicates a memory leak. For example, in the first sample output, `ordblks` (free blocks) increased by 3, while `uordblks` (used space) increased by 1080 bytes. This suggests that the test run on the `/tmp` path may have triggered memory allocations that were not properly released.
|
||||
|
||||
#### Performance Data
|
||||
|
||||
Lines in the log that start with `[TMR]` show the performance data for each file operation phase.
|
||||
|
||||
- **Success Indicator**: When all test loops complete without errors, the log will print `fstest success!` at the end.
|
||||
- **Performance Metrics**: Entries like `create file`, `write file`, `read file`, and `remove file` correspond to the file creation, writing, reading, and deletion phases, respectively. The subsequent time value indicates the total time consumed to complete all operations in that phase (the unit is typically milliseconds or system clock ticks, depending on the platform implementation). By analyzing this timing data, you can evaluate the filesystem's performance under various I/O patterns.
|
||||
|
|
@ -0,0 +1,88 @@
|
|||
# Conducting Memory Stress Tests with memstress
|
||||
|
||||
[ English | [简体中文](./../../../zh-cn/debugging_tools/stress_testing/memstress.md) ]
|
||||
|
||||
## I. Overview
|
||||
|
||||
`memstress` is a test tool designed to verify the stability and correctness of a system's memory manager, making it particularly suitable for use during development and debugging phases.
|
||||
|
||||
When run in debug mode, the tool outputs detailed logs for each memory allocation and deallocation, which helps in tracking down memory-related issues.
|
||||
|
||||
## II. How It Works
|
||||
|
||||
The `memstress` tool stress-tests the system by randomly performing the following three types of memory operations:
|
||||
|
||||
1. **Standard `malloc`**: Allocates memory using `malloc()`.
|
||||
2. **Aligned allocation**: Allocates aligned memory using `aligned_alloc()`.
|
||||
3. **Reallocation**: Resizes existing memory blocks using `realloc()`.
|
||||
|
||||
The tool fills the allocated memory with random data (or a fixed pattern in debug mode) and subsequently verifies the data's integrity to detect memory corruption or other read/write errors.
|
||||
|
||||
If a memory error is detected, the tool prints detailed error information and triggers an assertion to help pinpoint the issue.
|
||||
|
||||
## III. How to Use memstress
|
||||
|
||||
### Step 1: Enable the Tool at Compile Time
|
||||
|
||||
Enable the following Kconfig options in your `defconfig` file.
|
||||
|
||||
```makefile
|
||||
# Enable the memstress tool
|
||||
CONFIG_TESTING_MEMORY_STRESS=y
|
||||
|
||||
# Set the program name
|
||||
CONFIG_TESTING_MEMORY_STRESS_PROGNAME
|
||||
|
||||
# Set the task priority
|
||||
CONFIG_TESTING_MEMORY_STRESS_PRIORITY
|
||||
|
||||
# Set the stack size
|
||||
CONFIG_TESTING_MEMORY_STRESS_STACKSIZE
|
||||
```
|
||||
|
||||
### Step 2: Run the Test Command
|
||||
|
||||
Execute the `memstress` command from the system shell.
|
||||
|
||||
#### Command Syntax
|
||||
|
||||
```bash
|
||||
memstress -m <max-allocsize> -n <node-length> -t <sleep-us> [-x <nthreads>] [-d]
|
||||
```
|
||||
|
||||
#### Parameters
|
||||
|
||||
| Parameter | Description |
|
||||
| :------------------- | :------------------------------------------------------------------------------------ |
|
||||
| `-m <max-allocsize>` | Sets the maximum size for a single memory allocation, in bytes. Default: `8192`. |
|
||||
| `-n <node-length>` | Sets the number of memory blocks (nodes) to manage in the test list. Default: `1024`. |
|
||||
| `-t <sleep-us>` | Sets the sleep interval between operations, in microseconds. Default: `100`. |
|
||||
| `-x <nthreads>` | Enables multi-threaded testing and sets the number of threads. Default: `1`. |
|
||||
| `-d` | Enables debug mode, which outputs verbose logs to help locate issues. |
|
||||
|
||||
#### Examples
|
||||
|
||||
```bash
|
||||
# Basic usage with default parameters
|
||||
memstress
|
||||
|
||||
# Set max allocation to 4 KB, 1000 blocks, and 4 threads
|
||||
memstress -m 4096 -n 1000 -x 4
|
||||
|
||||
# Run a test with debug mode enabled
|
||||
memstress -d -m 2048 -n 500
|
||||
```
|
||||
|
||||
## IV. Important: Estimating Memory Consumption
|
||||
|
||||
The maximum potential memory consumption of the `memstress` tool is determined by the following factors:
|
||||
|
||||
1. **Node array per thread**: Each thread creates an array to manage `<node-length>` memory allocations.
|
||||
2. **Maximum allocation per node**: Each node in the array can hold one memory block, with a random size up to `<max-allocsize>`.
|
||||
3. **Multi-threaded execution**: The tool supports `<nthreads>` running concurrently, each with its own set of nodes.
|
||||
|
||||
`memstress` runs continuously until an error is detected. Before execution, you **must** estimate the maximum potential memory consumption using the formula below to ensure the system has sufficient available memory.
|
||||
|
||||
**Maximum Memory Consumption ≈ `<max-allocsize>` × `<node-length>` × `<nthreads>`**
|
||||
|
||||
Please note that this is a theoretical peak value. The actual memory usage will fluctuate due to the random allocation and deallocation of memory blocks. It is recommended to start with smaller parameters and gradually increase the test load.
|
||||
|
|
@ -0,0 +1,87 @@
|
|||
# opus_ramtest Stress Test Guide
|
||||
|
||||
[ English | [简体中文](./../../../zh-cn/debugging_tools/stress_testing/opus_ramtest.md) ]
|
||||
|
||||
This document provides a detailed guide for configuring and running the `opus_ramtest` stress test on the openvela system. This test evaluates the stability of the system's memory and scheduler under heavy load by concurrently decoding Opus audio data.
|
||||
|
||||
## I. Overview
|
||||
|
||||
`opus_ramtest` is a stress test tool designed to assess system stability. It creates multiple concurrent child processes (threads), each independently performing high-intensity Opus audio decoding tasks. This applies pressure to two core aspects of the system:
|
||||
|
||||
- **Memory System**: Concurrent decoding operations trigger a large volume of memory allocations and deallocations, effectively testing the robustness of the system's memory management. This helps identify issues such as memory leaks, fragmentation, or illegal memory access.
|
||||
- **Task Scheduler**: A large number of active processes frequently compete for CPU resources, posing a stringent challenge to the operating system's task scheduler. This can be used to evaluate the efficiency, real-time performance, and fairness of the scheduling algorithm.
|
||||
|
||||
This test is crucial for verifying the reliability of embedded systems under sustained high loads.
|
||||
|
||||
## II. Preparation: System Configuration
|
||||
|
||||
Before running the test, you must enable and optimize the relevant components in your system build configuration.
|
||||
|
||||
### 1. Enable Core Features
|
||||
|
||||
In your `defconfig` file, ensure the following Kconfig options are enabled to integrate the Opus library and the test program:
|
||||
|
||||
```bash
|
||||
CONFIG_LIB_OPUS=y
|
||||
CONFIG_LIB_OPUS_DEMO=y
|
||||
CONFIG_TESTING_OPUS_RAMTEST=y
|
||||
```
|
||||
|
||||
- `CONFIG_LIB_OPUS=y`: Enables the Opus audio codec library.
|
||||
- `CONFIG_LIB_OPUS_DEMO=y`: Enables the Opus demo code, which `opus_ramtest` depends on.
|
||||
- `CONFIG_TESTING_OPUS_RAMTEST=y`: Compiles and enables the `opus_ramtest` test command.
|
||||
|
||||
### 2. Optimize the Test Environment
|
||||
|
||||
To ensure the test can effectively apply pressure, make the following configurations:
|
||||
|
||||
- **Configure the Task Scheduler:**
|
||||
|
||||
- Set `CONFIG_RR_INTERVAL`, the time slice for Round-Robin scheduling. **Reducing this value increases the frequency of task switching, thereby increasing the scheduling pressure on the system**. For example, setting it to `5` (milliseconds) provides good test results.
|
||||
- `CONFIG_RR_INTERVAL=5`
|
||||
|
||||
- **Adjust the Main Process Stack Size:**
|
||||
|
||||
- If a stack overflow occurs when the test process starts, you need to increase the main process's stack space.
|
||||
- Modify the value of `CONFIG_TESTING_OPUS_RAMTEST_STACKSIZE`. The default value is `40960` bytes.
|
||||
|
||||
## III. Executing the Test
|
||||
|
||||
### 1. Disable the Watchdog
|
||||
|
||||
Prolonged stress testing may slow down system responsiveness, potentially triggering a watchdog reset. Before testing, use the following command to disable the watchdog:
|
||||
|
||||
```bash
|
||||
echo V > /dev/watchdog0
|
||||
```
|
||||
|
||||
### 2. Run the Test Command
|
||||
|
||||
Start the test using the `opus_ramtest` command. The following is a recommended command:
|
||||
|
||||
```bash
|
||||
# The -s parameter sets a 40960-byte stack for each child process
|
||||
opus_ramtest -s 40960
|
||||
```
|
||||
|
||||
## IV. Command-Line Parameter Details
|
||||
|
||||
The `opus_ramtest` command supports several parameters to customize its behavior.
|
||||
|
||||
| Parameter | Description | Default Value |
|
||||
| :-------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------- |
|
||||
| `-s` | **(Required)** Sets the stack size (in bytes) for each created child process (thread). On embedded devices, `pthread` may use a small default stack, so you must use this parameter to allocate sufficient space to prevent overflow. | N/A |
|
||||
| `-n` | Specifies the number of concurrent child processes for decoding tasks. **Note**: This value should not be set too high to avoid exhausting system resources. | `5` |
|
||||
| `-r` | Sets the scheduling priority for the child processes. | N/A |
|
||||
| `-f` | Specifies the path to an external Opus audio file for decoding. If this parameter is not provided, the test will use its built-in audio data array. | Built-in array |
|
||||
|
||||
## V. Important Notes
|
||||
|
||||
- **Built-in Data Source Size:**
|
||||
|
||||
- The test tool includes a built-in static array of approximately **250 KB**, which serves as the default audio data source. Ensure your target hardware has enough RAM to accommodate this array and the additional overhead from the test itself.
|
||||
|
||||
## VI. References
|
||||
|
||||
- **[Opus Official Website](https://opus-codec.org/)**: Get the latest information, specifications, and resources for the Opus codec.
|
||||
- **[Opus IETF RFC 6716](https://www.rfc-editor.org/rfc/rfc6716)**: The authoritative technical standard for the Opus codec, published by the Internet Engineering Task Force (IETF).
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
# Demo of music player
|
||||
# Music Player
|
||||
|
||||
\[ English | [简体中文](../../zh-cn/demo/Music_Player_Example_zh-cn.md) \]
|
||||
|
||||
|
|
@ -8,9 +8,7 @@ This article describes how to run the music player demo on Emulator.
|
|||
|
||||
## Prerequisites
|
||||
|
||||
1. Set up the development environment. Refer to [Environment Setup](./../quickstart/Set_up_the_development_environment.md).
|
||||
|
||||
2. Download the source code. Refer to [Download openvela source code](./../quickstart/Download_Vela_sources.md).
|
||||
To download the source code, see [Quick Start](./../quickstart/openvela_ubuntu_quick_start.md).
|
||||
|
||||
## Step 1: Configure the project
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Bandx Demo
|
||||
# Smart Band
|
||||
|
||||
\[ English | [简体中文](../../zh-cn/demo/Smart_Band_Example_zh-cn.md) \]
|
||||
|
||||
|
|
@ -10,9 +10,7 @@ This article describes how to run this example on Emulator.
|
|||
|
||||
## Prerequisites
|
||||
|
||||
1. Set up the development environment. Refer to [Environment Setup](./../quickstart/Set_up_the_development_environment.md).
|
||||
|
||||
2. Download the source code. Refer to [Download openvela source code](./../quickstart/Download_Vela_sources.md).
|
||||
To download the source code, see [Quick Start](./../quickstart/openvela_ubuntu_quick_start.md).
|
||||
|
||||
## Step 1: Configure the project
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Example of bike computer
|
||||
# Cycling Computer
|
||||
|
||||
\[ English | [简体中文](../../zh-cn/demo/X_Track_zh-cn.md) \]
|
||||
|
||||
|
|
@ -8,15 +8,13 @@
|
|||
|
||||
It’s a bike computer with features like speed display, distance statistics and real-time track display, with a display resolution of 240x320 pixels, using touch screen interaction.
|
||||
|
||||
The code directory is located at: “apps/packages/demos/x_track”
|
||||
The code directory is located at: `apps/packages/demos/x_track`
|
||||
|
||||
This article describes how to run the example on Emulator.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
1. Set up the development environment. Refer to [Environment Setup](./../quickstart/Set_up_the_development_environment.md).
|
||||
|
||||
2. Download the source code. Refer to [Download openvela source code](./../quickstart/Download_Vela_sources.md).
|
||||
To download the source code, see [Quick Start](./../quickstart/openvela_ubuntu_quick_start.md).
|
||||
|
||||
## Step 1: Configure the project
|
||||
|
||||
|
|
|
|||
|
After Width: | Height: | Size: 34 KiB |
|
After Width: | Height: | Size: 52 KiB |
|
After Width: | Height: | Size: 138 KiB |
|
|
@ -1,8 +1,13 @@
|
|||
# Development Board Application Cases
|
||||
# openvela Development Board Examples
|
||||
|
||||
\[ English | [简体中文](../../zh-cn/dev_board/Development_Board.md) \]
|
||||
[ English | [简体中文](../../zh-cn/dev_board/Development_Board.md) ]
|
||||
|
||||
|
||||
| Vendor Name | Development Board Model | Chip Model | Compatible Cases | Typical Application Scenarios | Purchase | Development Board Issue Consultation |
|
||||
| :--------- | :----------------------------------------------------------- | :----------------------------------------------------------- | :----------------------------------------------------------- | :------------------------------ | :----------------------------------------------------------- | :--------------- |
|
||||
| STMicroelectronics | [STM32H750B-DK](https://www.st.com.cn/zh/evaluation-tools/stm32h750b-dk.html#documentation) | [STM32H750XBH6](https://www.st.com.cn/zh/microcontrollers-microprocessors/stm32h750xb.html#documentation) | [Deploy openvela on STM32H750 ](../quickstart/development_board/STM32H750.md) | Smart Home & City<br>Industry<br>Medical<br>Payment | [Purchase Link](https://shop314814286.taobao.com/?weexShopTab=allitemsbar&weexShopSubTab=allitems&shopFrameworkType=native&sourceType=other&suid=74be4e31-a352-413d-bf81-72909dd711a5&shareUniqueId=31021130754&ut_sk=1.ZUQzpvSPtZsDAM22wgMusrSy_21646297_1743386335140.Copy.shop&un=0ebec934d3cc95cdbbeeeafdb2768e28&share_crt_v=1&un_site=0&spm=a2159r.13376460.0.0&sp_tk=bVZWMmV3bFZkbFI%3D&cpp=1&shareurl=true&short_name=h.6etlMBbY1ZEjXgI&bxsign=scdnpFVDezWrEooi2xHR3oT8fAOZA8b4hwRYH5nD-IkJzr_e6YrW1NWxn3VpZEVnrZ-9OpQT-aJKRxCaAu6Jbcs_PY7aOntLtLTTy6VNNJRR26yZttuARyPNJT51Pyeq_Ei&app=chrome) | mcu.china@st.com |
|
||||
| Manufacturer | Board Model | Chip Model | Porting Guide | Typical Application Scenarios | Board Support |
|
||||
| ------------------ | ----------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- |
|
||||
| STMicroelectronics | [STM32H750B-DK](https://www.st.com/en/evaluation-tools/stm32h750b-dk.html) | [STM32H750XB](https://www.st.com/en/microcontrollers-microprocessors/stm32h750xb.html) | [Deploy openvela on STM32H750](../quickstart/development_board/STM32H750.md) | Smart Home, Industrial Control, Medical Electronics | [ST MCU China Support](mailto:mcu.china@st.com) |
|
||||
| STMicroelectronics | STM32F411CEU6 | [STM32F411CE](https://www.st.com/en/microcontrollers-microprocessors/stm32f411ce.html) | [Blink an LED with openvela on STM32F411](../quickstart/development_board/STM32F411.md) | IoT, Industrial Automation | [ST MCU China Support](mailto:mcu.china@st.com) |
|
||||
| Espressif | [ESP32-S3-EYE](https://www.espressif.com/en/dev-board/esp32-s3-eye) | [ESP32-S3](https://www.espressif.com/en/products/socs/esp32-s3) | [Port openvela to the ESP32-S3-EYE Dev Board](../quickstart/development_board/ESP32-S3-EYE.md) | AIoT, HMI, Smart Home | [Espressif Developer Community](https://www.espressif.com/en/contact-us/technical-inquiries) |
|
||||
| Espressif | [ESP32-S3-BOX](https://www.espressif.com/en/news/ESP32-S3-BOX_video) | [ESP32-S3](https://www.espressif.com/en/products/socs/esp32-s3) | [See: Port openvela to the ESP32-S3-EYE Dev Board](../quickstart/development_board/ESP32-S3-EYE.md) | AIoT, HMI, Smart Home | [Espressif Developer Community](https://www.espressif.com/en/contact-us/technical-inquiries) |
|
||||
| Bestechnic | [BES2600WM MAIN BOARD V1.1](https://www.fortune-co.com/index.php?s=/Cn/Public/singlePage/catid/176.html) | BES2600WM-AX4F | [Readme](../../../../../vendor_bes/blob/trunk-5.5/boards/best2003_ep/aos_evb/Readme) | Smart Wearables, AI Toys | [Contact Distributor](https://www.fortune-co.com/Tech/projectDetail/id/64.html) |
|
||||
| Flagchip | [FC7300F8M-EVB](https://www.flagchip.com.cn/Pro/3/3.html) | [FC7300F8MDT](https://www.flagchip.com.cn/Pro/3/3.html) | [openvela Running Guide for FC7300F8M-EVB](../quickstart/development_board/fc7300f8m_evb_guide.md) | Domain/Zonal Controllers, ADAS, BMS, Motor Control, etc. | [Contact Distributor](https://www.flagchip.com.cn/Pro/3/3.html) | [Contact Distributor](https://www.flagchip.com.cn/Pro/3/3.html) |
|
||||
| Infineon | [TC4D9-EVB](https://itools.infineon.com/aurix_tc4xx_code_examples/documents/Board_Users_Manual_TriBoard-TC4X9-COM-V2_0_0.pdf) | [AURIX ™ TC4x](https://www.infineon.cn/products/microcontroller/32-bit-tricore/aurix-tc4x/tc4dx#products) | [openvela Running Guide for TC4D9-EVB](../quickstart/development_board/tc4d9_evb_guide.md) | Vehicle Motion Controllers, Zonal Controllers, Automotive Gateways, etc. | [Contact Distributor](https://www.infineon.cn/contact-us/where-to-buy) | [Contact Distributor](https://www.infineon.cn/contact-us/where-to-buy) |
|
||||
|
|
@ -0,0 +1,248 @@
|
|||
# CMake In-Depth Analysis and Maintenance Manual
|
||||
|
||||
\[ English | [简体中文](../../../zh-cn/device_dev_guide/build/CMake_advanced_guide.md) \]
|
||||
|
||||
This document is intended to serve as an in-depth technical reference for build system maintainers and advanced developers of openvela. It covers the internal architecture of the CMake build system, advanced development practices, and techniques for solving complex problems.
|
||||
|
||||
Before reading this document, it is recommended that you are familiar with the basic operations described in the [CMake Quick Start Guide](./CMake_quick_start.md).
|
||||
|
||||
## I. CMake Build System Architecture
|
||||
|
||||
This section provides a deep dive into the internal workflow and core design of the openvela CMake build system.
|
||||
|
||||
### 1. Overall Build Flow
|
||||
|
||||
The openvela CMake build process follows the standard NuttX framework, with `nuttx/CMakeLists.txt` as its entry point. The entire flow generates build rules during the `cmake` configuration phase and executes the compilation during the `--build` phase. It can be summarized into the following key stages:
|
||||
|
||||
1. **Configuration and Environment Check**: Performs basic CMake configuration, resolves core working directories like `NuttXDir` and `AppDir`, and executes fundamental sanity checks.
|
||||
2. **Kconfig and Configuration Import**: Parses the `defconfig` file, identifies and links the `board`, `chip`, and `apps` directories, and generates a complete Kconfig tree. Subsequently, it generates the `.config` file and imports all macro definitions from it into the CMake environment as cache variables.
|
||||
3. **Toolchain Loading**: Loads the corresponding CMake toolchain file based on configurations like `CONFIG_ARCH`, setting up the cross-compilation environment.
|
||||
4. **Build Context Generation**: Executes modules like `mkconfig.cmake` and `gen_header.cmake` to generate necessary headers and configurations, such as `config.h` and `version.h`, ensuring the build environment is ready.
|
||||
5. **Target Library Generation**: CMake iteratively traverses module directories such as `arch`, `drivers`, `mm`, `sched`, and `apps`, compiling the source files of each module and packaging them into corresponding static libraries (`.a` files).
|
||||
6. **Final Artifact Linking**: Links all generated static libraries (`${nuttx_libs}`) to produce the `nuttx` ELF executable file.
|
||||
7. **Artifact Post-Processing**: Executes user-defined `POST_BUILD` actions, such as generating `.bin` files via `objcopy` or packaging firmware.
|
||||
|
||||
The build steps are illustrated in the figure below:
|
||||
|
||||
<img src="./figures/013.png" alt="" width="60%">
|
||||
|
||||
### 2. Build Dependency Relationships
|
||||
|
||||
All modules are ultimately organized into different categories of library collections and linked to form the final product. The dependency relationship is shown in the figure below:
|
||||
|
||||
<img src="./figures/014.svg" alt="" width="100%">
|
||||
|
||||
## II. Advanced Development Practices Guide
|
||||
|
||||
### 1. Adapting Custom Boards and Chips
|
||||
|
||||
To add CMake support for your custom hardware, you need to create `CMakeLists.txt` files in the corresponding `board` and `chip` directories.
|
||||
|
||||
Example directory structure:
|
||||
|
||||
```Bash
|
||||
# Location: vendor/vendor_name
|
||||
├── boards
|
||||
│ ├── <chip_name>
|
||||
│ │ └── <board_name>
|
||||
│ │ ├── Kconfig
|
||||
│ │ ├── CMakeList.txt <-- Top-level board CMake file
|
||||
│ │ └── src
|
||||
│ │ ├── Make.defs
|
||||
│ │ └── CMakeList.txt <-- Board source CMake file
|
||||
├── chips
|
||||
│ └── chip_name
|
||||
│ ├── Kconfig
|
||||
│ ├── Make.defs
|
||||
│ └── CMakeList.txt <-- Chip-level CMake file
|
||||
```
|
||||
|
||||
Example `CMakeLists.txt` content:
|
||||
|
||||
1. `chips/<`**`chip_name`**`>/CMakeLists.txt`:
|
||||
|
||||
```Makefile
|
||||
# Add chip-related source files (e.g., startup files)
|
||||
set(SRCS chip_startup.S)
|
||||
|
||||
# Add the source files to the 'arch' target, which will be archived into libarch.a
|
||||
target_sources(arch PRIVATE ${SRCS})
|
||||
```
|
||||
|
||||
2. `boards/<`**`chip_name`**`>/<`**`board_name`**`>/src/CMakeLists.txt`:
|
||||
|
||||
```Makefile
|
||||
# Add board-level drivers and initialization source files
|
||||
set(SRCS board_source.c)
|
||||
|
||||
# Add the source files to the 'board' target, which will be archived into libboard.a
|
||||
target_sources(board PRIVATE ${SRCS})
|
||||
```
|
||||
|
||||
3. `boards/<`**`chip_name`**`>/<`**`board_name`**`>/CMakeLists.txt`:
|
||||
|
||||
```CMake
|
||||
# Include the src directory in the build
|
||||
add_subdirectory(src)
|
||||
|
||||
# Set the path for the Linker Script
|
||||
set_property(GLOBAL PROPERTY LD_SCRIPT
|
||||
"${NUTTX_BOARD_ABS_DIR}/scripts/app.ld"
|
||||
)
|
||||
|
||||
# Define a post_build target for automatic artifact processing after the build
|
||||
add_custom_target(
|
||||
nuttx_post_build ALL
|
||||
POST_BUILD
|
||||
COMMAND ${NUTTX_DIR}/../vendor/xxx/post_build.sh ${CMAKE_BINARY_DIR}
|
||||
)
|
||||
```
|
||||
|
||||
### 2. Porting a Third-Party Library
|
||||
|
||||
#### Methodology: When to Reuse, When to Rewrite?
|
||||
|
||||
If a third-party library already provides a `CMakeLists.txt`, you can evaluate whether to reuse it.
|
||||
|
||||
**Decision Principle**: Follow this principle when choosing a porting method. You **should not reuse** a third-party library's `CMakeLists.txt` and should instead write a new adaptation script if any of the following conditions apply:
|
||||
|
||||
1. The third-party library does not support cross-compilation or has strong dependencies on the host platform.
|
||||
2. The third-party library needs to be registered as a built-in application in openvela.
|
||||
3. The third-party library's `CMakeLists.txt` contains compile options that cannot be controlled externally.
|
||||
4. The third-party library's build script defines too many redundant targets or targets that conflict with the system.
|
||||
|
||||
If the third-party library is a pure static library without the issues above, you may consider reusing its build script.
|
||||
|
||||
#### Method 1 (Recommended): Write a New `CMakeLists.txt`
|
||||
|
||||
This method offers the greatest flexibility and control by completely rewriting the build logic. For details, refer to the [Basic Porting Method](./CMake_quick_start.md#basic-porting-method-recommended) section in the CMake Quick Start guide.
|
||||
|
||||
#### Method 2: Reuse via `add_subdirectory`
|
||||
|
||||
- **Description**: This method uses `add_subdirectory()` to include the third-party library as a subproject and integrates its library target into openvela using `nuttx_add_external_library`.
|
||||
- **Characteristics**: Allows reuse of external scripts, reducing the amount of porting code. However, it may introduce redundant or conflicting targets, requiring a careful evaluation of its `CMakeLists.txt`.
|
||||
- **Example** (`libpng`):
|
||||
|
||||
```Makefile
|
||||
# Control its build behavior by setting its CACHE variables externally
|
||||
set(PNG_SHARED OFF CACHE BOOL "Disable libpng shared library" FORCE)
|
||||
set(PNG_EXECUTABLES OFF CACHE BOOL "Disable libpng executable" FORCE)
|
||||
set(PNG_TESTS OFF CACHE BOOL "Disable libpng tests program" FORCE)
|
||||
|
||||
# Add the third-party library as a subdirectory
|
||||
add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/libpng
|
||||
${CMAKE_CURRENT_BINARY_DIR}/libpng EXCLUDE_FROM_ALL)
|
||||
|
||||
# Integrate the target defined by the third-party library into the openvela build environment
|
||||
nuttx_add_external_library(png_static)
|
||||
```
|
||||
|
||||
#### Method 3: Independent Build via `ExternalProject_Add`
|
||||
|
||||
- **Description**: This method initiates a completely separate sub-build process to compile the third-party library and then brings its build artifacts into the main project as an `IMPORTED` library.
|
||||
- **Characteristics**: Provides good isolation but is complex, requiring manual handling of toolchain passing and artifact importing.
|
||||
- **Example** (`libpng`):
|
||||
|
||||
```Makefile
|
||||
# Manually pass openvela's cross-compilation toolchain info to the sub-build process
|
||||
set(FLAGS_ARGS "$<JOIN:$<TARGET_PROPERTY:nuttx,COMPILE_OPTIONS>, >")
|
||||
set(EXTERN_C_FLAGS "${CMAKE_C_FLAGS} ${FLAGS_ARGS}")
|
||||
ExternalProject_Add(
|
||||
libpng_external
|
||||
SOURCE_DIR ${CMAKE_CURRENT_LIST_DIR}/libpng/
|
||||
BINARY_DIR ${CMAKE_BINARY_DIR}/external/libpng_external
|
||||
CMAKE_ARGS
|
||||
-DCMAKE_C_COMPILER=${CMAKE_C_COMPILER}
|
||||
-DCMAKE_C_FLAGS=${EXTERN_C_FLAGS}
|
||||
-DPNG_SHARED=OFF
|
||||
-DPNG_EXECUTABLES=OFF
|
||||
-DPNG_TEST=OFF
|
||||
TEST_COMMAND ""
|
||||
INSTALL_COMMAND ""
|
||||
)
|
||||
|
||||
# Bring the sub-build's artifacts into the main build process as an IMPORTED library
|
||||
add_library(libpng STATIC IMPORTED GLOBAL)
|
||||
set_target_properties(libpng PROPERTIES
|
||||
IMPORTED_LOCATION ${CMAKE_BINARY_DIR}/external/libpng_external/libpng.a
|
||||
)
|
||||
add_dependencies(libpng libpng_external)
|
||||
set_property(GLOBAL APPEND PROPERTY NUTTX_SYSTEM_LIBRARIES libpng)
|
||||
```
|
||||
|
||||
## III. FAQ
|
||||
|
||||
### 1. How can I make a module's header files visible to all other modules?
|
||||
|
||||
Use the `nuttx_export_header()` function.
|
||||
|
||||
- **Background**: The `PUBLIC` keyword of `target_include_directories()` is only effective for targets with an explicit dependency relationship (via `target_link_libraries`). In NuttX's flat module structure, there are typically no direct link dependencies between modules, so `PUBLIC` cannot propagate include paths.
|
||||
- **Solution**: `nuttx_export_header()` adds the exported include directory path to a global property, making it visible to all subsequent targets.
|
||||
|
||||
```CMake
|
||||
# nuttx/cmake/nuttx_export_header.cmake
|
||||
|
||||
# Usage:
|
||||
# nuttx_export_header(TARGET <string> INCLUDE_DIRECTORIES <list>)
|
||||
|
||||
# Example (in the CMakeLists.txt for libtommath):
|
||||
nuttx_export_header(TARGET libtommath INCLUDE_DIRECTORIES ${LIBTOMMATH_DIR})
|
||||
```
|
||||
|
||||
- **Usage Recommendation**: This method is suitable for common base libraries. For dependencies between specific libraries, it is still recommended to manage them explicitly using `nuttx_add_dependencies()`.
|
||||
|
||||
### 2. How can I remove or override global compile options?
|
||||
|
||||
**Problem**: The toolchain's default compile options (e.g., `-march`, `-mabi`) conflict with the requirements of a specific chip (e.g., `-mcpu`). How can this be resolved?
|
||||
|
||||
**Solution**: Use the `nuttx_remove_compile_options()` function.
|
||||
|
||||
- **Background**: In Makefiles, the toolchain's default settings can be overridden by redefining `ARCHCPUFLAGS` in `Make.defs`. CMake's `add_compile_options()` has no direct inverse operation, so openvela provides this enhanced function.
|
||||
|
||||
- **Example**:
|
||||
|
||||
```CMake
|
||||
# For example, with a custom toolchain for a RISC-V architecture where
|
||||
# -march and -mabi conflict with -mcpu
|
||||
|
||||
# CMake does not provide an inverse operation for add_compile_options(),
|
||||
# so we can use the enhanced function nuttx_remove_compile_options(ARGS) here.
|
||||
# For this custom RISC-V architecture, remove the conflicting options.
|
||||
nuttx_remove_compile_options(-march -mabi)
|
||||
|
||||
# CFLAGS before removal: -O2 -g -march=rv32if -mabi=ilp32f -mcpu=e907fp
|
||||
# CFLAGS after removal: -O2 -g -mcpu=e907fp
|
||||
```
|
||||
|
||||
## Appendix
|
||||
|
||||
### Core CMake Modules
|
||||
|
||||
NuttX's CMake modules are defined in the `nuttx/cmake/` directory. They are the core extensions of the build system, providing encapsulated, specialized functions, analogous to the `tools` and `.mk` scripts in the Makefile system.
|
||||
|
||||
| **Module File** | **Function Description** |
|
||||
| :----------------------------------- | :----------------------------------------------------------------------------------------------------------- |
|
||||
| `menuconfig.cmake` | Defines configuration targets like `menuconfig` based on Kconfig-frontend. |
|
||||
| `nuttx_add_application.cmake` | A wrapper function for adding NuttX built-in applications. |
|
||||
| `nuttx_add_dependencies.cmake` | An enhanced `add_dependencies` that can automatically pass the include directories of dependent targets. |
|
||||
| `nuttx_add_library.cmake` | An enhanced wrapper function for CMake's `add_library`. |
|
||||
| `nuttx_add_module.cmake` | A wrapper function for generating independent kernel modules (`.ko`). |
|
||||
| `nuttx_add_romfs.cmake` | A wrapper function for adding and generating a ROMFS image. |
|
||||
| `nuttx_add_subdirectory.cmake` | An enhanced wrapper function for CMake's `add_subdirectory`. |
|
||||
| `nuttx_add_symtab.cmake` | Generates a symbol table for undefined symbols. |
|
||||
| `nuttx_create_symlink.cmake` | A method for creating symbolic links (symlinks). |
|
||||
| `nuttx_export_header.cmake` | Exports the include directories of a specified target to a global scope, making them visible to all modules. |
|
||||
| `nuttx_generate_headers.cmake` | Defines the `nuttx_context` target, used for generating necessary header files. |
|
||||
| `nuttx_generate_outputs.cmake` | Defines commands like `objcopy` for generating final artifacts such as `.bin` files. |
|
||||
| `nuttx_kconfig.cmake` | The core logic for Kconfig parsing and `.config` generation. |
|
||||
| `nuttx_mkconfig.cmake` | Generates `include/nuttx/config.h` based on the `.config` file. |
|
||||
| `nuttx_mkversion.cmake` | Generates `include/nuttx/version.h` based on Git information. |
|
||||
| `nuttx_parse_function_args.cmake` | An enhancement for CMake's built-in `cmake_parse_arguments` module. |
|
||||
| `nuttx_redefine_symbols.cmake` | Used for the `sim` simulation platform to rename potentially conflicting symbols. |
|
||||
| `nuttx_remove_compile_options.cmake` | An inverse operation to `add_compile_options`, used for removing global compile options. |
|
||||
| `symtab.c.in` | A code generation template used in conjunction with `nuttx_add_symtab.cmake`. |
|
||||
|
||||
## References
|
||||
|
||||
- [CMake Quick Start Guide](./CMake_quick_start.md)
|
||||
- [Makefile Build System Guide](./Makefile_guide.md)
|
||||
|
|
@ -0,0 +1,405 @@
|
|||
# CMake Quick Start Guide
|
||||
|
||||
\[ English | [简体中文](../../../zh-cn/device_dev_guide/build/CMake_quick_start.md) \]
|
||||
|
||||
This document aims to comprehensively explain the background, advantages, and practical implementation of the openvela project's migration from the GNU Make to the CMake build system. It provides developers with a complete guide for migration, usage, and development.
|
||||
|
||||
If you are not yet familiar with CMake, it is recommended to review the following official resources first to better understand the content of this document:
|
||||
|
||||
- **CMake Official Tutorial:** https://cmake.org/cmake/help/latest/guide/tutorial/index.html
|
||||
- **CMake Official Documentation:** https://cmake.org/documentation/
|
||||
|
||||
## I. Background: Why Migrate to CMake
|
||||
|
||||
To address growing project complexity and the demand for higher developer efficiency, openvela has decided to migrate its build system from the traditional GNU Make to the modern CMake. This upgrade is intended to solve a series of challenges related to compilation efficiency, reliability, and extensibility in the old system.
|
||||
|
||||
### 1. The Challenges of GNU Make
|
||||
|
||||
According to statistics, the current GNU Make-based build system suffers from the following core pain points:
|
||||
|
||||
- **Frequent Issues**: In 2023, out of **1,043** reported issues, **92** were directly related to the build system, accounting for **8.8%** of the total.
|
||||
- **Low Efficiency**: A full CI build now takes over an hour, severely impacting development and continuous integration efficiency.
|
||||
- **Poor Developer Experience**: Developers widely report slow compilation speeds, unreliable incremental builds, incomplete cleanup of build artifacts, and a lack of modular compilation capabilities.
|
||||
|
||||
### 2. Why Choose CMake
|
||||
|
||||
After researching and comparing mainstream build systems, we chose CMake for the following key reasons:
|
||||
|
||||
| Build System | Speed | Auto-Dependency | Cross-Platform Support | Widespread Adoption | Ninja Generator | Community Size | Migration Cost |
|
||||
| :----------- | :----------------- | :-------------- | :--------------------- | :------------------ | :-------------- | :------------- | :------------------- |
|
||||
| CMake | Depends on Backend | Supported | Supported | Highest | Supported | Large | Community Foundation |
|
||||
| GN | Fast | Supported | Supported | Medium | Supported | Small | From Scratch |
|
||||
| SCons | Slow | Supported | Supported | Medium | Not Supported | Small | From Scratch |
|
||||
|
||||
> **Note**: Data reference: [Stack Overflow 2023 Survey](https://survey.stackoverflow.co/2023/#most-popular-technologies-tools-tech)
|
||||
|
||||
With its mature ecosystem, powerful cross-platform capabilities, precise dependency management, and support for high-performance backends like Ninja, CMake is the best choice for this upgrade.
|
||||
|
||||
## II. Core Advantages: The Value of CMake
|
||||
|
||||
Migrating to CMake brings the following significant benefits to openvela developers:
|
||||
|
||||
- **Significantly Improved Compilation Speed**: Measurements show that even when using the same Makefile backend, CMake provides more than a 2x speed improvement. Performance can be further optimized by using the Ninja backend.
|
||||
- **Out-of-Tree Builds**: Build artifacts are kept completely separate from the source code, ensuring a clean source tree. This feature also allows for parallel builds of multiple different configurations from the same source, greatly improving multi-target validation efficiency.
|
||||
- **Precise Dependency Management**: CMake automatically analyzes dependencies between targets, ensuring the correctness and reliability of incremental builds and completely resolving the shortcomings of the old `mkdep` and `.depend` mechanisms.
|
||||
- **Modular Compilation**: Developers can build and verify any specific module independently, facilitating rapid debugging, library distribution, and SDK integration.
|
||||
- **Excellent Cross-Platform Support**: CMake natively supports development on various host environments, including Windows, Linux, and macOS. It seamlessly integrates with multiple build tools and IDEs like GNU Make, Ninja, and Xcode through its generators.
|
||||
- **Improved Development and Debugging Experience**: CMake's syntax is clearer and easier to maintain and extend. Its deep integration with mainstream IDEs like VSCode and CLion provides developers with graphical tools for build configuration and debugging.
|
||||
|
||||
## III. Quick Start
|
||||
|
||||
### 1. Build Steps
|
||||
|
||||
You can configure and compile openvela in two simple steps.
|
||||
|
||||
```Bash
|
||||
# Ensure the current working directory is nuttx/
|
||||
|
||||
# 1. Configure Phase: Generate the build system files
|
||||
# -B build: Specifies 'build' as the build directory (for an out-of-tree build)
|
||||
# -DBOARD_CONFIG=sim/nsh: Specifies the target board configuration.
|
||||
# Can also be an absolute or relative path to a defconfig file.
|
||||
# -GNinja: (Optional) Specifies Ninja as the backend generator. Defaults to Makefile if not set.
|
||||
cmake -B build -DBOARD_CONFIG=sim/nsh -GNinja
|
||||
|
||||
# 2. Build Phase: Execute the compilation
|
||||
# --build build: Specifies that the build should be run in the 'build' directory.
|
||||
cmake --build build
|
||||
```
|
||||
|
||||
### 2. Common Build Options
|
||||
|
||||
| **Option** | **Alias** | **Description** | **Example** |
|
||||
| :------------------ | :-------- | :---------------------------------------------- | :---------------------------------- |
|
||||
| `--build <dir>` | | Specifies the build directory and runs a build. | `cmake --build build` |
|
||||
| `--target <target>` | `-t` | Builds only the specified target. | `cmake --build build -t menuconfig` |
|
||||
| `--parallel <jobs>` | `-j` | Specifies the number of parallel build jobs. | `cmake --build build --parallel 8` |
|
||||
| `--verbose` | `-v` | Prints detailed build logs. | `cmake --build build -v` |
|
||||
| `--clean-first` | | Runs a clean operation before building. | `cmake --build build --clean-first` |
|
||||
|
||||
## IV. [IMPORTANT] Dual Build System Maintenance During the Transition Period
|
||||
|
||||
> **Note: This is a core rule that all developers must follow during the transition phase.**
|
||||
|
||||
To ensure a smooth project transition, openvela will support both Makefile and CMake build systems concurrently for a period of time. When you make any file modifications related to compilation (such as adding/deleting source files or changing compile options), you **must** update both the `Makefile` and the `CMakeLists.txt` file in the same directory to ensure the two systems behave identically.
|
||||
|
||||
## V. Daily Development Practices
|
||||
|
||||
This section guides developers on how to perform daily development tasks in the CMake environment.
|
||||
|
||||
### 1. Adding a New Application
|
||||
|
||||
To integrate a new application into the CMake build system, simply create a `CMakeLists.txt` file in the same directory as its `Makefile`.
|
||||
|
||||
```Bash
|
||||
apps/
|
||||
└── example/
|
||||
└── hello_main/
|
||||
├── hello_main.c
|
||||
├── Kconfig
|
||||
├── Make.defs
|
||||
├── Makefile
|
||||
└── CMakeLists.txt <-- Add this file
|
||||
```
|
||||
|
||||
Example `CMakeLists.txt` content:
|
||||
|
||||
```CMake
|
||||
# Kconfig options (like CONFIG_EXAMPLES_HELLO) are automatically loaded as CMake variables
|
||||
if(CONFIG_EXAMPLES_HELLO)
|
||||
# Call the nuttx_add_application function to register a built-in application
|
||||
nuttx_add_application(
|
||||
NAME ${CONFIG_EXAMPLES_HELLO_PROGNAME} # App name, from Kconfig
|
||||
SRCS hello_main.c # Source file list
|
||||
STACKSIZE ${CONFIG_EXAMPLES_HELLO_STACKSIZE} # Stack size, from Kconfig
|
||||
PRIORITY ${CONFIG_EXAMPLES_HELLO_PRIORITY} # Priority, from Kconfig
|
||||
)
|
||||
endif()
|
||||
```
|
||||
|
||||
Function Prototype Reference: `nuttx_add_application()`
|
||||
|
||||
```CMake
|
||||
nuttx/cmake/nuttx_add_application.cmake
|
||||
|
||||
Usage:
|
||||
nuttx_add_application( NAME <string> [ PRIORITY <string> ]
|
||||
[ STACKSIZE <string> ] [ COMPILE_FLAGS <list> ]
|
||||
[ INCLUDE_DIRECTORIES <list> ] [ DEPENDS <string> ]
|
||||
[ DEFINITIONS <string> ] [ MODULE <string> ] [ SRCS <list> ] )
|
||||
|
||||
Parameters:
|
||||
NAME : unique name of application
|
||||
PRIORITY : priority
|
||||
STACKSIZE : stack size
|
||||
COMPILE_FLAGS : compile flags
|
||||
INCLUDE_DIRECTORIES : include directories
|
||||
DEPENDS : targets which this module depends on
|
||||
DEFINITIONS : optional compile definitions
|
||||
MODULE : if "m", build module (designed to received
|
||||
CONFIG_<app> value)
|
||||
SRCS : source files
|
||||
NO_MAIN_ALIAS : do not add a main=<app>_main alias(*)
|
||||
```
|
||||
|
||||
### 2. Porting a Third-Party Library
|
||||
|
||||
#### Basic Porting Method (Recommended)
|
||||
|
||||
We recommend writing a new `CMakeLists.txt` file to adapt the third-party library for openvela. This allows for precise control over its build behavior.
|
||||
|
||||
```Bash
|
||||
openvela openvela
|
||||
└── external └── external
|
||||
└── ThirdPartyLib (Wrapper) └── ThirdPartyLib (Wrapper)
|
||||
├── Makefile Add ├── Makefile
|
||||
├── Kconfig =========> ├── Kconfig
|
||||
├── Make.defs ├── Make.defs
|
||||
└── ThirdPartyLib (Actual) ├── CMakeLists.txt
|
||||
└── your changes └── ThirdPartyLib (Actual)
|
||||
└── your changes
|
||||
```
|
||||
|
||||
`CMakeLists.txt` structural template (using `libtommath` as an example):
|
||||
|
||||
```CMake
|
||||
# Example source: nuttx/apps/math/libtommath/CMakeLists.txt
|
||||
|
||||
# 1. Enable Switch: Check if the library is enabled in Kconfig
|
||||
if(CONFIG_MATH_LIBTOMMATH)
|
||||
|
||||
# #####################################################
|
||||
# Config and Fetch Tommath lib
|
||||
# This stage is analogous to the 'context' preparation step in the original Makefile.
|
||||
# #####################################################
|
||||
|
||||
# 2. Source Code Preparation: (Optional) If needed, use FetchContent to
|
||||
# automatically download and extract the source code.
|
||||
set(LIBTOMMATH_DIR ${CMAKE_CURRENT_LIST_DIR}/libtommath)
|
||||
|
||||
if(NOT EXISTS ${LIBTOMMATH_DIR})
|
||||
set(CONFIG_LIBTOMMATH_URL https://github.com/libtom/libtommath/archive)
|
||||
# Use CMake's FetchContent module to get external resources
|
||||
FetchContent_Declare(
|
||||
libtommath_fetch
|
||||
URL ${CONFIG_LIBTOMMATH_URL}/v${CONFIG_LIBTOMMATH_VERSION}.zip SOURCE_DIR
|
||||
${CMAKE_CURRENT_LIST_DIR}/libtommath BINARY_DIR
|
||||
${CMAKE_BINARY_DIR}/apps/math/libtommath/libtommath
|
||||
DOWNLOAD_NO_PROGRESS true
|
||||
TIMEOUT 30)
|
||||
|
||||
FetchContent_GetProperties(libtommath_fetch)
|
||||
if(NOT libtommath_fetch_POPULATED)
|
||||
FetchContent_Populate(libtommath_fetch)
|
||||
endif()
|
||||
endif()
|
||||
|
||||
# ########################################################
|
||||
# Sources: Add the third-party library's source files
|
||||
# ########################################################
|
||||
# 3. Source File Definition: Use file(GLOB ...) or list all required source files directly.
|
||||
file(GLOB CSRCS ${LIBTOMMATH_DIR}/*.c) # Using file() here
|
||||
|
||||
if(CONFIG_LIBTOMMATH_DEMOS)
|
||||
list(APPEND CSRCS ${LIBTOMMATH_DIR}/demo/shared.c) # You can also append individual files
|
||||
endif()
|
||||
|
||||
# #########################################################
|
||||
# Include Directory: Path for the third-party library's headers
|
||||
# #########################################################
|
||||
# 4. Include Directory Definition: Specify the library's public include directory.
|
||||
set(INCDIR ${LIBTOMMATH_DIR})
|
||||
|
||||
# ########################################################
|
||||
# Flags: Configure compile options for the third-party library
|
||||
# #######################################################
|
||||
# 5. Compile Flags Definition: (Optional) Set specific compile flags for this library.
|
||||
set(CFLAGS -Wno-format)
|
||||
|
||||
# #########################################################
|
||||
# Library Configuration: Add the third-party library
|
||||
# #########################################################
|
||||
|
||||
# 6. Register the Library Target: Define it as a static library using nuttx_add_library.
|
||||
nuttx_add_library(libtommath STATIC)
|
||||
|
||||
# 7. Configure the Library Target: Apply the source files, include paths,
|
||||
# and compile options to the target.
|
||||
target_compile_options(libtommath PRIVATE ${CFLAGS})
|
||||
target_sources(libtommath PRIVATE ${CSRCS})
|
||||
target_include_directories(libtommath PRIVATE ${INCDIR})
|
||||
|
||||
# ###########################################################
|
||||
# Applications Configuration: If there are applications, add them as before.
|
||||
# ###########################################################
|
||||
# 8. (Optional) Add Example Applications: If the library includes examples
|
||||
# or test programs, they can be added here.
|
||||
if(CONFIG_LIBTOMMATH_TEST)
|
||||
nuttx_add_application(
|
||||
NAME
|
||||
${CONFIG_LIBTOMMATH_TEST_PROGNAME}
|
||||
STACKSIZE
|
||||
${CONFIG_LIBTOMMATH_TEST_STACKSIZE}
|
||||
PRIORITY
|
||||
${CONFIG_LIBTOMMATH_TEST_PRIORITY}
|
||||
SRCS
|
||||
${LIBTOMMATH_DIR}/demo/test.c
|
||||
INCLUDE_DIRECTORIES
|
||||
${INCDIR}
|
||||
DEPENDS
|
||||
libtommath)
|
||||
endif()
|
||||
endif()
|
||||
```
|
||||
|
||||
For other porting methods, please see [Advanced Development Practices: Porting Third-Party Libraries](./CMake_advanced_guide.md#2-porting-a-third-party-library).
|
||||
|
||||
### 3. Adapting Custom Boards and Chips
|
||||
|
||||
To add CMake support for your custom hardware, you need to create `CMakeLists.txt` files in the corresponding `board` and `chip` directories.
|
||||
|
||||
Example directory structure:
|
||||
|
||||
```Bash
|
||||
# Location: vendor/vendor_name
|
||||
├── boards
|
||||
│ ├── <chip_name>
|
||||
│ │ └── <board_name>
|
||||
│ │ ├── Kconfig
|
||||
│ │ ├── CMakeLists.txt <-- Add this
|
||||
│ │ └── src
|
||||
│ │ ├── Make.defs
|
||||
│ │ └── CMakeLists.txt <-- Add this
|
||||
├── chips
|
||||
│ └── chip_name
|
||||
│ ├── Kconfig
|
||||
│ ├── Make.defs
|
||||
│ └── CMakeLists.txt <-- Add this
|
||||
```
|
||||
|
||||
Example `CMakeLists.txt` content:
|
||||
|
||||
1. `chips/<`**`chip_name`**`>/CMakeLists.txt`:
|
||||
|
||||
```Makefile
|
||||
# Add the source files for the custom chip
|
||||
set(SRCS chip_startup.S)
|
||||
|
||||
# Note: Add sources to the 'arch' target, which will be archived into libarch.a
|
||||
target_sources(arch PRIVATE ${SRCS})
|
||||
```
|
||||
|
||||
2. `boards/<`**`chip_name`**`>/<`**`board_name`**`>/src/CMakeLists.txt`:
|
||||
|
||||
```Makefile
|
||||
# Add the source files for the custom board
|
||||
set(SRCS board_source.c)
|
||||
|
||||
# Note: Add sources to the 'board' target, which will be archived into libboard.a
|
||||
target_sources(board PRIVATE ${SRCS})
|
||||
```
|
||||
|
||||
3. `boards/<`**`chip_name`**`>/<`**`board_name`**`>/CMakeLists.txt`:
|
||||
|
||||
```CMake
|
||||
# Add the custom/board/src directory to the build structure
|
||||
add_subdirectory(src)
|
||||
|
||||
# Set the path to the linker script
|
||||
set_property(
|
||||
GLOBAL
|
||||
PROPERTY
|
||||
LD_SCRIPT
|
||||
"${NUTTX_BOARD_ABS_DIR}/scripts/app.ld"
|
||||
)
|
||||
|
||||
# Define a post_build target for automatic processing of artifacts after the build
|
||||
add_custom_target(
|
||||
nuttx_post_build ALL
|
||||
POST_BUILD
|
||||
COMMAND ${NUTTX_DIR}/../vendor/xxx/post_build.sh ${CMAKE_BINARY_DIR}
|
||||
)
|
||||
```
|
||||
|
||||
## VI. FAQ
|
||||
|
||||
### 1. What is the most important principle when writing CMakeLists.txt?
|
||||
|
||||
Maintain the purity of out-of-tree builds. You must ensure that all build operations are performed within the build directory (Binary Tree) and strictly avoid modifying the source directory (Source Tree). Operations like creating symbolic links or modifying files, which were common in the old Makefile system, should be migrated to execute within the build directory.
|
||||
|
||||
### 2. Is there a required format for CMake code?
|
||||
|
||||
**Yes**. openvela uses `cmake-format` from the `cmakelang` toolset to format CMake code. You must run the formatting command before committing code; otherwise, the CI check will fail.
|
||||
|
||||
```Makefile
|
||||
# Reference: https://cmake-format.readthedocs.io/en/latest/cmake-format.html
|
||||
# Install the tool
|
||||
pip3 install cmake-format
|
||||
# Format a file (in-place modification)
|
||||
cmake-format -i CMakeLists.txt
|
||||
|
||||
# usage:
|
||||
# cmake-format [-h]
|
||||
# [--dump-config {yaml,json,python} | -i]
|
||||
# [-c CONFIG_FILE]
|
||||
# infilepath [infilepath ...]
|
||||
```
|
||||
|
||||
### 3. How should I handle dependencies between modules?
|
||||
|
||||
Use the `nuttx_add_dependencies()` function. It automatically adds the public include directories of a dependency to any module that depends on it.
|
||||
|
||||
```CMake
|
||||
# Scenario: libtomcrypt depends on libtommath
|
||||
|
||||
# In libtommath's CMakeLists.txt:
|
||||
nuttx_add_library(libtommath STATIC)
|
||||
nuttx_export_header(TARGET libtommath INCLUDE_DIRECTORIES ${LIBTOMMATH_DIR})
|
||||
|
||||
# In libtomcrypt's CMakeLists.txt:
|
||||
nuttx_add_library(libtomcrypt STATIC)
|
||||
# libtomcrypt will automatically get the include path for libtommath
|
||||
nuttx_add_dependencies(TARGET libtomcrypt DEPENDS libtommath)
|
||||
```
|
||||
|
||||
### 4. How can I set unique compile options for a specific file?
|
||||
|
||||
Use the `set_source_files_properties()` function.
|
||||
|
||||
```CMake
|
||||
# Use CMake's set_source_files_properties()
|
||||
set_source_files_properties(
|
||||
${CMAKE_CURRENT_LIST_DIR}/source.c
|
||||
PROPERTIES
|
||||
COMPILE_FLAGS -O2)
|
||||
```
|
||||
|
||||
### 5. How do I link a pre-compiled static library (.a file)?
|
||||
|
||||
Use the `nuttx_add_extra_library()` function.
|
||||
|
||||
```CMake
|
||||
# Call the function
|
||||
nuttx_add_extra_library(${NUTTX_CHIP_ABS_DIR}/libadc.a)
|
||||
```
|
||||
|
||||
### 6. How can I customize post-build actions (like packaging firmware)?
|
||||
|
||||
- The original Makefile build provided a `POSTBUILD` macro for customizing post-build artifact handling.
|
||||
- CMake offers a similar method:
|
||||
|
||||
```CMake
|
||||
# Inside the custom board's CMakeLists.txt
|
||||
# Define a custom 'nuttx_post_build' target
|
||||
add_custom_target(
|
||||
nuttx_post_build ALL
|
||||
POST_BUILD
|
||||
# Define any custom post-build actions here
|
||||
COMMAND ${NUTTX_DIR}/../vendor/xxx/post_build.sh ${CMAKE_BINARY_DIR}
|
||||
)
|
||||
```
|
||||
|
||||
## References
|
||||
|
||||
- Further Reading: [CMake In-Depth Analysis and Maintenance Manual](./CMake_advanced_guide.md)
|
||||
- Makefile: [Makefile Build System Guide](./Makefile_guide.md)
|
||||
|
|
@ -16,7 +16,7 @@ To modify configuration parameters during project setup, perform the following v
|
|||
|
||||
You can examine the `.config` file to determine whether the configuration has been set and if its value meets the expected criteria. If it does, you may use it as is; otherwise, it is recommended to adjust the setting using the `menuconfig` tool.
|
||||
|
||||
**Note:** Using the `menuconfig` tool ensures that all configuration dependencies are complete and correct.
|
||||
> **Note:** Using the `menuconfig` tool ensures that all configuration dependencies are complete and correct.
|
||||
|
||||
2. Example: Configuring the KVDB storage path.
|
||||
|
||||
|
|
@ -58,7 +58,7 @@ During the initial build, openvela locates the corresponding project's defconfig
|
|||
- The `.config` file is the complete configuration generated from the `defconfig` file, incorporating all extended and combined configuration options.
|
||||
- The `menuconfig` interface reads the local `.config` file for user-customized configuration adjustments and automatically propagates validated changes back to the `defconfig` file upon completion.
|
||||
|
||||
3. config.h
|
||||
3. `config.h`
|
||||
|
||||
- The `config.h` file is generated from the `.config` file, containing all configuration information to support conditional compilation and runtime operations in the code.
|
||||
|
||||
|
|
@ -105,7 +105,7 @@ The following diagram illustrates a typical build configuration workflow:
|
|||
|
||||
In the `menuconfig` interface, you can enter `/` followed by a configuration keyword to search. For example, to search for `EXAMPLES_HELLO`:
|
||||
|
||||
**Note**: If the search results contain `depends on` dependencies, type `?` to continue searching for dependent configurations and enable them.
|
||||
> **Note**: If the search results contain `depends on` dependencies, type `?` to continue searching for dependent configurations and enable them.
|
||||
|
||||

|
||||
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
# Build System
|
||||
# Makefile Build System
|
||||
|
||||
\[ English | [简体中文](../../../zh-cn/device_dev_guide/build/build_system.md) \]
|
||||
\[ English | [简体中文](../../../zh-cn/device_dev_guide/build/Makefile_guide.md) \]
|
||||
|
||||
## I. Overview
|
||||
|
||||
|
|
@ -20,7 +20,7 @@ In addition to the core build files, the following key files and configurations
|
|||
- Location: `nuttx/Make.defs`.
|
||||
- Source: Copied from the template file located at `nuttx/board/${arch}/${chip}/${board}/${config}/scripts/Make.defs`.
|
||||
|
||||
2. Conditional build configuration file.
|
||||
2. Conditional build configuration file.
|
||||
|
||||
- Location: `configs/defconfig` in the root directory.
|
||||
- Function: Copied as `.config` and serves as the base configuration file for **openvela**, supporting highly customizable and modular configurations.
|
||||
|
|
@ -88,7 +88,10 @@ Makefile Example:
|
|||
# properly configured. The basic configuration steps include creation of the
|
||||
# the config.h and version.h header files in the include/nuttx directory and
|
||||
# the establishment of symbolic links to configured directories.
|
||||
## tools/Unix.mk 核心Makefile文件
|
||||
```
|
||||
|
||||
```Makefile
|
||||
## tools/Unix.mk: Core Makefile
|
||||
|
||||
%.context: include/nuttx/config.h .dirlinks
|
||||
$(Q) $(MAKE) -C $(patsubst %.context,%,$@) TOPDIR="$(TOPDIR)" context
|
||||
|
After Width: | Height: | Size: 81 KiB |
|
After Width: | Height: | Size: 40 KiB |
|
|
@ -36,7 +36,7 @@ openvela Bluetooth also supports various open‑source and proprietary stacks, s
|
|||
|
||||
- The openvela Bluetooth Framework provides a unified programming API for `Android Native`, wearables, speakers, IoT, and other applications.
|
||||
- These APIs cover Bluetooth operations such as power on/off, scanning, connecting, and pairing, all implemented by a comprehensive set of Bluetooth service components.
|
||||
- To support multiple stacks, the Bluetooth Framework defines a unified Stack Abstraction Layer interface (`SAL API`), allowing third‑party stacks to integrate easily with OpenVela. When integrating a new stack, in addition to adapting the `SAL API`, you must also adapt NuttX’s `POSIX APIs` so that the stack runs efficiently on `NuttX`.
|
||||
- To support multiple stacks, the Bluetooth Framework defines a unified Stack Abstraction Layer interface (`SAL API`), allowing third‑party stacks to integrate easily with openvela. When integrating a new stack, in addition to adapting the `SAL API`, you must also adapt NuttX’s `POSIX APIs` so that the stack runs efficiently on `NuttX`.
|
||||
|
||||
## III. Code Directory
|
||||
|
||||
|
|
@ -89,7 +89,7 @@ Additionally, the Bluetooth Framework provides NDK interfaces to access all Blue
|
|||
|
||||
### 2. Bluetooth Driver Development
|
||||
|
||||
OpenVela Bluetooth supports multiple driver architectures. Below is an example using the common BTH4 driver architecture to implement and register a Bluetooth driver.
|
||||
openvela Bluetooth supports multiple driver architectures. Below is an example using the common BTH4 driver architecture to implement and register a Bluetooth driver.
|
||||
|
||||
#### Implementing the Driver
|
||||
|
||||
|
|
@ -123,5 +123,5 @@ When HCI data arrives from the chip, simply call `bt_netdev_receive()`, which in
|
|||
## V. Related Repositories
|
||||
|
||||
- [frameworks_bluetooth](../../../../../../../frameworks_bluetooth): Provides rich Bluetooth application programming interfaces for developers, including API layers, service components, SAL abstraction, and HAL layers. The repo also includes tools like [bttool](../bluetooth/functionality_test/bttool_cmd.md) for testing Bluetooth features and sample API usage.
|
||||
- [external_zblue](../../../../../../../external_zblue): Based on Zephyr’s stack, enhanced by OpenVela.
|
||||
- [external_zblue](../../../../../../../external_zblue): Based on Zephyr’s stack, enhanced by openvela.
|
||||
- [docs](../../../../../../../docs): Contains additional technical documentation for the Bluetooth module.
|
||||
|
|
|
|||
|
|
@ -316,7 +316,7 @@ bttool> set leaddr 01:02:03:04:05:06
|
|||
The expected results are as follows:
|
||||
|
||||
```Plain
|
||||
[ 80.646100] [49] [ DEBUG] [ap] [1362][adapter-svc]: adapter_on_le_addr_update
|
||||
bttool> [ 80.646100] [49] [ DEBUG] [ap] [1362][adapter-svc]: adapter_on_le_addr_update
|
||||
```
|
||||
|
||||
### 7. id
|
||||
|
|
|
|||
|
|
@ -1,21 +1,21 @@
|
|||
# bttool Command Description
|
||||
# bttool Command
|
||||
|
||||
\[ English | [简体中文](../../../../../zh-cn/device_dev_guide/connection/bluetooth/functionality_test/bttool_cmd.md) \]
|
||||
|
||||
## I. Introduction
|
||||
|
||||
Executed in the OpenVela NSH command line to enter the Bluetooth command tool console. Within this console, you can execute `bttool`’s built‑in sub-commands.
|
||||
Executed in the openvela NSH command line to enter the Bluetooth command tool console. Within this console, you can execute `bttool`’s built‑in sub-commands.
|
||||
|
||||
## II. Syntax
|
||||
|
||||
| **Syntax Element** | **Description** | **Example** |
|
||||
| :--------------------------- | :--------------------------------------------------- | :-------------------------------------------------------------------------- |
|
||||
| Text without brackets/braces | Items that must be typed exactly as shown. | `cd` <br> The `cd` portion of the command must be typed verbatim. |
|
||||
| <Text in angle brackets> | Placeholders requiring value substitution. | `mkdir <directory_name>` <br> Replace `<directory_name>` with an actual. |
|
||||
| [Text in square brackets] | Optional items. | `ls [-l]` <br> `[-l]` is optional to display files in long list format. |
|
||||
| {Text in curly braces} | Required group - exactly one item must be selected. | `git reset { --soft \| --mixed \| --hard }` <br> Select one option, e.g., `git reset --soft`. |
|
||||
| Vertical bar \| | Separator for mutually exclusive items. | `git reset { --soft \| --mixed \| --hard }` <br> Choose only one of the options. |
|
||||
| Ellipsis … | Items that can be repeated multiple times. | `cp <file1> <file2> … <destination>` <br> Copy multiple files to destination. |
|
||||
| **Syntax Element** | **Description** | **Example** |
|
||||
| :--------------------------- | :-------------------------------------------------- | :-------------------------------------------------------------------------------------------- |
|
||||
| Text without brackets/braces | Items that must be typed exactly as shown. | `cd` <br> The `cd` portion of the command must be typed verbatim. |
|
||||
| \<Text in angle brackets\> | Placeholders requiring value substitution. | `mkdir <directory_name>` <br> Replace `<directory_name>` with an actual. |
|
||||
| [Text in square brackets] | Optional items. | `ls [-l]` <br> `[-l]` is optional to display files in long list format. |
|
||||
| {Text in curly braces} | Required group - exactly one item must be selected. | `git reset { --soft \| --mixed \| --hard }` <br> Select one option, e.g., `git reset --soft`. |
|
||||
| Vertical bar \| | Separator for mutually exclusive items. | `git reset { --soft \| --mixed \| --hard }` <br> Choose only one of the options. |
|
||||
| Ellipsis … | Items that can be repeated multiple times. | `cp <file1> <file2> … <destination>` <br> Copy multiple files to destination. |
|
||||
|
||||
## III. Example
|
||||
|
||||
|
|
|
|||
|
|
@ -17,18 +17,22 @@ The implementation of these member functions depends on the actual operation of
|
|||
|
||||
### Example
|
||||
|
||||
- To quickly validate custom callbacks and driver registration in a QEMU environment, this example implements the `struct bt_driver_s` member functions directly within the [drivers_initialize](../../../../../../../nuttx/blob/dev/drivers/drivers_initialize.c) function and completes driver registration.
|
||||
- In a real integration or production scenario, it is recommended to create a separate source file under the [vendor](../../../../../../vendor_template/blob/dev/boards/chip_name/board_name/src) directory for maintainability and version control.
|
||||
#### Note
|
||||
|
||||
1. In [drivers_initialize.c](../../../../../../../nuttx/blob/dev/drivers/drivers_initialize.c), add the `bt_driver.h` header include:
|
||||
- To quickly validate custom callbacks and driver registration in a QEMU environment, this example implements the `struct bt_driver_s` member functions directly within the [drivers_initialize](../../../../../../../nuttx/blob/trunk-5.5/drivers/drivers_initialize.c) function and completes driver registration.
|
||||
- In a real integration or production scenario, it is recommended to create a separate source file under the [vendor](../../../../../../../vendor_template/blob/trunk-5.5/boards/chip_name/board_name/src) directory for maintainability and version control.
|
||||
|
||||
#### Steps
|
||||
|
||||
1. In [drivers_initialize.c](../../../../../../../nuttx/blob/trunk-5.5/drivers/drivers_initialize.c), add the [bt_driver.h](../../../../../../../nuttx/blob/trunk-5.5/include/nuttx/wireless/bluetooth/bt_driver.h) header include:
|
||||
|
||||
```C
|
||||
#include <nuttx/wireless/bluetooth/bt_driver.h> /* Add bt_driver.h header include */
|
||||
```
|
||||
|
||||
2. In [drivers_initialize.c](../../../../../../../nuttx/blob/dev/drivers/drivers_initialize.c), implement the member functions.
|
||||
2. In [drivers_initialize.c](../../../../../../../nuttx/blob/trunk-5.5/drivers/drivers_initialize.c), implement the member functions.
|
||||
|
||||
In openvela, the `receive` member function of `struct bt_driver_s` already has a default implementation in [uart_bth4.c](../../../../../../../nuttx/blob/dev/drivers/serial/uart_bth4.c). Therefore, developers or vendors do not need to redefine or implement this method.
|
||||
In openvela, the `receive` member function of `struct bt_driver_s` already has a default implementation in [uart_bth4.c](../../../../../../../nuttx/blob/trunk-5.5/drivers/serial/uart_bth4.c). Therefore, developers or vendors do not need to redefine or implement this method.
|
||||
|
||||
```C
|
||||
/* The following are sample implementations for demonstration only.
|
||||
|
|
@ -64,7 +68,7 @@ The implementation of these member functions depends on the actual operation of
|
|||
/* 4. The receive member function is assigned by openvela at registration time */
|
||||
```
|
||||
|
||||
3. In [drivers_initialize.c](../../../../../../../nuttx/blob/dev/drivers/drivers_initialize.c), define the `struct bt_driver_s` structure.
|
||||
3. In [drivers_initialize.c](../../../../../../../nuttx/blob/trunk-5.5/drivers/drivers_initialize.c), define the `struct bt_driver_s` structure.
|
||||
|
||||
The following code shows a complete example of initializing a `struct bt_driver_s` instance, where the function pointers are assigned to the sample functions defined above:
|
||||
|
||||
|
|
@ -90,7 +94,7 @@ After implementing the above structure, register the driver instance using one o
|
|||
|
||||
- `bt_driver_register_with_id(FAR struct bt_driver_s *driver, int id)`: Registers with the specified id
|
||||
|
||||
The type definition `int bt_driver_register(FAR struct bt_driver_s *drv)` can be found in the header [bt_driver.h](../../../../../../../nuttx/blob/dev/include/nuttx/wireless/bluetooth/bt_driver.h). Vendors or developers do not need to define the `receive()` member function; the BTH4 driver will initialize it.
|
||||
The type definition `int bt_driver_register(FAR struct bt_driver_s *drv)` can be found in the header [bt_driver.h](../../../../../../../nuttx/blob/trunk-5.5/include/nuttx/wireless/bluetooth/bt_driver.h). Vendors or developers do not need to define the `receive()` member function; the BTH4 driver will initialize it.
|
||||
|
||||
The call flow is shown below:
|
||||
|
||||
|
|
@ -98,7 +102,7 @@ The call flow is shown below:
|
|||
|
||||
### Example
|
||||
|
||||
After completing the driver implementation example above, call the driver registration API at the end of the `drivers_initialize()` function in [drivers_initialize.c](../../../../../../../nuttx/blob/dev/drivers/drivers_initialize.c) to complete the driver registration:
|
||||
After completing the driver implementation example above, call the driver registration API at the end of the `drivers_initialize()` function in [drivers_initialize.c](../../../../../../../nuttx/blob/trunk-5.5/drivers/drivers_initialize.c) to complete the driver registration:
|
||||
|
||||
```C
|
||||
void drivers_initialize(void)
|
||||
|
|
|
|||
|
|
@ -562,7 +562,7 @@ Below are links to related implementations in Linux for reference:
|
|||
- [wext-sme.c](https://elixir.bootlin.com/linux/latest/source/net/wireless/wext-sme.c#L43)((Specific implementation)
|
||||
- [wext-compat.c](https://elixir.bootlin.com/linux/latest/source/net/wireless/wext-compat.c#L1463)((Compatibility implementation)
|
||||
|
||||
## VI.Testing Tools
|
||||
## VI. Testing Tools
|
||||
|
||||
openvela provides multiple network testing tools for driver migration and network throughput debugging. Below are descriptions and usage of relevant tools.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Detailed Explanation of curl Command
|
||||
# curl
|
||||
|
||||
\[ English | [简体中文](../../../../../zh-cn/device_dev_guide/connection/network/network_tools/curl.md) \]
|
||||
|
||||
|
|
@ -17,9 +17,7 @@ CONFIG_LIB_CURL=y
|
|||
CONFIG_UTILS_CURL=y
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> Ensure these options are properly configured to meet the dependencies required for the curl tool.
|
||||
> **Note**: Ensure these options are properly configured to meet the dependencies required for the curl tool.
|
||||
|
||||
## III. Common Use Cases
|
||||
|
||||
|
|
@ -75,7 +73,7 @@ The openvela-equipped device and PC must connect to the same router (wired or wi
|
|||
curl -o /data/ota.zip http://<YOUR_FILE_SERVER_IP>:8000/ota.zip &
|
||||
```
|
||||
|
||||
### 2.Uploading Device Files
|
||||
### 2. Uploading Device Files
|
||||
|
||||
Follow these steps to upload files from the device to a local PC using curl.
|
||||
|
||||
|
|
@ -156,9 +154,9 @@ Follow these steps to upload files from the device to a local PC using curl.
|
|||
ifconfig
|
||||
```
|
||||
|
||||
- Ensure the device and PC are on the same network, and port 4321 is unblocked.
|
||||
- Ensure the device and PC are on the same network, and port `4321` is unblocked.
|
||||
|
||||
### 3、Retrieving Web Content
|
||||
### 3. Retrieving Web Content
|
||||
|
||||
Use `curl` to fetch and print webpage content:
|
||||
|
||||
|
|
@ -207,7 +205,7 @@ curl -L -o /data/test.mp3 https://example.com
|
|||
| = | %3D |
|
||||
| # | %23 |
|
||||
|
||||
### 5.Network Performance Testing
|
||||
### 5. Network Performance Testing
|
||||
|
||||
Measure TCP/SSL handshake times with -w.
|
||||
|
||||
|
|
|
|||
|
|
@ -44,15 +44,15 @@ To use the ifconfig command, enable network support and proc filesystem support
|
|||
ifconfig interface [[inet|inet6] [<ip-address>|dhcp]] [dr|gw|gateway <dr-address>] [netmask <net-mask>|prefixlen <len>] [dns <dns-address>] [hw <hw-mac>]]
|
||||
```
|
||||
|
||||
| Parameter | Description |
|
||||
| ------------------------------------- | ---------------------------------------------------------- |
|
||||
| interface | Interface name (e.g., eth0 for Ethernet, wlan0 for Wi-Fi). |
|
||||
| inet/inet6 | Address family (IPv4/IPv6). |
|
||||
| \<ip-address>\|dhcp | Static IP assignment or DHCP-based dynamic address. |
|
||||
| dr\|gw\|gateway \<dr-address> | Configure gateway address. |
|
||||
| netmask \<net-mask>\|prefixlen \<len> | Set IP netmask (default derived from IP class). |
|
||||
| dns \<dns-address> | Configure DNS server. |
|
||||
| hw \<hw-mac> | Set hardware MAC address (if supported by driver). |
|
||||
| Parameter | Description |
|
||||
| --------------------------------------- | ---------------------------------------------------------- |
|
||||
| interface | Interface name (e.g., eth0 for Ethernet, wlan0 for Wi-Fi). |
|
||||
| inet/inet6 | Address family (IPv4/IPv6). |
|
||||
| \<ip-address\>\|dhcp | Static IP assignment or DHCP-based dynamic address. |
|
||||
| dr\|gw\|gateway \<dr-address\> | Configure gateway address. |
|
||||
| netmask \<net-mask\>\|prefixlen \<len\> | Set IP netmask (default derived from IP class). |
|
||||
| dns \<dns-address\> | Configure DNS server. |
|
||||
| hw \<hw-mac\> | Set hardware MAC address (if supported by driver). |
|
||||
|
||||
## IV. Common Commands
|
||||
|
||||
|
|
|
|||
|
|
@ -91,10 +91,8 @@ Use the following command to set up a regular socket client and connect to the s
|
|||
iperf -c <server IP> -i 1 [-u]
|
||||
```
|
||||
|
||||
> **Note**
|
||||
>
|
||||
> iperf's UDP client has no termination information, so the UDP server does not stop automatically.
|
||||
After the test, you need to manually press "Ctrl + C" to stop.
|
||||
> **Note**: iperf's UDP client has no termination information, so the UDP server does not stop automatically.
|
||||
After the test, you need to manually press `Ctrl + C` to stop.
|
||||
|
||||
#### 3.2 rpmsg socket client
|
||||
|
||||
|
|
@ -117,7 +115,7 @@ iperf -c <path> --local [-u]
|
|||
|
||||
- `< path >`: Any string, as long as it matches the`path `specified by the server.
|
||||
- `-u`: Can be used with the `-u` parameter to test DGRAM mode, similar to UDP for ordinary sockets.
|
||||
- After the test, the server needs to manually press Ctrl + C to stop.
|
||||
- After the test, the server needs to manually press `Ctrl + C` to stop.
|
||||
|
||||
## IV. Interpretation of the results
|
||||
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ CONFIG_UTILS_IPERF2=y
|
|||
|
||||
#### common parameters
|
||||
|
||||
Iperf2 supports a variety of parameter settings. The following are common parameters and their descriptions:
|
||||
iperf2 supports a variety of parameter settings. The following are common parameters and their descriptions:
|
||||
|
||||
- `-f [k | m | K | M]`: Specifies the units in which the report is displayed.
|
||||
- `k` and`m `are displayed in Kbits and Mbits.
|
||||
|
|
@ -145,7 +145,7 @@ Iperf2 supports a variety of parameter settings. The following are common parame
|
|||
- `-F file`: Specifies the file to be transferred.
|
||||
- `-T ttl`: Specifies the TTL value.
|
||||
|
||||
### 2. start the server level
|
||||
### 2. Start the server level
|
||||
|
||||
Run the following command to set up a regular socket server:
|
||||
|
||||
|
|
@ -175,7 +175,7 @@ When using iperf2, please note the following to avoid potential problems:
|
|||
|
||||
- Avoid launching multiple iperf2 instances simultaneously.
|
||||
|
||||
Due to the particularity of RTOS, do not start two iperf2 in the same OpenVela instance at the same time, otherwise you may cause problems such as crashes.
|
||||
Due to the particularity of RTOS, do not start two iperf2 in the same openvela instance at the same time, otherwise you may cause problems such as crashes.
|
||||
|
||||
- Termination of the background startup process:
|
||||
|
||||
|
|
|
|||
|
|
@ -125,7 +125,7 @@ The following are the commonly used parameters of iperf3 and their functional de
|
|||
- `-M size`: Sets the MSS (maximum segment size) of the TCP data packet.
|
||||
- `-N`: Enable TCP non-delay mode.
|
||||
|
||||
### 2. start the server level
|
||||
### 2. Start the server level
|
||||
|
||||
Run the following command to set up a regular socket server:
|
||||
|
||||
|
|
@ -207,7 +207,7 @@ Connecting to host 192.0.2.1, port 5201
|
|||
|
||||
- openvela compatible version:
|
||||
|
||||
The current OpenVela compatible version of iperf3 is 3.11.
|
||||
The current openvela compatible version of iperf3 is 3.11.
|
||||
|
||||
- Ubuntu Common Version:
|
||||
|
||||
|
|
|
|||
|
|
@ -42,7 +42,7 @@ CONFIG_SYSTEM_TCPDUMP_STACKSIZE=8192
|
|||
Before using `tcpdump `to capture packages, the following preparations need to be completed:
|
||||
|
||||
- Prepare storage directories: Make sure there are available directories on the device for storing capture files, depending on the storage method of the device.
|
||||
- Mount the host directory (for OpenVela SIM environment): The host directory can be mounted on the device for easy storage of capture files.
|
||||
- Mount the host directory (for openvela SIM environment): The host directory can be mounted on the device for easy storage of capture files.
|
||||
|
||||
```Bash
|
||||
# Take the SIM as an example, mount the directory on the host to /data1
|
||||
|
|
|
|||
|
|
@ -8,15 +8,49 @@
|
|||
|
||||
The OS network protocol stack mainly handles Layer 2, Layer 3, and Layer 4 protocols during network communication. Below is a comparison between the OSI seven-layer network model and the TCP/IP four-layer model, along with the corresponding network protocols used in network communications:
|
||||
|
||||
| **OSI 7-Layer Model** | **TCP/IP 4-Layer Conceptual Model** | **Corresponding Network Protocols** |
|
||||
| :-------------------- | :---------------------------------- | :-------------------------------------- |
|
||||
| Application Layer | Application Layer | HTTP, TFTP, FTP, NFS, WAIS, SMTP |
|
||||
| Presentation Layer | | Telnet, Rlogin, SNMP, Gopher |
|
||||
| Session Layer | | SMTP, DNS |
|
||||
| Transport Layer | Transport Layer | TCP, UDP |
|
||||
| Network Layer | Network Layer | IP, ICMP, ARP, RARP, AKP, UUCP |
|
||||
| Data Link Layer | Data Link Layer | FDDI, Ethernet, Arpanet, PDN, SLIP, PPP |
|
||||
| Physical Layer | | IEEE 802.1A, IEEE 802.2–IEEE 802.11 |
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>TCP/IP 4-Layer Model</th>
|
||||
<th>OSI 7-Layer Model</th>
|
||||
<th>Protocol Examples</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<td rowspan="3"><b>Application Layer</b></td>
|
||||
<td>Application Layer</td>
|
||||
<td>HTTP, FTP, SMTP, DNS, Telnet</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Presentation Layer</td>
|
||||
<td>JPEG, ASCII, TLS, SSL</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Session Layer</td>
|
||||
<td>RPC, NetBIOS</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>Transport Layer</b></td>
|
||||
<td>Transport Layer</td>
|
||||
<td>TCP, UDP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td><b>Network Layer</b></td>
|
||||
<td>Network Layer</td>
|
||||
<td>IP, ICMP, ARP, RARP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="2"><b>Network Interface Layer</b></td>
|
||||
<td>Data Link Layer</td>
|
||||
<td>Ethernet, PPP, SLIP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>Physical Layer</td>
|
||||
<td>Cables, Hubs, Repeaters</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
|
||||
### 2. Capabilities of the openvela Network Protocol Stack
|
||||
|
||||
|
|
@ -76,7 +110,7 @@ The openvela network protocol stack supports multiple network and transport laye
|
|||
The openvela network protocol stack supports both IPv4 and IPv6 protocols and offers the following extended features:
|
||||
|
||||
- ARP and NDP Protocols.
|
||||
-DHCP / DHCPv6: Supports both DHCP client and server functionalities.
|
||||
- DHCP / DHCPv6: Supports both DHCP client and server functionalities.
|
||||
- Fragmentation Support: Supports fragmentation in both IPv4 and IPv6.
|
||||
- 6LoWPAN: Supports the Low-Power Wireless Personal Area Network protocol.
|
||||
- Multiple Address Support: A single network interface can be configured with multiple IPv6 addresses.
|
||||
|
|
@ -103,7 +137,7 @@ The openvela network protocol stack supports the TCP protocol on both IPv4 and I
|
|||
|
||||
### 3. UDP / ICMP / ICMPv6 Capabilities
|
||||
|
||||
In addition to the basic network communication capabilities, the OpenVela network stack also provides a series of advanced features for multi-core architectures, complex routing scenarios, and high-performance network requirements. The following is a detailed introduction to the advanced capabilities.
|
||||
In addition to the basic network communication capabilities, the openvela network stack also provides a series of advanced features for multi-core architectures, complex routing scenarios, and high-performance network requirements. The following is a detailed introduction to the advanced capabilities.
|
||||
|
||||
#### UDP Capabilities
|
||||
|
||||
|
|
|
|||
|
After Width: | Height: | Size: 1.5 MiB |
|
After Width: | Height: | Size: 1.2 MiB |
|
After Width: | Height: | Size: 1.3 MiB |
|
After Width: | Height: | Size: 420 KiB |
|
After Width: | Height: | Size: 207 KiB |
|
After Width: | Height: | Size: 1.6 MiB |
|
After Width: | Height: | Size: 344 KiB |
|
After Width: | Height: | Size: 166 KiB |
|
After Width: | Height: | Size: 876 KiB |
|
After Width: | Height: | Size: 130 KiB |
|
After Width: | Height: | Size: 21 KiB |
|
After Width: | Height: | Size: 1.1 MiB |
|
After Width: | Height: | Size: 429 KiB |
|
|
@ -0,0 +1,224 @@
|
|||
# SIL SocketCAN Functional Testing Guide
|
||||
|
||||
[ English | [简体中文](../../../../../zh-cn/device_dev_guide/connection/network/socketcan/sil_socketcan_test.md) ]
|
||||
|
||||
## I. Overview
|
||||
|
||||
This guide aims to demonstrate how to perform SocketCAN functional testing using openvela in a Software-in-the-Loop (SIL) environment.
|
||||
|
||||
Through this example, you will build and run the Vector SIL Kit toolchain, bridging the Linux host's virtual CAN interface (vcan) with the openvela simulation target to achieve CAN message transmission, reception, and loopback response testing.
|
||||
|
||||
## II. Test Architecture and Principles
|
||||
|
||||
Before executing specific operations, it is crucial to understand the relationships between components and the data flow.
|
||||
|
||||
### 1. Core Component Description
|
||||
|
||||
This test scenario involves four core components that together form a closed-loop test environment:
|
||||
|
||||
| **Component Name** | **Type** | **Functional Description** |
|
||||
| :------------------- | :-------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **openvela** | OS | The embedded operating system (System Under Test) running in the simulation environment, monitoring network traffic via the SocketCAN interface. |
|
||||
| **SIL Kit Registry** | Infrastructure | The "Command Tower" of the SIL Kit network, responsible for service discovery and coordinating connections between Participants. |
|
||||
| **SIL Kit Adapter** | Bridge | **The Connector**. One end connects to the Linux kernel vcan device `can0`, and the other connects to the virtual SIL Kit network, enabling message forwarding between two heterogeneous networks. |
|
||||
| **Echo Device** | Simulation Node | **The Test Node**. A virtual device running on the SIL Kit network used to simulate an external ECU. It automatically responds to received messages to verify if the communication link is functional. |
|
||||
|
||||
### 2. Architecture and Data Flow Diagram
|
||||
|
||||

|
||||
|
||||
**Data Flow Analysis:**
|
||||
|
||||
1. **Injection**: The script sends a raw message with ID `001` to the Linux `can0`.
|
||||
2. **Bridging**: The `SIL Kit Adapter` captures this message from `can0`, encapsulates it, and forwards it to the SIL Kit virtual bus.
|
||||
3. **Processing**: The `Echo Device` receives the message from the virtual bus and processes it (ID+1, data bit shift).
|
||||
4. **Response**: The `Echo Device` sends the processed message with ID `002` back to the virtual bus.
|
||||
5. **Write-back**: The `SIL Kit Adapter` receives the response message, unpacks it, and writes it to the Linux `can0`.
|
||||
6. **Verification**: Since `openvela` is constantly listening to `can0`, it captures both the original message (001) and the response message (002).
|
||||
|
||||
## III. Prerequisites
|
||||
|
||||
Before starting, please ensure your development host (Ubuntu) meets the following requirements.
|
||||
|
||||
### 1. Basic Environment Setup
|
||||
|
||||
Please refer to the official documentation [Quick Start (Ubuntu)](../quickstart/openvela_ubuntu_quick_start.md) to complete the setup of the openvela basic development environment and source code download.
|
||||
|
||||
### 2. SocketCAN Functional Verification
|
||||
|
||||
Please refer to the official documentation [SocketCAN Usage Guide](./socketcan_guide.md) to complete the execution of SocketCAN functions, ensuring you are familiar with enabling SocketCAN functionality in openvela.
|
||||
|
||||
## IV. Component Construction
|
||||
|
||||
This section will guide you through compiling the Vector SIL Kit and its adapter components.
|
||||
|
||||
### 1. Compiling the SIL Kit Core Library
|
||||
|
||||
Vector SIL Kit is an open-source library used to connect Software-in-the-Loop components.
|
||||
|
||||
> **Reference**: For an introduction to the SIL Kit, please visit: [GitHub - vectorgrp/sil-kit](https://github.com/vectorgrp/sil-kit)
|
||||
|
||||
Please execute the following commands in the `openvela` source root directory:
|
||||
|
||||
```Bash
|
||||
# 1. Enter the dependency directory
|
||||
cd ./external/vector-sil
|
||||
|
||||
# 2. Initialize and compile SIL Kit
|
||||
cd ./sil-kit
|
||||
git submodule update --init --recursive
|
||||
|
||||
# Configure CMake (disable documentation and tests to speed up compilation)
|
||||
cmake -S. -Bbuild -DSILKIT_BUILD_DOCS=OFF -DCMAKE_INSTALL_PREFIX=./install -DSILKIT_BUILD_TESTS=OFF
|
||||
|
||||
# Execute installation
|
||||
cmake --build build --target install -j16
|
||||
```
|
||||
|
||||
### 2. Compiling the SocketCAN Adapter
|
||||
|
||||
The adapter is used to bridge the SIL Kit network with the Linux SocketCAN device.
|
||||
|
||||
```Bash
|
||||
# 1. Enter the adapter directory
|
||||
cd ../sil-kit-adapters-vcan
|
||||
|
||||
# 2. Initialize and compile the adapter
|
||||
git submodule update --init --recursive
|
||||
|
||||
# Configure CMake (specify the SIL Kit installation path)
|
||||
cmake -S. -Bbuild -DSILKIT_PACKAGE_DIR=../sil-kit/install -DCMAKE_BUILD_TYPE=Debug
|
||||
|
||||
# Execute compilation
|
||||
cmake --build build --parallel
|
||||
```
|
||||
|
||||
## V. Executing the Test
|
||||
|
||||
This test requires opening **5 independent terminal windows** to run different components respectively. Please follow the order below.
|
||||
|
||||
### Step 1: Start the openvela Simulation Platform (Terminal 1)
|
||||
|
||||
Refer to the instructions in the "Prerequisites" section to start the openvela simulator.
|
||||
|
||||
1. After a successful startup, the terminal will display the NSH (NuttShell) interface as follows:
|
||||
|
||||

|
||||
|
||||
2. Execute the following command in NSH to start the CAN device:
|
||||
|
||||
```Bash
|
||||
ifup can0
|
||||
```
|
||||
|
||||
**Expected Output:**
|
||||
|
||||
`ifup can0...OK` indicates that the can0 device started successfully.
|
||||
|
||||
### Step 2: Start the SIL Kit Registry (Terminal 2)
|
||||
|
||||
Execute the following command in the `openvela/external/vector-sil/sil-kit/` directory:
|
||||
|
||||
```Bash
|
||||
./install/bin/sil-kit-registry --log debug --listen-uri 'silkit://0.0.0.0:8501'
|
||||
```
|
||||
|
||||
**Expected Output:**
|
||||
|
||||
Upon success, the service starts and listens on port 8501.
|
||||
|
||||

|
||||
|
||||
### Step 3: Start the vcan Adapter (Terminal 3)
|
||||
|
||||
This step bridges the SIL Kit virtual network `CAN1` with the Linux host's `can0` interface.
|
||||
|
||||
Execute the following command in the `openvela/external/vector-sil/sil-kit-adapters-vcan` directory:
|
||||
|
||||
```Bash
|
||||
./bin/sil-kit-adapter-vcan --name SilKitAdapterVcan1 --registry-uri silkit://localhost:8501 --can-name can0 --network CAN1 --log Debug
|
||||
```
|
||||
|
||||
**Expected Output**: The adapter successfully connects to the registry and begins bridging the `can0` and `CAN1` networks.
|
||||
|
||||

|
||||
|
||||
At this point, **Terminal 2 (Registry)** will also refresh its log, showing that a new connection has been detected:
|
||||
|
||||

|
||||
|
||||
### Step 4: Start the Echo Demo Device (Terminal 4)
|
||||
|
||||
Create a `CanEchoDevice` connected to the SIL Kit CAN1 network. The `CanEchoDevice` responds to received data (CAN ID increments by one, data shifts left by one byte) and sends the response to the SIL Kit CAN1 network.
|
||||
|
||||
Execute the following command in the `openvela/external/vector-sil/sil-kit-adapters-vcan` directory:
|
||||
|
||||
```Bash
|
||||
./bin/sil-kit-demo-can-echo-device
|
||||
```
|
||||
|
||||
**Expected Output:**
|
||||
|
||||

|
||||
|
||||
**Terminal 2 (Registry)** will show that the Echo device is connected:
|
||||
|
||||

|
||||
|
||||
### Step 5: Monitor Data and Inject Traffic
|
||||
|
||||
1. Enable Monitoring (Terminal 1).
|
||||
|
||||
Return to the terminal running openvela and enable CAN data dump monitoring in NSH:
|
||||
|
||||
```Bash
|
||||
candump can0
|
||||
```
|
||||
|
||||
2. Inject Traffic (Terminal 5).
|
||||
|
||||
Run the script on the Linux host to send test messages to the `can0` interface.
|
||||
|
||||
Execute the following command in the `openvela/external/vector-sil/sil-kit-adapters-vcan` directory:
|
||||
|
||||
```Bash
|
||||
./SocketCAN/demos/shell_scripts/send_CAN_frames.sh can0
|
||||
```
|
||||
|
||||
This continuously generates CAN messages (CAN ID = 001, Data=AAAABBBB) and sends them to the vcan device CAN0.
|
||||
|
||||

|
||||
|
||||
## VI. Result Verification and Analysis
|
||||
|
||||
### 1. Data Flow Analysis
|
||||
|
||||
After the test starts, the data flow is as follows:
|
||||
|
||||
1. **Terminal 5** sends raw message (ID: 001) -> Linux `can0`.
|
||||
2. **Terminal 3** (Adapter) reads message from `can0` -> Forwards to SIL Kit network `CAN1`.
|
||||
3. **Terminal 4** (Echo Device) receives message -> Processes (ID+1, Shift Left) -> Sends response message (ID: 002) to `CAN1`.
|
||||
4. **Terminal 3** (Adapter) receives response from `CAN1` -> Writes to Linux `can0`.
|
||||
5. **Terminal 1** (openvela) reads both the raw message and the response message via `candump`.
|
||||
|
||||
### 2. Verification Results
|
||||
|
||||
**Terminal 1 (openvela NSH) Output:**
|
||||
|
||||
In Terminal 1, the complete traffic interaction is monitored:
|
||||
|
||||

|
||||
|
||||
**Terminal 3 (Adapter) Log:**
|
||||
|
||||
The adapter records the message conversion process in detail:
|
||||
|
||||

|
||||
|
||||
**Conclusion**:
|
||||
|
||||
- The CAN frame with CAN ID 001 is the data injected into the vcan device can0 by the script `send_CAN_frames.sh`.
|
||||
- The CAN frame with CAN ID 002 is the response to the message from `sil-kit-demo-can-echo-device`, where the CAN ID is incremented by 1 and the data is shifted left by 1 byte.
|
||||
- openvela successfully monitored the complete interaction process via the SocketCAN interface, completing a simple test of SocketCAN communication functionality in a SIL environment.
|
||||
|
||||
Furthermore, other test software such as CANoe can be connected to the SIL Kit as participants to complete more comprehensive testing of SocketCAN functionality.
|
||||
|
|
@ -0,0 +1,214 @@
|
|||
# SocketCAN User Guide
|
||||
|
||||
[ English | [简体中文](../../../../../zh-cn/device_dev_guide/connection/network/socketcan/socketcan_guide.md) ]
|
||||
|
||||
## I. Introduction to SocketCAN
|
||||
|
||||
**SocketCAN** is an open-source driver and network stack developed for the CAN (Controller Area Network) protocol within the Linux kernel. Unlike traditional character device drivers, SocketCAN utilizes the Berkeley Socket API network programming interface, abstracting the CAN bus as a network interface (e.g., `can0`). This makes CAN protocol development highly similar to Ethernet programming.
|
||||
|
||||
Introducing SocketCAN support in the openvela operating system offers the following significant advantages:
|
||||
|
||||
- **Standardized Interfaces**: The application layer can access the CAN bus via standard `socket`, `bind`, `write`, and `read` system calls.
|
||||
- **Multiplexing**: Supports multiple applications accessing the same CAN interface simultaneously without the need to handle complex concurrency locks.
|
||||
- **Tool Ecosystem**: Natively compatible with powerful standard Linux debugging tools such as `can-utils` (e.g., `candump`, `cansend`).
|
||||
|
||||
This guide will lead you through configuring and using this powerful functionality within the openvela SIL (Software-in-the-Loop) simulation environment.
|
||||
|
||||
## II. Overview
|
||||
|
||||
This experiment aims to establish a virtual CAN network between a Linux host and an openvela instance using the QEMU emulator to verify the feasibility of bidirectional data communication.
|
||||
|
||||
**Upon completing this experiment, you will achieve the following objectives:**
|
||||
|
||||
1. Successfully build and launch the openvela system with the SocketCAN protocol stack supported.
|
||||
2. Master the methods for exchanging CAN data frames between the host and openvela.
|
||||
|
||||
## III. Prerequisites
|
||||
|
||||
Please complete the following software installation and source code preparation on the development host (Ubuntu environment).
|
||||
|
||||
### 1. Build Basic Development Environment
|
||||
|
||||
Please first refer to the official documentation [Quick Start (Ubuntu)](../quickstart/openvela_ubuntu_quick_start.md) to complete the setup of the openvela compilation environment and the downloading of source code.
|
||||
|
||||
### 2. Install CAN Debugging Tools
|
||||
|
||||
Execute the following command in the host terminal to install the `can-utils` toolkit, which is used for CAN data debugging on the Linux side:
|
||||
|
||||
```bash
|
||||
sudo apt-get install can-utils
|
||||
```
|
||||
|
||||
## IV. System Configuration and Build
|
||||
|
||||
This chapter takes the `openvela sil` platform as an example to guide you on enabling core SocketCAN functionality.
|
||||
|
||||
### 1. Configure Function Options (Menuconfig)
|
||||
|
||||
Execute the following command to enter the configuration interface for `core0`:
|
||||
|
||||
```bash
|
||||
./build.sh vendor/openvela/boards/sil/configs/ksil_arm32r_nsh_core0 --cmake menuconfig
|
||||
```
|
||||
|
||||
Please locate and enable the following key configuration items in the configuration menu (or confirm that the `.config` file contains the following):
|
||||
|
||||
```Makefile
|
||||
# CAN Controller Support
|
||||
CONFIG_CAN_CTUCANFD=y
|
||||
CONFIG_CAN_CTUCANFD_SOCKET=y
|
||||
|
||||
# PCI & Bus Support
|
||||
CONFIG_PCI=y
|
||||
CONFIG_PCI_MSIX=y
|
||||
|
||||
# Networking Support
|
||||
CONFIG_NET=y
|
||||
CONFIG_NET_CAN=y
|
||||
CONFIG_NET_SOCKOPTS=y
|
||||
CONFIG_NETDEV_LATEINIT=y
|
||||
CONFIG_NETDEV_IFINDEX=y
|
||||
|
||||
# BSD Compatibility
|
||||
CONFIG_ALLOW_BSD_COMPONENTS=y
|
||||
|
||||
# CAN Utilities (NuttX side)
|
||||
CONFIG_CANUTILS_LIBCANUTILS=y
|
||||
CONFIG_CANUTILS_CANSEND=y
|
||||
CONFIG_CANUTILS_CANDUMP=y
|
||||
|
||||
# Disable unrelated CAN drivers to avoid conflicts
|
||||
CONFIG_CAN=n
|
||||
CONFIG_CAN_KVASER=n
|
||||
```
|
||||
|
||||
### 2. Compile Project
|
||||
|
||||
Use `protect` mode to build the Bootloader (BL) and the Core System (Core0) separately.
|
||||
|
||||
#### Step 1: Execute Compilation Commands
|
||||
|
||||
```Bash
|
||||
# Build BL
|
||||
./build.sh vendor/openvela/boards/sil/configs/ksil_arm32r_nsh_bl --cmake -j8
|
||||
|
||||
# Build Core0
|
||||
./build.sh vendor/openvela/boards/sil/configs/ksil_arm32r_nsh_core0 --cmake -j8
|
||||
```
|
||||
|
||||
#### Step 2: Deploy Build Artifacts
|
||||
|
||||
Create the release directory and move the ELF image files:
|
||||
|
||||
```Bash
|
||||
mkdir ./cmake_out/cur-release/
|
||||
|
||||
# Copy build artifacts
|
||||
cp ./cmake_out/sil_ksil_arm32r_nsh_core0/vela_core0.elf ./cmake_out/cur-release/ &&
|
||||
cp ./cmake_out/sil_ksil_arm32r_nsh_core0/vela_core0_user.elf ./cmake_out/cur-release/
|
||||
```
|
||||
|
||||
## V. Running the Simulation Environment
|
||||
|
||||
### 1. Create Virtual CAN Network
|
||||
|
||||
Execute the following commands in the **Host (Ubuntu) terminal** to load the `vcan` module and create virtual CAN nodes.
|
||||
|
||||
**Note**: This step requires `sudo` privileges.
|
||||
|
||||
```Bash
|
||||
cp -r ./vendor/openvela/boards/sil/tools ./cmake_out/cur-release
|
||||
|
||||
# Creation of virtual CAN nodes, creating 10 vcan nodes
|
||||
sudo modprobe vcan; \
|
||||
for i in {0..9}; do \
|
||||
sudo ip link add dev can$i type vcan; \
|
||||
sudo ip link set up can$i; \
|
||||
done
|
||||
# After adding, you can execute ifconfig to check if these interfaces exist and are running
|
||||
```
|
||||
|
||||
### 2. Start openvela Simulation
|
||||
|
||||
Execute the startup script to run the QEMU environment:
|
||||
|
||||
```Bash
|
||||
./cmake_out/cur-release/tools/run_arm32r_qemu_ctu_canfd.sh 10 3 protect 1
|
||||
```
|
||||
|
||||
**Parameter Explanation**:
|
||||
|
||||
- `10`: The number of mapped CAN devices (must match the number of vcan nodes created in the previous step).
|
||||
- `3`: The number of serial devices.
|
||||
- `protect`: The boot mode.
|
||||
- `1`: The number of startup cores.
|
||||
|
||||
After the system starts successfully, the terminal will display the `core0>` prompt:
|
||||
|
||||

|
||||
|
||||
## VI. Functionality Verification Experiment
|
||||
|
||||
This section verifies bidirectional communication between the host and openvela.
|
||||
|
||||
### Scenario 1: openvela Receives CAN Data
|
||||
|
||||
#### Step 1: Target Setup (openvela)
|
||||
|
||||
Start the CAN interface and listen for data in the `openvela` NSH terminal:
|
||||
|
||||
```Bash
|
||||
ifup can0
|
||||
candump can0
|
||||
```
|
||||
|
||||
#### Step 2: Host Send (Ubuntu)
|
||||
|
||||
Open a new Ubuntu terminal window and send test data to `can0`:
|
||||
|
||||
```Bash
|
||||
# Send standard frame (ID: 123, Data: 12 34 56 78)
|
||||
cansend can0 123#12345678
|
||||
|
||||
# Send standard frame (ID: 123, Data: deadbeef)
|
||||
cansend can0 123#deadbeef
|
||||
|
||||
# Send remote request frame (RTR)
|
||||
cansend can0 123#R
|
||||
```
|
||||
|
||||
#### Step 3: Verify Results
|
||||
|
||||
Observe the openvela terminal; it should display the received data frames:
|
||||
|
||||

|
||||
|
||||
### Scenario 2: openvela Sends CAN Data
|
||||
|
||||
#### Step 1: Host Listen (Ubuntu)
|
||||
|
||||
Execute the listening command in the Ubuntu terminal:
|
||||
|
||||
```bash
|
||||
candump can0
|
||||
```
|
||||
|
||||
#### Step 2: Target Send (openvela)
|
||||
|
||||
Execute the send command in the openvela NSH terminal:
|
||||
|
||||
```Bash
|
||||
# Ensure the interface is up
|
||||
ifup can0
|
||||
|
||||
# Send test data
|
||||
cansend can0 123#12345678
|
||||
cansend can0 123#deadbeef
|
||||
cansend can0 123#R
|
||||
```
|
||||
|
||||
#### Step 3: Verify Results
|
||||
|
||||
Observe the Ubuntu terminal; it should receive the data frames from openvela:
|
||||
|
||||

|
||||
|
After Width: | Height: | Size: 31 KiB |
|
After Width: | Height: | Size: 40 KiB |
|
|
@ -0,0 +1,251 @@
|
|||
# RIL Adaptation Guide
|
||||
|
||||
\[ English | [Chinese (Simplified)](../../../../zh-cn/device_dev_guide/connection/telephony/ril_adaptation_guide.md) \]
|
||||
|
||||
This guide details the architecture of the openvela Radio Interface Layer (RIL) and provides Modem vendors with a complete workflow and technical requirements for adapting and integrating their `vendor-ril` into the openvela system.
|
||||
|
||||
## I. Overview
|
||||
|
||||
The openvela Radio Interface Layer (RIL) is a comprehensive Telephony solution heavily inspired by the Android RIL architecture. It was initially developed for the openvela QEMU emulator and has since been extended to physical hardware products.
|
||||
|
||||
This section introduces the core architecture of openvela RIL, the responsibilities of its components, and the collaboration model for vendor adaptation.
|
||||
|
||||
### 1. RIL Architecture and Components
|
||||
|
||||
The openvela RIL architecture consists of three core components that work together to connect the upper-level Telephony framework with the underlying Modem hardware.
|
||||
|
||||
- **`libril`**: An interface library that receives socket requests from the upper-level Telephony framework (oFono) and forwards them to the `rild` daemon. Its implementation is based on Android 7.0.
|
||||
- **`rild`**: The core daemon that acts as a bridge between `libril` and `vendor-ril`. It manages the communication link between them and dispatches requests to `vendor-ril` for processing.
|
||||
- **`vendor-ril`**: The vendor-specific implementation that directly interacts with the underlying Modem hardware or QEMU emulator (`modem_simulator`) to perform concrete communication operations. The reference implementation (`reference-ril`) provided by openvela is primarily based on Android 13 code.
|
||||
|
||||
<img src="./figures/004.png" width="75%" height="100%">
|
||||
|
||||
### 2. Collaboration Model and Adaptation Strategy
|
||||
|
||||
To simplify the adaptation effort across different hardware platforms, openvela RIL adopts a strategy that separates standardization from customization, clearly defining the division of responsibilities between openvela and Modem chip vendors.
|
||||
|
||||
- **Common Components (Maintained by openvela)**: openvela is responsible for maintaining and providing the common `libril` library and `rild` daemon. These components remain consistent across all products running openvela and should not be modified by vendors.
|
||||
- **Custom Module (`vendor-ril`) (Developed by Modem Vendors)**: Modem chip vendors only need to focus on developing and implementing the `vendor-ril` that is compatible with their hardware. This part of the code handles the specific chip's hardware interfaces, AT command set, communication protocols, and control logic.
|
||||
|
||||
This collaboration model, by standardizing common components and isolating custom modules, aims to significantly reduce the adaptation costs for Modem vendors and accelerate the integration of their products into the openvela ecosystem.
|
||||
|
||||
## II. Codebase Structure
|
||||
|
||||
### 1. Code Directory Introduction
|
||||
|
||||
The source code for openvela RIL is located in the `external/ril` repository, with its core code residing in the `external/ril/ril` subdirectory.
|
||||
|
||||
#### Codebase Path
|
||||
|
||||
```Bash
|
||||
vela_source_code/external/ril
|
||||
```
|
||||
|
||||
The top-level `external/ril` directory primarily contains the project's top-level build configuration files, while the actual core source code is located in the `external/ril/ril` subdirectory.
|
||||
|
||||
#### Core Directory Structure
|
||||
|
||||
```Bash
|
||||
.
|
||||
├── include # Public RIL headers defining core data structures and interfaces
|
||||
├── libril # Common libril library implementation for communicating with the upper-level framework
|
||||
├── librilutils # Common RIL utility function library
|
||||
├── reference-ril # Reference implementation for the QEMU emulator (should not be modified by vendors)
|
||||
└── rild # Main program entry point for the RIL daemon (rild)
|
||||
```
|
||||
|
||||
### 2. Role and Modular Design of `reference-ril`
|
||||
|
||||
The `reference-ril` directory provides an AT command-based RIL reference implementation. Its **sole purpose is to serve as an example** to demonstrate the basic structure of a `vendor-ril`, its interface specifications, and its interaction logic with `rild`. In the current codebase, this implementation is tailored for the QEMU emulator (`modem_simulator`) environment.
|
||||
|
||||
> **Note:**
|
||||
>
|
||||
> `reference-ril` is **not** intended to be the location for a vendor's final product code.
|
||||
|
||||
To improve code readability and maintainability, `reference-ril` is split into functional modules, which primarily include:
|
||||
|
||||
- `at_call.c`: Handles AT commands related to Calls.
|
||||
- `at_data.c`: Handles AT commands related to Data services.
|
||||
- `at_modem.c`: Handles AT commands related to Modem control.
|
||||
- `at_network.c`: Handles AT commands related to the Network.
|
||||
- `at_sim.c`: Handles AT commands related to the SIM card.
|
||||
- `at_sms.c`: Handles AT commands related to SMS.
|
||||
- `at_ril.c`: Handles RIL request dispatching and main logic.
|
||||
- `atchannel.c`: Manages the AT command sending and receiving channel.
|
||||
|
||||
This modular design uses dispatch functions like `on_request_*` and `try_handle_unsol_*` to route RIL requests and unsolicited responses to the appropriate module files for processing.
|
||||
|
||||
> **Development Recommendation:**
|
||||
>
|
||||
> When developing their own `vendor-ril`, Modem vendors should follow this modular structure. This ensures that the code logic is clear and responsibilities are well-defined, greatly facilitating subsequent development, debugging, and long-term maintenance.
|
||||
|
||||
## III. Vendor RIL Adaptation Workflow
|
||||
|
||||
The core of the adaptation work is to correctly integrate the vendor-specific `vendor-ril` into the openvela build system. Please follow these steps strictly.
|
||||
|
||||
### Step 1: Create a Directory
|
||||
|
||||
> **Note:**
|
||||
>
|
||||
> **Do not** modify, delete, or replace any content within the `external/ril/ril/reference-ril` directory in any way.
|
||||
|
||||
It is recommended that you create a new `vendor-ril` directory under your chip-specific `vendor` directory to store your custom RIL code.
|
||||
|
||||
#### Example Directory Path
|
||||
|
||||
```Bash
|
||||
vendor/<vendor_name>/<chip_platform_name>/<vendor-ril>/
|
||||
```
|
||||
|
||||
### Step 2: Deploy Code and Build Scripts
|
||||
|
||||
Copy all your developed `vendor-ril` source files into the directory created in the previous step. At the same time, add the corresponding build system configuration files (e.g., Kconfig or `CMakeLists.txt`) in this directory to ensure the build system can correctly compile and link your code.
|
||||
|
||||
#### Example Directory Files
|
||||
|
||||
```CMake
|
||||
$ tree sample_vendor_ril/
|
||||
sample_vendor_ril/
|
||||
├── CMakeLists.txt
|
||||
├── Kconfig
|
||||
└── sample_vendor_ril
|
||||
├── at_call.c
|
||||
├── at_call.h
|
||||
├── atchannel.c
|
||||
├── atchannel.h
|
||||
├── at_data.c
|
||||
├── at_data.h
|
||||
├── at_modem.c
|
||||
├── at_modem.h
|
||||
├── at_network.c
|
||||
├── at_network.h
|
||||
├── at_ril.c
|
||||
├── at_ril.h
|
||||
├── at_sim.c
|
||||
├── at_sim.h
|
||||
├── at_sms.c
|
||||
├── at_sms.h
|
||||
├── at_tok.c
|
||||
├── at_tok.h
|
||||
├── misc.c
|
||||
├── misc.h
|
||||
├── MODULE_LICENSE_APACHE2
|
||||
└── NOTICE
|
||||
|
||||
1 directory, 24 files
|
||||
```
|
||||
|
||||
### Step 3: Integrate into the openvela Build System
|
||||
|
||||
You need to integrate your `vendor-ril` into the system build process using `Kconfig` and `CMakeLists.txt`. The build system will automatically compile and link the common `libril` and `rild` with your `vendor-ril`, ultimately generating an `rild` daemon adapted for the target hardware.
|
||||
|
||||
#### 3.1 Disable the Simulator RIL
|
||||
|
||||
First, **disable** the default QEMU simulator RIL (`CONFIG_GOLDFISH_RIL`) through the Kconfig configuration system.
|
||||
|
||||
#### 3.2 Add a Kconfig Option
|
||||
|
||||
At the top level of your `vendor` directory, create a `Kconfig` file to add an enable option for your RIL.
|
||||
|
||||
**Kconfig Example (`vendor/<vendor>/<platform>/Kconfig`):**
|
||||
|
||||
```Makefile
|
||||
#
|
||||
# For a description of the syntax of this configuration file,
|
||||
# see the file kconfig-language.txt in the NuttX tools repository.
|
||||
#
|
||||
|
||||
config SAMPLE_VENDOR_RIL
|
||||
tristate "Enable SAMPLE_VENDOR_RIL"
|
||||
default n
|
||||
depends on RILD
|
||||
---help---
|
||||
Enable sample vendor ril
|
||||
```
|
||||
|
||||
#### 3.3 Create a `CMakeLists.txt` for `vendor-ril`
|
||||
|
||||
In your `vendor-ril` directory (`vendor/<vendor>/<platform>/vendor-ril/`), create a `CMakeLists.txt` file to describe how to compile your source code. This `CMakeLists.txt` only needs to focus on the source files of the `vendor-ril` itself.
|
||||
|
||||
**CMakeLists.txt Example (`vendor/<xxx>/<platform>/<sample_vendor_ril>/CMakeLists.txt`):**
|
||||
|
||||
```CMake
|
||||
#
|
||||
# Copyright (C) 2021 Xiaomi Corporation
|
||||
#
|
||||
# Licensed under the Apache License, Version 2.0 (the "License"); you may not
|
||||
# use this file except in compliance with the License. You may obtain a copy of
|
||||
# the License at
|
||||
#
|
||||
# http://www.apache.org/licenses/LICENSE-2.0
|
||||
#
|
||||
# Unless required by applicable law or agreed to in writing, software
|
||||
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
||||
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
|
||||
# License for the specific language governing permissions and limitations under
|
||||
# the License.
|
||||
#
|
||||
|
||||
if(CONFIG_SAMPLE_VENDOR_RIL)
|
||||
set(SAMPLE_VENDOR_RIL_DIR ${CMAKE_CURRENT_LIST_DIR}/sample_vendor_ril)
|
||||
file(GLOB CSRCS ${SAMPLE_VENDOR_RIL_DIR}/*.c)
|
||||
set(INCDIR ${SAMPLE_VENDOR_RIL_DIR})
|
||||
set(CFLAGS -Wno-format)
|
||||
|
||||
nuttx_add_library(sample_vendor_ril STATIC)
|
||||
|
||||
target_compile_options(sample_vendor_ril PRIVATE ${CFLAGS})
|
||||
target_sources(sample_vendor_ril PRIVATE ${CSRCS})
|
||||
target_include_directories(sample_vendor_ril PRIVATE ${INCDIR})
|
||||
|
||||
endif()
|
||||
```
|
||||
|
||||
## IV. Development Guidelines and Recommendations
|
||||
|
||||
### 1. Key Considerations
|
||||
|
||||
- **Differences Between Simulator and Physical Hardware**: `reference-ril` is designed for a limited QEMU emulator environment. When porting to physical hardware, you must account for more complex real-world scenarios, such as more comprehensive error handling, dynamic changes in signal strength, and network switching logic.
|
||||
- **Remove Simulator-Specific Code**: `reference-ril` contains some code specific to the emulator (e.g., the `ENABLE_MODEM` macro). You must identify and remove this code when adapting it to your hardware.
|
||||
- **Robust State Management**: To simplify its implementation, `reference-ril` uses some global variables to maintain state. In a production product, this practice can lead to race conditions and system instability. We strongly recommend that you adopt a more robust state management mechanism (e.g., a context-based struct) in your `vendor-ril`.
|
||||
|
||||
### 2. Development Recommendations
|
||||
|
||||
- **Limit a-Scope of Modifications**: Please strictly confine your code modifications to your own `vendor-ril` directory. `libril` and `rild` are common components shared across platforms. If you must modify common code, please create a patch and submit it to the developers for review and merging.
|
||||
- **Implement Hardware-Specific Functions**: Some functions in `reference-ril` are simulated for the emulator (e.g., `enable modem`). You need to implement the complete logic for these functions in your `vendor-ril` based on the behavior of your actual hardware.
|
||||
- **Adapt the Device Node**: The device node opened by `reference-ril` is `/dev/ttyV0`, which is a virtual serial port provided by the Goldfish emulator. You must change this to the actual device node for your Modem hardware in the system (e.g., `/dev/ttyS1` or `/dev/ttyUSB0`).
|
||||
|
||||
## V. Interface Requirements
|
||||
|
||||
Your `vendor-ril` implementation must adhere to the openvela Telephony interface specifications.
|
||||
|
||||
- **Request Categories**: RIL requests are divided into **mandatory** and **optional** categories. Your implementation **must** support all mandatory requests and is **recommended** to support optional requests.
|
||||
- **Documentation-First Principle**: If there is a discrepancy between the `reference-ril` implementation and the interface documentation, **always follow the interface documentation**.
|
||||
|
||||
- For example, the `requestSetPreferredNetworkType` function in `reference-ril`'s `at_network.c` might follow the native Android implementation instead of adhering to the `RIL_PreferredNetworkType` enum required by the documentation. In such cases, you should refer to the documentation for correct development.
|
||||
|
||||
## VI. RIL Adaptation Acceptance Testing
|
||||
|
||||
After completing the `vendor-ril` adaptation, you can use the `RILTEST` tool to perform acceptance testing and verify the correctness of your implementation.
|
||||
|
||||
### 1. Test Steps
|
||||
|
||||
1. **Disable oFono**: The `RILTEST` tool conflicts with the `oFono` service and they cannot run simultaneously. Please **disable** the `CONFIG_OFONO` option in Kconfig.
|
||||
|
||||
2. **Enable RILTEST**: **Enable** the `CONFIG_RIL_TEST` option in Kconfig.
|
||||
|
||||
3. **Rebuild the System**: Perform a full build process to generate the firmware containing `RILTEST` and flash it to the device.
|
||||
|
||||
4. **Push the Test Script**: Push the [run_testcase.sh](./run_testcase.sh) script to the device's data partition via `adb`.
|
||||
|
||||
```bash
|
||||
adb push run_testcase.sh /data/
|
||||
```
|
||||
|
||||
5. **Run the Test**: Log in to the device via `adb shell` and run the test script.
|
||||
|
||||
```bash
|
||||
adb shell "sh /data/run_testcase.sh"
|
||||
```
|
||||
|
||||
The test tool will automatically execute a series of RIL commands and verify the Modem's responses, helping you to quickly locate and fix issues in your implementation.
|
||||
|
|
@ -0,0 +1,52 @@
|
|||
#!/bin/sh
|
||||
rilreq_tool 0 0
|
||||
rilreq_tool 0 1
|
||||
rilreq_tool 0 0
|
||||
rilreq_tool 0 8
|
||||
rilreq_tool 0 9
|
||||
rilreq_tool 0 8
|
||||
rilreq_tool 0 2
|
||||
rilreq_tool 0 3
|
||||
rilreq_tool 0 4
|
||||
rilreq_tool 0 5
|
||||
rilreq_tool 0 6
|
||||
rilreq_tool 0 7
|
||||
rilreq_tool 0 10
|
||||
rilreq_tool 0 11
|
||||
rilreq_tool 0 12
|
||||
rilreq_tool 0 13
|
||||
rilreq_tool 0 15
|
||||
rilreq_tool 0 12
|
||||
rilreq_tool 0 16
|
||||
rilreq_tool 0 17
|
||||
rilreq_tool 0 18
|
||||
rilreq_tool 0 19
|
||||
rilreq_tool 0 20
|
||||
rilreq_tool 0 21
|
||||
rilreq_tool 0 22
|
||||
rilreq_tool 0 23
|
||||
rilreq_tool 0 22
|
||||
rilreq_tool 0 24
|
||||
rilreq_tool 0 25
|
||||
rilreq_tool 0 26
|
||||
rilreq_tool 0 27
|
||||
rilreq_tool 0 28
|
||||
rilreq_tool 0 29
|
||||
rilreq_tool 0 30
|
||||
rilreq_tool 0 29
|
||||
rilreq_tool 0 31
|
||||
rilreq_tool 0 32
|
||||
rilreq_tool 0 33
|
||||
rilreq_tool 0 34
|
||||
rilreq_tool 0 35
|
||||
rilreq_tool 0 36
|
||||
rilreq_tool 0 40
|
||||
rilreq_tool 0 37
|
||||
rilreq_tool 0 38
|
||||
rilreq_tool 0 39
|
||||
rilreq_tool 0 41
|
||||
rilreq_tool 0 42
|
||||
rilreq_tool 0 43
|
||||
rilreq_tool 0 44
|
||||
rilreq_tool 0 45
|
||||
rilreq_tool 0 1
|
||||
|
|
@ -0,0 +1,589 @@
|
|||
# Telephony API Developer Guide
|
||||
|
||||
\[ English | [简体中文](../../../../zh-cn/device_dev_guide/connection/telephony/tapi_developer_guide.md) \]
|
||||
|
||||
This document provides a detailed guide for application developers on using the Telephony Application Programming Interface (TAPI) on the openvela operating system.
|
||||
|
||||
## I. Overview
|
||||
|
||||
Telephony is the framework and API collection within the openvela operating system for handling communication functions. `Framework/telephony` is the interface layer that openvela provides to the application layer, also known as TAPI (Telephony API). TAPI offers a rich set of tools and interfaces designed so that application developers can easily obtain Telephony-related information and build applications by simply calling APIs, without needing to understand the internal business logic of the Telephony service (which is implemented by oFono). Additionally, Telephony supports flexible extension and customization to meet evolving communication needs.
|
||||
|
||||
### 1. Core Functional Modules
|
||||
|
||||
The series of APIs provided by Telephony includes:
|
||||
|
||||
- **Common Management (Common)**: Provides the master control interface for the Telephony service, responsible for initializing and managing communication functions. This is a prerequisite for using all other Telephony services.
|
||||
- **Call Management (Call)**: Enables applications to implement call functions such as dialing, answering, hanging up, holding, displaying caller information, and switching between multiple calls.
|
||||
- **Supplementary Service (SS)**: Allows applications to implement supplementary services provided by carriers, such as call barring, call forwarding, and call waiting.
|
||||
- **Short Message Service (SMS)**: Enables applications to send and receive SMS messages, as well as manage the Short Message Service Center (SMSC) address.
|
||||
- **Network**: Allows applications to query current registered network information, such as network service status and signal strength.
|
||||
- **Data**: Cellular data is a wireless communication technology standard that uses packet switching for both data transmission and exchange, providing mobile devices with voice, data, and multimedia services.
|
||||
- **SIM Card (SIM)**: Allows applications to retrieve SIM card status, operator name, Integrated Circuit Card Identifier (ICCID), and other information.
|
||||
- **IP Multimedia Subsystem (IMS)**: Provides applications with multimedia communication capabilities, including audio/video calls, instant messaging, and conference collaboration. By calling this API, developers can access IMS services, implement High-Definition Voice (VoLTE), manage network status, and configure IMS capabilities.
|
||||
|
||||
### 2. Debugging and Testing
|
||||
|
||||
Telephony also provides a command-line debugging tool and a unit testing solution:
|
||||
|
||||
- **Telephony Command-Line Tool**: A tool specifically designed for developing and debugging Telephony-related functions. It wraps TAPI interfaces into commands, allowing users to perform operations like dialing, answering, hanging up, and sending SMS messages via the `telephonytool` command. For details, refer to the [Telephonytool Command](./telephonytool/telephonytool_cmd_desc.md).
|
||||
- **Telephony Unit Testing Solution**: A highly reliable test suite built on the CMocka testing framework. It verifies the functionality, performance, and stability of the core Telephony code by simulating real-world scenarios such as SIM card states, network signaling, and abnormal signals, covering the entire communication link from physical layer interaction to protocol stack processing.
|
||||
|
||||
## II. How It Works
|
||||
|
||||
TAPI operates on an asynchronous, event-driven model, communicating with the underlying system Telephony service via D-Bus. Its workflow follows a standard **Initialize -> Invoke -> Release** lifecycle.
|
||||
|
||||
1. **Initialization**: The application calls `tapi_open()` to initialize the TAPI client, establishing a connection with the system service and obtaining a context handle (`tapi_context`).
|
||||
2. **Invocation**: The application uses this handle to call the APIs of various functional modules. Most of these operations are asynchronous, with results delivered through registered callback functions.
|
||||
3. **Release**: When the application exits or no longer needs communication functions, it calls `tapi_close()` to release the handle and associated resources.
|
||||
|
||||

|
||||
|
||||
## III. Prerequisites
|
||||
|
||||
### 1. System Build Configuration
|
||||
|
||||
Before you begin development, you must enable the following options in your project's `Kconfig` file to compile the Telephony framework and its dependencies into the system.
|
||||
|
||||
```Makefile
|
||||
CONFIG_ALLOW_MIT_COMPONENTS=y
|
||||
# Enable D-Bus support, which TAPI relies on for inter-process communication
|
||||
CONFIG_LIB_DBUS=y
|
||||
# Enable the Telephony core framework
|
||||
CONFIG_TELEPHONY=y
|
||||
```
|
||||
|
||||
### 2. Include Header Files
|
||||
|
||||
Include the main TAPI header file in your C source files to import all API declarations and data types.
|
||||
|
||||
```C
|
||||
#include "tapi.h"
|
||||
```
|
||||
|
||||
## IV. Core Development Steps
|
||||
|
||||
This section details the standard procedure for application developers to integrate the TAPI service.
|
||||
|
||||
### Step 1: Initialize the TAPI Context
|
||||
|
||||
Before using any TAPI function, you must call `tapi_open()` to initialize the Telephony library and obtain a context handle. This handle is required for all subsequent TAPI calls.
|
||||
|
||||
#### Function Prototype
|
||||
|
||||
```C
|
||||
tapi_context tapi_open(const char* client_name,
|
||||
tapi_client_ready_function callback,
|
||||
void* user_data);
|
||||
```
|
||||
|
||||
#### Description
|
||||
|
||||
Initializes the TAPI client and establishes a D-Bus connection with the system's Telephony service. This is an asynchronous process. When the service is ready, the system will invoke the `callback` function you provide.
|
||||
|
||||
#### Parameters
|
||||
|
||||
| **Parameter** | **Type** | **Description** |
|
||||
| :------------ | :--------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `client_name` | `const char*` | A unique name for the client.<br>Must conform to D-Bus naming conventions (e.g., `com.yourcompany.yourapp`). |
|
||||
| `callback` | `tapi_client_ready_function` | The callback function to be invoked when the TAPI service is ready.<br>Defined as `typedef void (*tapi_client_ready_function)(const char* client_name, void* user_data);` |
|
||||
| `user_data` | `void*` | User-defined data to be passed to the `callback` function. |
|
||||
|
||||
#### Return Value
|
||||
|
||||
| **Return Value** | **Description** |
|
||||
| :--------------- | :-------------------------------------------------------------- |
|
||||
| `tapi_context` | On success, returns a non-`NULL` TAPI context handle `(void*)`. |
|
||||
| `NULL` | Initialization failed. |
|
||||
|
||||
#### Code Example
|
||||
|
||||
```C++
|
||||
#include "tapi.h"
|
||||
|
||||
// TAPI service-ready callback function
|
||||
static void on_tapi_client_ready(const char* client_name, void* user_data)
|
||||
{
|
||||
if (client_name != NULL) {
|
||||
info("tapi is ready for %s\n", client_name);
|
||||
}
|
||||
|
||||
// After this callback is invoked, you can safely call other TAPI service APIs
|
||||
}
|
||||
|
||||
// Initialize TAPI
|
||||
static bool init_tapi(void)
|
||||
{
|
||||
tapi_context t_context =
|
||||
tapi_open("telephone.tapi_test", on_tapi_client_ready, NULL);
|
||||
if (t_context == NULL) {
|
||||
return false;
|
||||
}
|
||||
|
||||
return true;
|
||||
}
|
||||
```
|
||||
|
||||
### Step 2: Call Telephony Module APIs
|
||||
|
||||
After successful initialization, you can use the obtained `tapi_context` handle to call the APIs of various functional modules. Most operations are asynchronous, with results returned through callback functions.
|
||||
|
||||
#### Asynchronous Operations and Callbacks
|
||||
|
||||
Most TAPI operations are executed asynchronously, and their results are returned via callback functions. The callback for every asynchronous API receives a pointer to a `tapi_async_result` struct, which carries the result of the operation.
|
||||
|
||||
```C++
|
||||
typedef struct {
|
||||
int msg_id; // Event ID passed by the caller, used to distinguish requests in the callback
|
||||
tapi_message_type msg_type; // Message type (currently unused)
|
||||
int status; // Operation result status: 0 for success, negative for failure
|
||||
int arg1; // Generic parameter 1 (e.g., slot_id)
|
||||
int arg2; // Generic parameter 2
|
||||
void* data; // Pointer to returned data (e.g., a call_id string)
|
||||
void* user_obj; // User-defined object (currently unused)
|
||||
} tapi_async_result;
|
||||
```
|
||||
|
||||
> **Note**: The specific meaning of the `arg1`, `arg2`, and `data` members depends on the API being called.
|
||||
|
||||
#### Example 1: Enable the Modem
|
||||
|
||||
The modem is the hardware foundation for all cellular services (calls, SMS, data) and must be enabled before use.
|
||||
|
||||
##### Function Prototype
|
||||
|
||||
```C
|
||||
int tapi_enable_modem(tapi_context context,
|
||||
int slot_id,
|
||||
int event_id,
|
||||
bool enable,
|
||||
tapi_async_function p_handle);
|
||||
```
|
||||
|
||||
##### Description
|
||||
|
||||
Asynchronously enables or disables the modem for the specified slot (`slot_id`).
|
||||
|
||||
##### Parameters
|
||||
|
||||
| **Parameter** | **Type** | **Description** |
|
||||
| :------------ | :-------------------- | :----------------------------------------------------------------------------------------------------- |
|
||||
| `context` | `tapi_context` | The context handle returned by `tapi_open()`. |
|
||||
| `slot_id` | `int` | The slot ID (usually 0). |
|
||||
| `event_id` | `int` | A user-defined event ID that will be returned in the callback. |
|
||||
| `enable` | `bool` | `true` to enable, `false` to disable. |
|
||||
| `p_handle` | `tapi_async_function` | A pointer to the callback function. The result is passed in the `status` field of `tapi_async_result`. |
|
||||
|
||||
##### Asynchronous Callback
|
||||
|
||||
In the `p_handle` function, the `tapi_async_result` struct members are interpreted as follows:
|
||||
|
||||
- `status`: The operation result. `0` indicates success.
|
||||
- `arg1`: The `slot_id` of the operation.
|
||||
|
||||
##### Code Example
|
||||
|
||||
You can optionally call `tapi_get_modem_status` to check the current modem status.
|
||||
|
||||
```C
|
||||
#define EVENT_MODEM_ENABLE_DONE 101
|
||||
|
||||
// Callback function for the modem enable/disable operation
|
||||
static void on_modem_enable_done(tapi_async_result* result)
|
||||
{
|
||||
if (result->msg_id == EVENT_MODEM_ENABLE_DONE) {
|
||||
if (result->status == 0) {
|
||||
printf("Enable modem on slot %d succeeded.\n", result->arg1);
|
||||
} else {
|
||||
printf("Enable modem on slot %d failed.\n", result->arg1);
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Call the API to enable the modem
|
||||
int enable_modem(void)
|
||||
{
|
||||
if (g_tapi_context == NULL) {
|
||||
return -1;
|
||||
}
|
||||
// Enable the modem on slot 0
|
||||
return tapi_enable_modem(g_tapi_context, 0, EVENT_MODEM_ENABLE_DONE, true, on_modem_enable_done);
|
||||
}
|
||||
```
|
||||
|
||||
#### Example 2: Dial a Call
|
||||
|
||||
Dialing a call is a core function of the Call Management module.
|
||||
|
||||
##### Function Prototype
|
||||
|
||||
```C
|
||||
int tapi_call_dial(tapi_context context,
|
||||
int slot_id,
|
||||
const char* number,
|
||||
int hide_callerid,
|
||||
int event_id,
|
||||
tapi_async_function p_handle);
|
||||
```
|
||||
|
||||
##### Description
|
||||
|
||||
Initiates a phone call using the specified slot.
|
||||
|
||||
##### Parameters
|
||||
|
||||
| **Parameter** | **Type** | **Description** |
|
||||
| :-------------- | :-------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `context` | `tapi_context` | The context handle. |
|
||||
| `slot_id` | `int` | The slot ID. |
|
||||
| `number` | `const char*` | The phone number to dial. |
|
||||
| `hide_callerid` | `int` | Sets the Calling Line Identification Restriction (CLIR).<br>`0`: Default (uses the subscription's default setting)<br>`1`: Enabled (restricts CLI presentation, i.e., hides the number)<br>`2`: Disabled (allows CLI presentation, i.e., shows the number) |
|
||||
| `event_id` | `int` | A user-defined event ID. |
|
||||
| `p_handle` | `tapi_async_function` | The callback function to receive the operation result. |
|
||||
|
||||
---
|
||||
|
||||
| **Call Status** | **Description** |
|
||||
| :----------------------------- | :----------------------------------------- |
|
||||
| `CALL_STATUS_UNKNOW = -1` | Unknown or abnormal state |
|
||||
| `CALL_STATUS_ACTIVE = 0` | Active (in a call) |
|
||||
| `CALL_STATUS_HELD = 1` | Call is on hold |
|
||||
| `CALL_STATUS_DIALING = 2` | Dialing |
|
||||
| `CALL_STATUS_ALERTING = 3` | Remote party is ringing |
|
||||
| `CALL_STATUS_INCOMING = 4` | Incoming call with no other active calls |
|
||||
| `CALL_STATUS_WAITING = 5` | Incoming call while another call is active |
|
||||
| `CALL_STATUS_DISCONNECTED = 6` | Call is disconnected |
|
||||
|
||||
##### Asynchronous Callback
|
||||
|
||||
In the `p_handle` function, the `tapi_async_result` struct members are interpreted as follows:
|
||||
|
||||
- `status`: The operation result. `0` indicates success.
|
||||
- `arg1`: The `slot_id` of the operation.
|
||||
- `data`: A `(char*)` pointer to the unique call identifier (`call_id`), such as `/ril_0/voicecall01`.
|
||||
|
||||
**Note**: This `call_id` is required for subsequent operations on this call, like hanging up.
|
||||
|
||||
##### Code Example
|
||||
|
||||
Call the `tapi_call_dial` API to make a call. The `call_id` is obtained in the callback and can be used for subsequent call operations.
|
||||
|
||||
```C
|
||||
#define EVENT_REQUEST_DIAL_DONE 1
|
||||
|
||||
// Buffer to store the call ID
|
||||
static char g_call_id[64] = {0};
|
||||
|
||||
// Callback function for the dial operation
|
||||
static void on_dial_done(tapi_async_result* result)
|
||||
{
|
||||
if (result->msg_id == EVENT_REQUEST_DIAL_DONE) {
|
||||
if (result->status == 0 && result->data != NULL) {
|
||||
printf("Dialing succeeded. Call ID: %s\n", (char*)result->data);
|
||||
// Save the call_id for subsequent operations (e.g., hanging up)
|
||||
strncpy(g_call_id, (char*)result->data, sizeof(g_call_id) - 1);
|
||||
} else {
|
||||
printf("Dialing failed.\n");
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Call the API to start a call
|
||||
int start_call(const char* phone_number)
|
||||
{
|
||||
if (g_tapi_context == NULL || phone_number == NULL) {
|
||||
return -1;
|
||||
}
|
||||
return tapi_call_dial(g_tapi_context, 0, phone_number, 0,
|
||||
EVENT_REQUEST_DIAL_DONE, on_dial_done);
|
||||
}
|
||||
|
||||
// Example usage
|
||||
// start_call("10010");
|
||||
```
|
||||
|
||||
#### Example 3: Set Call Waiting
|
||||
|
||||
Call Waiting allows a user to be notified of a new incoming call while already in an active call and provides the option to answer or reject the new call without disconnecting the current one.
|
||||
|
||||
##### Function Prototype
|
||||
|
||||
```C
|
||||
int tapi_ss_set_call_waiting(tapi_context context,
|
||||
int slot_id,
|
||||
int event_id,
|
||||
bool enable,
|
||||
tapi_async_function p_handle);
|
||||
```
|
||||
|
||||
##### Description
|
||||
|
||||
Asynchronously enables or disables the call waiting feature.
|
||||
|
||||
##### Parameters
|
||||
|
||||
| **Parameter** | **Type** | **Description** |
|
||||
| :------------ | :-------------------- | :----------------------------------------------------- |
|
||||
| `context` | `tapi_context` | The context handle. |
|
||||
| `slot_id` | `int` | The slot ID. |
|
||||
| `event_id` | `int` | The event identifier. |
|
||||
| `enable` | `bool` | `true` to enable, `false` to disable. |
|
||||
| `p_handle` | `tapi_async_function` | The callback function to receive the operation result. |
|
||||
|
||||
##### Asynchronous Callback
|
||||
|
||||
- `status`: The operation result. `0` indicates success.
|
||||
|
||||
##### Code Example
|
||||
|
||||
```C
|
||||
#define EVENT_SET_CALL_WAITING_DONE 2
|
||||
|
||||
// Callback function for setting call waiting
|
||||
static void on_set_call_waiting_done(tapi_async_result* result)
|
||||
{
|
||||
if (result->msg_id == EVENT_SET_CALL_WAITING_DONE) {
|
||||
if (result->status == 0) {
|
||||
printf("Set call waiting succeeded.\n");
|
||||
} else {
|
||||
printf("Set call waiting failed.\n");
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Call the API to set the call waiting service
|
||||
int set_call_waiting_service(int slot_id, bool enable)
|
||||
{
|
||||
if (g_tapi_context == NULL) {
|
||||
return -1;
|
||||
}
|
||||
return tapi_ss_set_call_waiting(g_tapi_context, slot_id,
|
||||
EVENT_SET_CALL_WAITING_DONE, enable, on_set_call_waiting_done);
|
||||
}
|
||||
```
|
||||
|
||||
#### Example 4: Send an SMS
|
||||
|
||||
After activating an eSIM service and enabling cellular communication, developers can send SMS messages by calling APIs from the `Sms` module.
|
||||
|
||||
##### Function Prototype
|
||||
|
||||
```C
|
||||
int tapi_sms_send_message(tapi_context context,
|
||||
int slot_id,
|
||||
int sms_id,
|
||||
const char* number,
|
||||
const char* text,
|
||||
int event_id,
|
||||
tapi_async_function p_handle);
|
||||
```
|
||||
|
||||
##### Description
|
||||
|
||||
Sends a text-based SMS message.
|
||||
|
||||
##### Parameters
|
||||
|
||||
| **Parameter** | **Type** | **Description** |
|
||||
| :------------ | :-------------------- | :----------------------------------------------------- |
|
||||
| `context` | `tapi_context` | The context handle. |
|
||||
| `slot_id` | `int` | The slot ID. |
|
||||
| `sms_id` | `int` | An identifier for the SMS. |
|
||||
| `number` | `const char*` | The recipient's phone number. |
|
||||
| `text` | `const char*` | The content of the SMS message. |
|
||||
| `event_id` | `int` | A user-defined event ID. |
|
||||
| `p_handle` | `tapi_async_function` | The callback function to receive the operation result. |
|
||||
|
||||
##### Asynchronous Callback
|
||||
|
||||
In the `p_handle` function, the `tapi_async_result` struct members are interpreted as follows:
|
||||
|
||||
- `status`: The operation result. `0` indicates success.
|
||||
- `data`: A `(char*)` pointer to the unique identifier (UUID) of the SMS.
|
||||
|
||||
##### Code Example
|
||||
|
||||
```C
|
||||
#define EVENT_SEND_MESSAGE_DONE 3
|
||||
|
||||
// Callback function for the SMS send operation
|
||||
static void on_send_sms_done(tapi_async_result* result)
|
||||
{
|
||||
if (result->msg_id == EVENT_SEND_MESSAGE_DONE) {
|
||||
if (result->status == 0 && result->data != NULL) {
|
||||
printf("Send message succeeded. UUID: %s\n", (char*)result->data);
|
||||
} else {
|
||||
printf("Send message failed.\n");
|
||||
}
|
||||
}
|
||||
}
|
||||
|
||||
// Call the API to send an SMS
|
||||
int send_sms(const char* recipient, const char* message)
|
||||
{
|
||||
if (g_tapi_context == NULL || recipient == NULL || message == NULL) {
|
||||
return -1;
|
||||
}
|
||||
return tapi_sms_send_message(g_tapi_context, 0, 0, recipient, message,
|
||||
EVENT_SEND_MESSAGE_DONE, on_send_sms_done);
|
||||
}
|
||||
```
|
||||
|
||||
#### Example 5: Enable Cellular Data
|
||||
|
||||
The device supports standalone 4G connectivity (independent of Bluetooth/Wi-Fi relay), but mobile data must be enabled manually to access internet services like maps, music streaming, and social apps.
|
||||
|
||||
##### Function Prototype
|
||||
|
||||
```C
|
||||
int tapi_data_enable_data(tapi_context context, bool enabled);
|
||||
```
|
||||
|
||||
##### Description
|
||||
|
||||
Synchronously enables or disables cellular data. This is a synchronous API that blocks until the operation is complete.
|
||||
|
||||
##### Parameters
|
||||
|
||||
| **Parameter** | **Type** | **Description** |
|
||||
| :------------ | :------------- | :------------------------------------ |
|
||||
| `context` | `tapi_context` | The context handle. |
|
||||
| `enabled` | `bool` | `true` to enable, `false` to disable. |
|
||||
|
||||
##### Return Value
|
||||
|
||||
| **Return Value** | **Description** |
|
||||
| :--------------- | :--------------------------------- |
|
||||
| `0` | Success. |
|
||||
| Negative value | Failure, indicating an error code. |
|
||||
|
||||
##### Code Example
|
||||
|
||||
```C
|
||||
bool set_data_connection(bool enable)
|
||||
{
|
||||
if (g_tapi_context == NULL) {
|
||||
return false;
|
||||
}
|
||||
|
||||
int ret = tapi_data_enable_data(g_tapi_context, enable);
|
||||
if (ret == 0) {
|
||||
printf("Data connection status set to %s successfully.\n", enable ? "enabled" : "disabled");
|
||||
return true;
|
||||
} else {
|
||||
printf("Failed to set data connection status.\n");
|
||||
return false;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Step 3: Release the TAPI Context
|
||||
|
||||
When the application no longer needs the Telephony service, call `tapi_close()` to disconnect and release resources, preventing memory and D-Bus connection leaks.
|
||||
|
||||
#### Function Prototype
|
||||
|
||||
```C
|
||||
int tapi_close(tapi_context context);
|
||||
```
|
||||
|
||||
#### Code Example
|
||||
|
||||
```C
|
||||
static void tapi_close_test()
|
||||
{
|
||||
if (t_context != NULL) {
|
||||
tapi_close(t_context);
|
||||
t_context = NULL;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## V. Debugging Tool
|
||||
|
||||
`telephonytool` is an interactive command-line tool that allows you to call TAPI functions directly on the device for rapid debugging and verification.
|
||||
|
||||
### 1. Configuration
|
||||
|
||||
Enable the following option in `Kconfig` to build `telephonytool`:
|
||||
|
||||
```C
|
||||
CONFIG_TELEPHONY_TOOL=y
|
||||
```
|
||||
|
||||
> **Runtime Environment**: It is recommended to run `telephonytool` in the openvela Emulator environment, as it requires the Modem Simulator. Please refer to [Emulator documentation](../../../quickstart/Set_up_the_development_environment.md) to set up the environment.
|
||||
|
||||
### 2. Usage Instructions
|
||||
|
||||
1. Enter `telephonytool` in the system's NSH command line to start the tool:
|
||||
|
||||
```Bash
|
||||
goldfish-armv7a-ap> telephonytool
|
||||
[ 39.370900] [29] [ DEBUG] [ap] tapi is ready for vela.telephony.tool
|
||||
...
|
||||
telephonytool>
|
||||
```
|
||||
|
||||
2. Once inside the `telephonytool`, you can use the `help` command to view detailed command descriptions:
|
||||
|
||||
```Bash
|
||||
telephonytool> help
|
||||
========= Telephony Tool Manual =========
|
||||
***** 1: Radio TAPI Instruction *****
|
||||
***** 2: Call TAPI Instruction *****
|
||||
***** 3: Data TAPI Instruction *****
|
||||
***** 4: SIM TAPI Instruction *****
|
||||
***** 5: SMS & CBS TAPI Instruction *****
|
||||
***** 6: Network TAPI Instruction *****
|
||||
***** 7: SS TAPI Instruction *****
|
||||
***** 8: IMS TAPI Instruction *****
|
||||
***** 9: Phonebook TAPI Instruction *****
|
||||
***** 10: TAPI open&close Instruction *****
|
||||
***** 11: Quit *****
|
||||
***** 12: Help *****
|
||||
Please enter your choice: (1~11)
|
||||
```
|
||||
|
||||
3. Select a module number to view its specific commands. For example, enter `2` to see commands related to Call:
|
||||
|
||||
```Shell
|
||||
Please enter your choice: (1~11)
|
||||
2
|
||||
|
||||
listen-call call manger event callback (enter example : listen-call 0 1 [event_id]
|
||||
unlisten-call call unlisten event callback (enter example : unlisten-call [watch_id] [watch_id, one uint value returned from "listen-call"]
|
||||
listen-call-slot-change register call slot change callback (enter example : listen-call-slot-change)
|
||||
dial Dial (enter example : dial 0 10086 0 [slot_id][number][hide_call_id, 0:show 1:hide])
|
||||
|
||||
...
|
||||
```
|
||||
|
||||
## VI. Testing Tool
|
||||
|
||||
The Telephony module provides a unit test suite based on the CMocka framework for automated testing of the core code.
|
||||
|
||||
### 1. Configuration
|
||||
|
||||
Enable the following options in `Kconfig` to build the test code:
|
||||
|
||||
```Bash
|
||||
CONFIG_TELEPHONY=y
|
||||
CONFIG_TESTING_CMOCKA=y
|
||||
CONFIG_TELEPHONY_TEST=y
|
||||
```
|
||||
|
||||
### 2. Running Tests
|
||||
|
||||
Execute the following command in the NSH command line to run all Telephony-related unit test cases:
|
||||
|
||||
```Bash
|
||||
goldfish-armv7a-ap> cmocka_telephony_test
|
||||
```
|
||||
|
||||
After you enter the command, all Telephony-related test cases will run automatically, and the results will be displayed at the end:
|
||||
|
||||
```Bash
|
||||
[ 3728.347500] [48] [ INFO] [ap] [ RUN ] TestTeleFunc_CallDialingThirdCall
|
||||
[ 3728.348000] [48] [ INFO] [ap] [ OK ] TestTeleFunc_CallDialingThirdCall
|
||||
[ 3728.348100] [48] [ INFO] [ap] [==========] CallTestSuites: 91 test(s) run.
|
||||
[ 3728.348200] [48] [ INFO] [ap] [ PASSED ] 91 test(s).
|
||||
```
|
||||
|
|
@ -2,13 +2,13 @@
|
|||
|
||||
\[ English | [简体中文](../../../../../zh-cn/device_dev_guide/connection/telephony/telephonytool/call.md) \]
|
||||
|
||||
## I. Introduction
|
||||
## I. Overview
|
||||
|
||||
In the NSH command line of openvela, you can perform all call control-related operations by entering the Console of the `telephonytool` command tool.
|
||||
In the openvela NSH command line, you can enter the `telephonytool` console to perform all operations related to call control.
|
||||
|
||||
## II. Prerequisites
|
||||
|
||||
Make sure that `telephonytool` is enabled by executing the following command:
|
||||
Ensure `telephonytool` has been started by running the following command:
|
||||
|
||||
```Bash
|
||||
ap> telephonytool
|
||||
|
|
@ -20,19 +20,19 @@ ap> telephonytool
|
|||
|
||||
#### Description
|
||||
|
||||
The `listen-call` command is used to monitor changes in call status, emergency number changes, and changes in the ringback tone, among other information.
|
||||
The `listen-call` command is used to monitor information such as call state changes, emergency number changes, and ringback tone changes.
|
||||
|
||||
#### Syntax
|
||||
#### Format
|
||||
|
||||
```Bash
|
||||
listen-call [slot_id][event_id]
|
||||
listen-call [slot_id] [event_id]
|
||||
```
|
||||
|
||||
- slot_id: Sets the slot to monitor. Currently, only `0` is supported.
|
||||
- event_id:
|
||||
- `slot_id`: The slot to monitor. Currently, only `0` is supported.
|
||||
- `event_id`:
|
||||
|
||||
- `0`: Call status change.
|
||||
- `1`: Emergency number list change.
|
||||
- `0`: Call state change.
|
||||
- `1`: Emergency number list change (ecc list change).
|
||||
- `2`: Ringback tone change.
|
||||
|
||||
#### Example
|
||||
|
|
@ -54,15 +54,15 @@ telephonytool> listen-call 0 1
|
|||
|
||||
#### Description
|
||||
|
||||
The `unlisten-call` command is used to cancel listening for changes in call status, emergency numbers, and ringback tone changes.
|
||||
The `unlisten-call` command is used to stop monitoring call state changes, emergency number changes, and ringback tone changes.
|
||||
|
||||
#### Syntax
|
||||
#### Format
|
||||
|
||||
```Bash
|
||||
unlisten-call [watch_id]
|
||||
```
|
||||
|
||||
- watch_id: Corresponds to the return value of the `listen-call` command, used to identify the event to stop monitoring.
|
||||
- `watch_id`: The ID returned by the `listen-call` command, which identifies the event to stop monitoring.
|
||||
|
||||
#### Example
|
||||
|
||||
|
|
@ -79,13 +79,13 @@ telephonytool> unlisten-call 95
|
|||
[12820.712800] [28] [ DEBUG] [ap] stop to watch call event with watch_id : 95 with return value : 0
|
||||
```
|
||||
|
||||
### 3. Listen-Call-Slot-Change
|
||||
### 3. listen-call-slot-change
|
||||
|
||||
#### Description
|
||||
|
||||
the `listen-call-slot-change` command is used to monitor changes in the call slot.
|
||||
The `listen-call-slot-change` command is used to monitor changes in the call slot.
|
||||
|
||||
#### Syntax
|
||||
#### Format
|
||||
|
||||
```Bash
|
||||
listen-call-slot-change
|
||||
|
|
@ -112,15 +112,15 @@ telephonytool> listen-call-slot-change
|
|||
|
||||
The `dial` command is used to initiate a phone call.
|
||||
|
||||
#### Syntax
|
||||
#### Format
|
||||
|
||||
```Bash
|
||||
dial [slot_id][number][hide_call_id]
|
||||
dial [slot_id] [number] [hide_call_id]
|
||||
```
|
||||
|
||||
- slot_id: Sets the slot to be used. Currently, only 0 is supported.
|
||||
- number: The phone number to dial.
|
||||
- hide_call_id: Whether to hide the caller ID:
|
||||
- `slot_id`: The slot to use. Currently, only `0` is supported.
|
||||
- `number`: The phone number to dial.
|
||||
- `hide_call_id`: Specifies whether to hide the caller ID:
|
||||
|
||||
- `0`: Show caller ID.
|
||||
- `1`: Hide caller ID.
|
||||
|
|
@ -133,7 +133,7 @@ dial [slot_id][number][hide_call_id]
|
|||
telephonytool> dial 0 10086 0
|
||||
```
|
||||
|
||||
#### Output
|
||||
##### Output
|
||||
|
||||
```Bash
|
||||
telephonytool> dial 0 10086 0
|
||||
|
|
@ -146,16 +146,16 @@ telephonytool> dial 0 10086 0
|
|||
|
||||
#### Description
|
||||
|
||||
The answer_0 command is used to answer an incoming call.
|
||||
Answer an incoming call.
|
||||
|
||||
#### Syntax
|
||||
#### Format
|
||||
|
||||
```Bash
|
||||
answer_0 [slot_id] [call_id]
|
||||
```
|
||||
|
||||
- `slot_id`:Set the slot you want to listen to, currently only `0` is supported.
|
||||
- `call_id`:Call id information of the incoming call.
|
||||
- `slot_id`: The slot to use. Currently, only `0` is supported.
|
||||
- `call_id`: The call ID of the incoming call.
|
||||
|
||||
#### Example
|
||||
|
||||
|
|
@ -178,14 +178,14 @@ telephonytool> answer_0 0 /ril_0/voicecall01
|
|||
|
||||
The `hangup_0` command is used to hang up a call.
|
||||
|
||||
#### Syntax
|
||||
#### Format
|
||||
|
||||
```Bash
|
||||
hangup_0 [slot_id][call_id]
|
||||
hangup_0 [slot_id] [call_id]
|
||||
```
|
||||
|
||||
- slot_id: Specifies the slot to use; currently only slot `0` is supported.
|
||||
- call_id: The ID of the call to be disconnected.
|
||||
- `slot_id`: The slot to use. Currently, only `0` is supported.
|
||||
- `call_id`: The ID of the call to hang up.
|
||||
|
||||
#### Example
|
||||
|
||||
|
|
@ -206,15 +206,15 @@ telephonytool> hangup_0 0 /ril_0/voicecall01
|
|||
|
||||
#### Description
|
||||
|
||||
The `release_and_answer` command releases the current ongoing call and answers the latest incoming call.
|
||||
The `release_and_answer` command releases the current active call and answers the newest incoming call.
|
||||
|
||||
#### Syntax
|
||||
#### Format
|
||||
|
||||
```Bash
|
||||
release_and_answer [slot_id]
|
||||
```
|
||||
|
||||
- slot_id: Specifies the slot to use; currently only slot `0` is supported.
|
||||
- `slot_id`: The slot to use. Currently, only `0` is supported.
|
||||
|
||||
#### Example
|
||||
|
||||
|
|
@ -235,15 +235,15 @@ telephonytool> release_and_answer 0
|
|||
|
||||
#### Description
|
||||
|
||||
The `hold_and_answer` command places the current ongoing call on hold and answers the latest incoming call.
|
||||
The `hold_and_answer` command puts the current active call on hold and answers the newest incoming call.
|
||||
|
||||
#### Syntax
|
||||
#### Format
|
||||
|
||||
```Bash
|
||||
hold_and_answer [slot_id]
|
||||
```
|
||||
|
||||
- slot_id: Specifies the slot to use; currently only slot `0` is supported.
|
||||
- `slot_id`: The slot to use. Currently, only `0` is supported.
|
||||
|
||||
#### Example
|
||||
|
||||
|
|
@ -265,15 +265,15 @@ telephonytool> hold_and_answer 0
|
|||
|
||||
#### Description
|
||||
|
||||
The `release_and_swap` command hangs up the current active call and switches a call that is on hold to the active call.
|
||||
The `release_and_swap` command hangs up the current active call and switches the held call to active.
|
||||
|
||||
#### Syntax
|
||||
#### Format
|
||||
|
||||
```Bash
|
||||
release_and_swap [slot_id]
|
||||
```
|
||||
|
||||
- slot_id: Specifies the slot to use; currently only slot `0` is supported.
|
||||
- `slot_id`: The slot to use. Currently, only `0` is supported.
|
||||
|
||||
#### Example
|
||||
|
||||
|
|
@ -297,21 +297,22 @@ telephonytool> [57714.489500] [21] [ INFO] [ap] [0,0087]> RIL_REQUEST_HANGUP_FO
|
|||
|
||||
#### Description
|
||||
|
||||
The swap command is used to switch the call status between active and hold calls.
|
||||
The `swap` command switches the call state:
|
||||
|
||||
`swap` command to toggle the call state:
|
||||
- From an active call to a held call.
|
||||
- Or from a held call to an active call.
|
||||
|
||||
#### Syntax
|
||||
#### Format
|
||||
|
||||
```Bash
|
||||
swap [slot_id][action]
|
||||
swap [slot_id] [action]
|
||||
```
|
||||
|
||||
- slot_id: Specifies the slot to use; currently only slot `0` is supported.
|
||||
- action: Defines the switching action:
|
||||
- `slot_id`: The slot to use. Currently, only `0` is supported.
|
||||
- `action`: Specifies the swap action:
|
||||
|
||||
- `1`: Switch to hold call.
|
||||
- `0`: Switch to active call.
|
||||
- `0`: Switch to active call (unhold).
|
||||
|
||||
#### Example
|
||||
|
||||
|
|
@ -335,15 +336,15 @@ telephonytool> [57750.211600] [21] [ INFO] [ap] [0,0089]> RIL_REQUEST_SWITCH_HO
|
|||
|
||||
#### Description
|
||||
|
||||
The `hangup-all` command is used to hang up all active calls, including background calls.
|
||||
The `hangup-all` command hangs up all existing calls, including background calls.
|
||||
|
||||
#### Syntax
|
||||
#### Format
|
||||
|
||||
```Bash
|
||||
hangup-all [slot_id]
|
||||
```
|
||||
|
||||
- slot_id: Specifies the slot to use; currently only slot `0` is supported.
|
||||
- `slot_id`: The slot to use. Currently, only `0` is supported.
|
||||
|
||||
#### Example
|
||||
|
||||
|
|
@ -365,19 +366,19 @@ telephonytool> hangup-all 0
|
|||
|
||||
#### Description
|
||||
|
||||
The `get-call` command is used to retrieve information about all ongoing calls.
|
||||
The `get-call` command gets information about all current calls.
|
||||
|
||||
#### Syntax
|
||||
#### Format
|
||||
|
||||
```Bash
|
||||
get-call [slot_id]
|
||||
```
|
||||
|
||||
- slot_id: Specifies the slot to use; currently only slot `0` is supported.
|
||||
- `slot_id`: The slot to use. Currently, only `0` is supported.
|
||||
|
||||
#### Example
|
||||
|
||||
###### Input
|
||||
##### Input
|
||||
|
||||
```Bash
|
||||
telephonytool> get-call 0
|
||||
|
|
@ -409,15 +410,15 @@ telephonytool> [57791.194300] [27] [ DEBUG] [ap] call_list_query_complete :
|
|||
|
||||
#### Description
|
||||
|
||||
The `transfer` command is used to transfer the current ongoing call to another device. This feature depends on network support.
|
||||
The `transfer` command transfers the current active call to another device. This feature is network-dependent.
|
||||
|
||||
#### Syntax
|
||||
#### Format
|
||||
|
||||
```Bash
|
||||
transfer [slot_id]
|
||||
```
|
||||
|
||||
- slot_id: Set the slot to be used, currently only supports `0`.
|
||||
- `slot_id`: The slot to use. Currently, only `0` is supported.
|
||||
|
||||
#### Example
|
||||
|
||||
|
|
@ -438,15 +439,15 @@ telephonytool> transfer 0
|
|||
|
||||
#### Description
|
||||
|
||||
The `get-ecclist` command is used to retrieve information about all emergency numbers.
|
||||
The `get-ecclist` command gets information about all emergency numbers.
|
||||
|
||||
#### Syntax
|
||||
#### Format
|
||||
|
||||
```Bash
|
||||
get-ecclist [slot_id]
|
||||
```
|
||||
|
||||
- slot_id: Set the slot to be used, currently only supports `0`.
|
||||
- `slot_id`: The slot to use. Currently, only `0` is supported.
|
||||
|
||||
#### Example
|
||||
|
||||
|
|
@ -471,15 +472,15 @@ telephonytool> get-ecclist 0
|
|||
|
||||
#### Description
|
||||
|
||||
The `is-ecc` command is used to check whether a specific phone number is an emergency number.
|
||||
The `is-ecc` command checks if a phone number is an emergency number.
|
||||
|
||||
#### Syntax
|
||||
#### Format
|
||||
|
||||
```Bash
|
||||
is-ecc [number]
|
||||
```
|
||||
|
||||
- number: The phone number to check.
|
||||
- `number`: The phone number to check.
|
||||
|
||||
#### Example
|
||||
|
||||
|
|
@ -502,16 +503,16 @@ telephonytool> is-ecc 110
|
|||
|
||||
#### Description
|
||||
|
||||
The `send-tones` command is used to send a preset DTMF (Dual-Tone Multi-Frequency) signal.
|
||||
The `send-tones` command sends a predefined DTMF (Dual-Tone Multi-Frequency) command.
|
||||
|
||||
#### Syntax
|
||||
#### Format
|
||||
|
||||
```Bash
|
||||
send-tones [slot_id][dtmf]
|
||||
send-tones [slot_id] [dtmf]
|
||||
```
|
||||
|
||||
- slot_id: Set the slot to be used, currently only supports `0`.
|
||||
- dtmf: The number (DTMF signal) to be sent.
|
||||
- `slot_id`: The slot to use. Currently, only `0` is supported.
|
||||
- `dtmf`: The digit(s) to send as a DTMF signal.
|
||||
|
||||
#### Example
|
||||
|
||||
|
|
@ -532,16 +533,16 @@ telephonytool> send-tones 0 11
|
|||
|
||||
#### Description
|
||||
|
||||
The `start-dtmf` command is used to send a single DTMF (Dual-Tone Multi-Frequency) signal during a call.
|
||||
The `start-dtmf` command starts sending a single DTMF (Dual-Tone Multi-Frequency) signal during a call.
|
||||
|
||||
#### Syntax
|
||||
#### Format
|
||||
|
||||
```Bash
|
||||
start-dtmf [slot_id][dtmf]
|
||||
start-dtmf [slot_id] [dtmf]
|
||||
```
|
||||
|
||||
- slot_id: Set the slot to be used, currently only supports 0.
|
||||
- dtmf: The number (DTMF signal) to be sent.
|
||||
- `slot_id`: The slot to use. Currently, only `0` is supported.
|
||||
- `dtmf`: The digit to send as a DTMF signal.
|
||||
|
||||
#### Example
|
||||
|
||||
|
|
@ -571,15 +572,15 @@ telephonytool> [58070.453600] [21] [ INFO] [ap] [0,0104]> RIL_REQUEST_DTMF_STAR
|
|||
|
||||
#### Description
|
||||
|
||||
The `stop-dtmf` command is used to stop sending DTMF (Dual-Tone Multi-Frequency) signals during a call.
|
||||
The `stop-dtmf` command stops sending the DTMF (Dual-Tone Multi-Frequency) signal during a call.
|
||||
|
||||
#### Syntax
|
||||
#### Format
|
||||
|
||||
```Bash
|
||||
stop-dtmf [slot_id]
|
||||
```
|
||||
|
||||
- slot_id: Set the slot to be used, currently only supports `0`.
|
||||
- `slot_id`: The slot to use. Currently, only `0` is supported.
|
||||
|
||||
#### Example
|
||||
|
||||
|
|
|
|||