Hi3861_WiFi a little understanding of IoT engineering

@liangkZ Updated at 2021.04.25 version: V1.5

directory

1. About the project itself

2.ohos_bundles

3. Project directory structure

4. Understand IoT peripheral control modules

4.1 Expansion of build. gn

4.2 Expansion of led_example.c

4.3 Overall understanding of IoT peripheral control modules

Update record:

2021.04.23

v1.0

Initial version, first 3 sections.

2021.04.25

v1.5

Added section 4 to understand IoT peripherals control modules.

Note: This article is a new chapter of “Hi3861_WiFi IoT Engineering understanding “, version upgraded to V1.5.

4. Understand the IoT peripherals control module Hi3861 development board, the most important function is to use IoT peripherals control module to provide the ability to operate peripherals, including GPIO, I2C, I2S, etc., see README for details.

In this section we’ll look at how these controls are implemented from top to bottom.

Let’s take a look at the official sample application:

applications\sample\wifi-iot\app\iothardware\ BUILD.gn + led_example.c

4.1 Build. gn: build. gn: build. gn: build. gn

include_dirs = [

“//utils/native/lite/include”, # A

“/ / kernel/liteos_m/components/cmsis / 2.0”, # B

“//base/iot_hardware/interfaces/kits/wifiiot_lite”, # C

]

  • A: Go to //utils/native/ Lite and read readme first.

Common Base inventory for OpenHarmony common base components. These basic components are used by OpenHarmony’s business subsystems and upper-layer applications.

Common base libraries provide capabilities on different platforms:

Liteos-m kernel (Hi3861 platform) : KV storage, file operation, IoT peripherals control, Dump system attributes.

Liteos-a kernel (Hi3516, Hi3518 platform) : JS API for KV storage, timer, data and file storage, Dump system properties.

The include directory contains important header files that application development and other modules within the system need to include when calling functions provided by the common base library, including:

Companies init.h/ Ocompanies Init.h, companies COMPANIES, define A group of macros, SYS_RUN(), companies used in led_example.c, with COMPANIES including SYS_RUN(LedExampleEntry); As defined here, LedExampleEntry() will eventually be executed through __zinitCall_run_app_entry in the.zinitCall.run2.init section.

The Thing between SYS_RUN() and MODULE_INIT() by Tang Zolin is very detailed, please read the original article.

2. Utilsfile.h defines an utils-encapsulated file operation interface, UtilsFileXxx(), in the file/ directory one level above,

UtilsFileXxx() { return HalFileXxx(); }. 2.Copy the code

The HalFileXxx() hardware abstraction layer interface is KAL, as shown in #B:

HalFileXxx() specifies the hi_xxx() file operation interface provided by LiteOS_M.

3. Utils_list.h defines and implements a bi-directional linked list structure that is very important.

Just this two days I saw “V01.10 hongmeng kernel source code analysis (bidirectional linked list)”, also recommend to see the original.

The directory structure of the common infrastructure library is shown in the figure above, but the details will not be expanded, please read for yourself.

  • //kernel/liteos_m/

The following “LitEOS-M core architecture diagram”, combined with the screenshot above #A (or the full Hongmeng system architecture diagram), should be understood in depth:

The Kernel Abstract Layer (KAL) is an interface between the Framework Layer and the Kernel (LiteOS_M, LiteOS_A, and the Linux Kernel). The Framework Layer and the Kernel Layer are isolated and decoued through the KAL interface.

KAL can connect the Framework and kernel according to CMSIS standard or POSIX standard. Currently, the code is implemented according to CMSIS – RTOS V2 standard.

There are some structural differences between the kernel/ liteOS_M/directory and the kernel/ liteOS_m/directory of this project. However, there are no significant differences between the structure of the directory and the kernel/ liteOS_m/directory.

See the README.

But in this project Hi3861_Wifiiot, or in accordance with the actual project directory to analyze. 】

Go to the Components directory:

The kal subdirectory, which appears to implement a set of KalXxx() interfaces, mainly timer-related, is implemented by calling the kernel’s LOS_Xxx().

Cmsis subdirectory, this is in accordance with the CMSIS – RTOS V2 standard to achieve a set of interfaces, go to see, mainly to obtain kernel information, thread management, timer management. This is where the thread creation interface osThreadNew() that we call in led_example.c is implemented.

Cmsis-rtos V2 standard and related interfaces

