@@ -15,15 +15,15 @@ OpenHarmony supports the following system types:
- Mini system
A mini system runs on the devices whose memory is greater than or equal to 128 KiB and that are equipped with MCU processors such as ARM Cortex-M and 32-bit RISC-V. This system provides multiple lightweight network protocols and graphics frameworks, and a wide range of read/write components for the IoT bus. Typical products include connection modules, sensors, and wearables for smart home.
A mini system runs on the devices whose memory is greater than or equal to 128 KiB and that are equipped with MCU processors such as ARM Cortex-M and 32-bit RISC-V. This system provides multiple lightweight network protocols and graphics frameworks, and a wide range of read/write components for the IoT bus. Typical products include connection modules, sensors, and wearables for smart home. Typical boards include Multi-modalV200Z-R.
- Small system
A small system runs on the devices whose memory is greater than or equal to 1 MiB and that are equipped with application processors such as ARM Cortex-A. This system provides higher security capabilities, standard graphics frameworks, and video encoding and decoding capabilities. Typical products include smart home IP cameras, electronic cat eyes, and routers, and event data recorders \(EDRs\) for smart travel.
A small system runs on the devices whose memory is greater than or equal to 1 MiB and that are equipped with application processors such as ARM Cortex-A. This system provides higher security capabilities, standard graphics frameworks, and video encoding and decoding capabilities. Typical products include smart home IP cameras, electronic cat eyes, and routers, and event data recorders \(EDRs\) for smart travel. Typical boards include Hispark_Taurus.
- Standard system
A standard system runs on the devices whose memory is greater than or equal to 128 MiB and that are equipped with application processors such as ARM Cortex-A. This system provides a complete application framework supporting the enhanced interaction, 3D GPU, hardware composer, diverse components, and rich animations. This system applies to high-end refrigerator displays.
A standard system runs on the devices whose memory is greater than or equal to 128 MiB and that are equipped with application processors such as ARM Cortex-A. This system provides a complete application framework supporting the enhanced interaction, 3D GPU, hardware composer, diverse components, and rich animations. This system applies to high-end refrigerator displays. Typical boards include HopeRun DAYU200.
## Directory Structure
...
...
@@ -112,12 +112,14 @@ The HCTest framework is used to support test cases developed with the C language
2. Write the test case in the **src** directory.
1 Import the test framework header file.
1. Import the test framework header file.
```
#include "hctest.h"
```
2. Use the **LITE\_TEST\_SUIT** macro to define names of the subsystem, module, and test suite.
```
...
...
@@ -147,12 +149,16 @@ The HCTest framework is used to support test cases developed with the C language
};
```
5. Use the **RUN\_TEST\_SUITE** macro to register the test suite.
```
RUN_TEST_SUITE(IntTestSuite);
```
3. Create the configuration file \(**BUILD.gn**\) of the test module.
Create a **BUILD.gn**\(example\) build file in each test module directory. Specify the name of the built static library and its dependent header file and library in the build file. The format is as follows:
...
...
@@ -239,6 +245,8 @@ The HCPPTest framework is enhanced and adapted based on the open-source framewor
#include "gtest/gtest.h"
```
2. Define Setup and TearDown.
```
...
...
@@ -263,6 +271,8 @@ The HCPPTest framework is enhanced and adapted based on the open-source framewor
};
```
3. Use the **HWTEST** or **HWTEST\_F** macro to write the test case.
**HWTEST**: definition of common test cases, including the test suite name, test case name, and case annotation.
...
...
@@ -277,6 +287,8 @@ The HCPPTest framework is enhanced and adapted based on the open-source framewor
}
```
3. Create a configuration file \(**BUILD.gn**\) of the test module.
Create a **BUILD.gn** build file in each test module directory. Specify the name of the built static library and its dependent header file and library in the build file. Each test module is independently built into a **.bin** executable file, which can be directly pushed to the development board for testing.
