Guide
1 Audience of This Tutorial
With more and more developers joining and major domestic technology companies improving the ecosystem, OpenHarmony has gradually become popular in the embedded field in recent years. However, there are still relatively few systematic OpenHarmony tutorials in China, and excellent open-source tutorials for beginners are even rarer. This is exactly the reason why our company's open-source department chose to produce this tutorial — to contribute our share to the construction of open-source OpenHarmony.
We mainly target students and embedded enthusiasts with zero foundation or with MCU experience. We focus on getting started, introducing the basic principles of peripherals and interfaces and driving them by writing sample code. From software installation to system compilation, there are detailed teaching documents. In addition, we will subsequently release companion video tutorials on platforms such as Bilibili. All materials are fully open source. Materials and tutorials are still being continuously improved, so please keep paying attention to updates...
2 Concepts and Differences between OpenHarmony and Linux
2.1 Embedded Linux Introduction
Embedded Linux is an operating system that tailors and optimizes the standard Linux kernel for resource-constrained embedded devices. The core components and their corresponding functions are shown in the table below:
| Component | Function |
|---|---|
| Linux Kernel | Provides process management, memory management, driver support (such as GPIO, I2C). |
| BusyBox | A lightweight toolset integrating common command-line tools (ls, cp) |
| File System | YAFFS2/JFFS2 (Flash storage), EXT4 (eMMC/SD card). |
| Cross-Compilation Tool | Such as arm-linux-gnueabi-gcc. |
The kernel adopts a modular design and can dynamically load drivers through device-tree files. And with the development of embedded systems in recent years, the Linux kernel's driver support for various hardware peripherals (such as Wi-Fi, screens, cameras, etc.) has become very complete; you can develop very conveniently after becoming familiar with the Linux development framework.
2.2 OpenHarmony Introduction
OpenHarmony is a distributed operating system operated by the OpenAtom Foundation. It is designed for the Internet of Everything and supports devices with memory from KB level to GB level. It adopts a layered design.
| Layer | Function | Component Example |
|---|---|---|
| Kernel Layer | Multi-kernel support | LiteOS-M (microkernel), Linux kernel |
| System Service Layer | Distributed capability | Distributed softbus, device virtualization |
| Framework Layer | Development interface | ArkUI declarative UI, Ability framework |
| Application Layer | Cross-device deployment | Develop once, run on multiple ends |
Because it supports multiple kernels, when developing, the system can be elastically deployed according to the device. Officially recommended: for systems with RAM < 128KB (the level of the STM32F4 series MCU), choose the lightweight system with the LiteOS-M kernel. For devices with RAM > 128MB, the standard system with the Linux kernel is recommended.
2.3 Differences between OpenHarmony and Linux
For those who have directly understood embedded Linux, you should know that its application development uses the traditional C/C++ language, the UI framework is mostly developed with Qt, and application development requires cross-compilation to compile binary applications for different hardware platforms. Native device interconnection is not supported and requires manual configuration by the developer (manually configured via MQTT protocol, etc.).
In terms of development goals, OpenHarmony is mainly oriented toward multi-device collaboration. On one hand, due to its multi-kernel feature, it can be deployed on systems with limited resources. On the other hand, it natively supports device interconnection. HUAWEI has also designed for it a UI design framework — ArkUI — that can adapt layouts across devices, and HAP applications written with the OpenHarmony development framework can automatically adapt to different devices. A brief summary for you:
| Feature | Embedded Linux | OpenHarmony |
|---|---|---|
| Kernel Selection | Linux | LiteOS-M / Linux |
| Development Language | C/C++ | ArkTS (front-end), C/C++ (low-level) |
| Design Goal | High performance and stability for a single device | Multi-device coordination and interconnection |
| UI Framework | Qt/LVGL, etc. (manually adapt to screen) | ArkUI (cross-device adaptive layout) |
| Application Development | Need to compile binary executables for different hardware | HAP format (automatically adapt to different devices) |
| Device Interconnection | Manual configuration (using MQTT protocol, etc.) | Natively supported (softbus auto-discovery) |
| Development Philosophy | One system per device | Develop once, deploy on multiple ends |
Embedded Linux, after years of development, already has a complete ecosystem, but its device-performance requirements are higher (1GB+ RAM). As a rising star, OpenHarmony is mainly oriented toward device interconnection and low-cost deployment, but at this stage the major-version updates are too fast — an average of once every 2 months — and high versions generally do not support backward compatibility. APIs may change at any time and are not as stable as Linux.
3 OpenHarmony Development Directions
At present, OpenHarmony development is divided into two major directions. Officially called southbound development and northbound development, this section will introduce them separately.
3.1 Southbound Development (Low-Level Hardware Adaptation)
Core Tasks
- Hardware driver development: write OpenHarmony-specific drivers for chips, sensors, and peripherals (cameras/screens) (based on the HDF framework).
- Kernel porting: adapt the LiteOS or Linux kernel to different hardware platforms (such as ARM Cortex-M/RISC-V).
Tech Stack
- System kernel: kernel source code, task-scheduling mechanism, memory management, etc.
- Driver development: Device Tree (DTS) configuration, HDF driver model
- Communication protocols: CAN, SPI, SDIO and other bus drivers, Wi-Fi/BT protocol stack...
3.2 Northbound Development (Upper-Layer Application Development)
Core Tasks
- Application function implementation: use ArkTS to develop cross-device applications (such as a smart-home control center).
- Distributed capability integration: call the softbus to achieve device collaboration (such as a phone controlling a TV to play).
- UI/UX design: use declarative ArkUI to implement adaptive layouts (multi-end adaptation for phones/watches/TVs).
- Performance optimization: ensure the application runs smoothly on low-end devices (such as smart watches).
Tech Stack
- Development language: ArkTS (TypeScript superset), JavaScript
- UI framework: ArkUI declarative syntax, componentized development
- Distributed capabilities: device discovery (DeviceManager), cross-device invocation (RPC), distributed data management (DataObject)
- Toolchain: DevEco Studio (IDE), hdc debugging tool, etc.
4 Development Method Used in This Tutorial
When you open this tutorial, the section titles you see should be Application Development and Device Development rather than the southbound and northbound mentioned in the previous section. The relationship between these four development directions should be as shown in the figure below:
Our tutorial targets Device Development, positioning the full-process development of hardware devices, including both southbound and northbound.
First, we will introduce the basic principles of the peripherals used. After giving everyone an understanding of the peripherals, we will introduce the corresponding peripheral interfaces on the board. Then we test the peripheral drivers through the command-line approach. By explaining the device tree and the pre-installed test commands in the kernel, we incidentally learn some tools and commands commonly used in embedded Linux. After successfully testing the peripherals, we will introduce how to develop your own APIs through NAPI under the OpenHarmony framework, and based on these APIs, write application programs and create basic applications based on common peripherals to get you started.
Some friends may have a question: the system pre-installed on our board is obviously OpenHarmony, so why can we develop in a command-line way just like Linux? That is because the main control chip RK3568 used in this tutorial is powerful enough, so the system we use is a standard system based on the Linux kernel. At this point, the OpenHarmony used is an upper-layer operating system built on top of the Linux kernel, so naturally we can call the interfaces that the Linux kernel provides to user space. We can use the command line for development and testing by connecting to the development board through the HDC debugging tool.
Finally, a brief description of the NAPI development method (the next-version tutorial will cover it in detail later):
On OpenHarmony, Node-API (often abbreviated NAPI) is a native-module development mechanism extended from the Node-API specification based on Node.js 12.x LTS. It provides stable, cross-platform interaction capabilities between ArkTS/JS and C/C++ modules.
The core flow can be summarized as:
Implement native methods on the C/C++ side and perform NAPI module registration;
Configure CMake/build to compile it into a shared library (so);
Provide type declarations (.d.ts) for the ArkTS side (for type hints and compilation);
import this native module on the ArkTS/ETS side and call the exported methods;
At initialization, the import triggers module registration and exported-object construction;
Runtime calls are forwarded to the corresponding C/C++ implementation through the exported object.
5 Rockchip RK3568 Introduction
The SOC used on our M4-R1 board is the RK3568 from Rockchip Electronics.
Main Features
- Quad-core Cortex-A55 up to 2.0GHz
- Mali-G52 GPU
- 1TOPS NPU
- LPDDR4/LPDDR4X/DDR4/DDR3/DDR3L/LPDDR3, ECC
- 4KP60 H.265/H.264/VP9 video decoder
- 1080P60 H.264/H.265 video encoder
- 8M ISP with HDR
- Dual dislplay, LVDS/MIPI-DSI/RGB/eDp/RGB/HDMI2.0/EBC
- 1x8ch I2S/TDM, 1x8ch PDM, 2x2ch I2S
- USB3.0 x2/SATA3.0 x3/PCIE2.1/QSGMII,PCIE3.0 1x2Lanes/2x1Lane
| Detailed Parameters | |
|---|---|
| CPU | • Quad-core 64-bit Cortex-A55, up to 2.0GHz • ARM G52 2EE |
| GPU | • Supports OpenGL ES 1.1/2.0/3.2, OpenCL 2.0, Vulkan 1.1 • Embedded high-performance 2D acceleration hardware |
| NPU | • Supports 1T computing power |
| Multimedia | • Supports 4K 60fps H.265/H.264/VP9 video decoding • Supports 1080P 60fps H.265/H.264 video encoding • Supports 8M ISP, supports HDR |
| Display | • Supports multi-screen heterogeneous display • Supports eDp/HDMI2.0/MIPI/LVDS/24bit RGB/EBC |
| Interface | • Supports USB2.0/USB3.0/PCIE3.0/PCIE2.1/SATA3.0/QSGMII |
(The above data is from the Rockchip official website product center: https://www.rock-chips.com/a/cn/product/RK35xilie/2021/0113/1275.html)
The RK3568 SOC, with its impressive computing power, supports OpenHarmony certification. Its adaptation for open-source OpenHarmony is relatively complete, and it has rich peripheral resources, making it the best choice for learning the OpenHarmony standard system!
6 Learning Material Recommendations
6.1 Official Documentation
- OpenHarmony official documentation: https://www.openharmony.cn/docs/zh-cn/overview
6.2 Development Materials
Since Rockchip does not provide datasheets and SDKs on its official website, these materials can be found in the Baidu Netdisk link "05-Development Materials" we provide for you:
Tip
Download link: https://pan.baidu.com/s/1URTm7_dVX_xuG5UlyQQNlA?pwd=83ui
Extraction code: 83ui
Materials path: 01-Development Materials (Baidu Netdisk) -> 05-Development Materials
Tip
All materials and tutorials are still being continuously improved. Please keep paying attention to updates.