www.keil.com/pack/doc/cm…

XinLiBK on CSDN has translated it into Chinese:

Blog.csdn.net/u012325601/…

I have verified that the kernel in Hi3861_Wifiiot\kernel\ liteOS_m \ directory is not compiled, but components are compiled, you can add log in it, you can print log when running.

  • #C: Go to //base/iot_hardware/ and read readme.

The IoT peripheral control module provides the ability to operate peripherals.

This module provides the following peripheral device operation interface: ADC, AT, FLASH, GPIO, I2C, I2S, PARTITION, PWM, SDIO, UART, WATCHDOG, etc.

IoT peripheral control module is written in C language and currently only supports Hi3861 development board.

The directory structure of the source code is not detailed enough. Let me use a slightly more complete table to clarify the call relationship between them:

Here include / / base/iot_hardware/interfaces/kits/wifiiot_lite statement “B” is the graph, the invocation of the relationship between the lower level to see the right column.

4.2 led_example.c expansion seems to understand the above 4.1 summary thoroughly, led_example.c also naturally understand, here is a brush over.

Start:

#include Common base library header file

Cmsis thread management header provided by #include KAL layer

IoT control module header file encapsulated in the #include framework layer

1. Use the macro SYS_RUN(LedExampleEntry) provided by the public infrastructure library to enter LedExampleEntry.

2. LedExampleEntry cannot do blocking things, because it will affect the start of other applications. Call cmSIS interface to create a thread LedTask, which is specialized in handling the control of Led light switch.

3. LedTask invokes the IoT control related interfaces of the framework layer (the step B is invoked in the right column of the figure above), and then invokes it layer by layer to finally realize the switch control of LED lights.

The end.

4.3 overall Understanding of IoT Peripherals Control Module The above example program provided by the official only shows how to control an LED light on the Hi3861 WLAN motherboard through GPIO.

The development board also has other expansion boards, including universal backboard, display board, NFC board, intelligent three-color light board, etc. (the official information pack also provides more instructions for expanding the hardware function), the different hardware board can be controlled through different interfaces.

To debug a board hardware, need to go to the / / vendor/hisi/hi3861 / hi3861 / build/config/usr_config mk opened the corresponding SUPPORT macros:

# BSP Settings # # CONFIG_I2C_SUPPORT is not set # CONFIG_I2S_SUPPORT is not set # CONFIG_SPI_SUPPORT is not set # CONFIG_DMA_SUPPORT is not set # CONFIG_SDIO_SUPPORT is not set # CONFIG_SPI_DMA_SUPPORT is not set # CONFIG_UART_DMA_SUPPORT is not set # CONFIG_PWM_SUPPORT is not set # CONFIG_PWM_HOLD_AFTER_REBOOT is not set CONFIG_AT_SUPPORT=y CONFIG_FILE_SYSTEM_SUPPORT=y CONFIG_UART0_SUPPORT=y CONFIG_UART1_SUPPORT=y # CONFIG_UART2_SUPPORT is  not set # end of BSP SettingsCopy the code

These macros initialize the control interface and data interface when the system starts the peripheral_init() of app_main(). After that, the debugging routine and related control flow are similar to the control of LED lights above.

Full set of development board details, you can go to run and official website to download:

www.hihope.org/download/do…

The hardware data sheet, schematic diagrams, demo code and more extension instructions are included in the documentation, which seems to be quite playable.

Conclusion:

In general, Hi3861_WiFiIot development board + engineering project, or very suitable for beginners to learn hongmeng system equipment development, from the simple things, can gradually, the system architecture diagram: All kinds of processes, such as the relationship between the upper and lower levels and module components, will not step into the vast sea of complete hongmeng system.

In the next step, I will focus on this project first, combine the complete hongmeng code, and learn about other modules/components that have not yet been involved, so as to get familiar with the board, open up the overall path of equipment development, form my own understanding system, summarize and share more, and make my humble contribution to the Hongmeng ecology.

The above is also a summary of what I learned in the previous stage.

Writing here, I want to shout a slogan, like “Take the first small step, the dream is the sea of stars” or something like that. Suddenly I remembered the product category name of HB Set: Wifiiot_hispark_pegasus. Isn’t that what it means, from Spark to Pegasus, from spark to sea of stars?

Author: liangkz

For more information, visit Harmonyos.51cto.com, a collaboration between 51CTO and Huawei