Shulou(Shulou.com)06/01 Report--

The main content of this article is to explain "what is the method of LiteOS-driven migration". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "what is the method of LiteOS driver migration?"

1. LiteOS bare metal driver migration series

As the saying goes, just talk but not practice fake tricks. The last series of LiteOS kernel practical tutorials described how to manage tasks in the kernel, how to use semaphores to synchronize the operation of multiple tasks, how to protect shared resources with mutexes, and how to apply for the allocation of dynamic memory space, but in embedded systems, if the kernel can not be effectively applied to the actual scene to control peripherals, then everything is on paper. In this series, this tutorial will lead you to add some commonly used peripheral drivers to the LiteOS system, and master the porting method of peripheral drivers.

two。 What is bare metal drive?

Driver layer code, in simple and popular terms, is to provide users with a layer of API that can control the device, down responsible for dealing with the device, and directly operate the hardware.

For example, the driver code of LED can provide users with an initialization API and open / close API, the driver code of keystroke can provide initialization API and API,LCD that reads the state of keystroke, the driver code of sensor can provide initialization API and API of display related content on screen, the driver code of sensor can provide API of sensor initialization and API of reading data, and so on.

If you are not familiar with bare metal drivers based on HAL libraries, please read the embedded basic tutorial first!

Here, take the bare metal project that uses LED flicker generated by STM32CuebMX as an example, where the gpio.c file in the Src directory is equivalent to the driver layer file of LED, and the initialization code of LED is provided:

With this file, the driver layer code, we can call MX_GPIO_Init directly to initialize the LED.

So, where does the driver layer code come from?

If you only use GPIO for simple peripherals, such as LED and keystrokes, you can directly use the gpio.c file and gpio.h file generated by STM32CubeMX.

If it is a more complex peripherals, such as the underlying LCD is driven by SPI, then in addition to the spi.h and spi.c files generated by STM32CubeMX, you also need to handwrite the driver files of the LCD screen on this basis. For specific tutorials, please refer to my bare metal tutorial series: STM32CubeMX tutorials.

3. How to migrate drivers to LiteOS to copy bare Metal driver Files

The target directory structure of LiteOS project is as follows:

There are three folders related to the device driver:

Inc: generate Inc in bare metal project corresponding to STM32CubeMX

Src: generate Src in bare metal project corresponding to STM32CubeMX

Hardware: store the device driver code written by yourself

When copying files, just copy them to the corresponding folder as appropriate.

Here the only LED-related code files are gpio.h and gpio.c, so copy gpio.h to the Inc folder and gpio.c to the Src folder.

These two files are already provided in the HelloWorld project created with IoT-Studio, so you can learn about this operation without having to copy it again.

Add bare metal driver file path

Because the entire project of LiteOS is built using make, after copying the driver file, you need to add the path to the driver file to makefile and add compilation.

The project.mk file indicates the path to all files in the project:

In this file:

C file path

HARDWARE_SRC: the Src folder under the Hardware folder

USER_SRC: corresponding Src folder

Header file path

HARDWARE_INC: the Inc folder under the Hardware folder

USER_INC: corresponding Inc folder

As follows, the gpio.c file driven by LED is added to the USER_SRC (it has been added by default in the project and does not need to be added repeatedly):

Add the gpio.h file driven by LED to the USER_INC (it has been added by default in the project and does not need to be added repeatedly):

At this point, copy the file to the LiteOS project, add the newly copied file path to the makefile, add the project compilation, and complete the migration of the driver.

4. Use of peripheral driver files to initialize peripherals

Before using peripherals, you need to initialize peripherals first. In LiteOS, there are two ways to initialize devices:

Initialize before the system starts scheduling: the device can be used by any task in the system at any time

Initialize in a task: the device is generally only used in this task

For example:

Drivers like LED generally have arbitrary tasks that need to be turned on or off LED, and there is no special LED to light up or close tasks. It is better to initialize them before the system starts scheduling.

Drivers such as the light intensity sensor generally have a special data acquisition task to read the sensor data, and there is no need for other threads to call the driver to read the data, so it can be initialized in the data acquisition task.

It's easy to call initialization API in a task, so how do you call initialization API before the system starts?

In fact, the answer is in the main.c under the Src folder, and the main function is as follows:

As you can see, after the system is powered on, the HardWare_Init function is first called to initialize the hardware device, then the kernel is initialized, shell is initialized, and finally the LOS kernel is started.

The implementation of the HardWare_Init function is also stored in main.c to find out:

How's it going? Are there any surprises? Is it exactly the same as the beginning of the main function of bare metal engineering?

We can throw the initialization function into this function as much as possible, such as the initialization function MX_GPIO_Init () of LED, and initialize the LED automatically when the system is powered on.

Fix the small bug in the gpio.c file

In the MX function of the gpio.c file provided by IoT Studio by default, the pin PC13 of LED is not initialized, and the following initialization code is manually added:

Operating peripherals

Next, first create a folder to hold the code for this series of tutorial labs:

Create a file in this folder:

Write code:

# include # include static int led_blink_entry () {while (1) {HAL_GPIO_TogglePin (GPIOC, GPIO_PIN_13); osal_task_sleep (1x 1000);}} int standard_app_demo_main () {osal_task_create ("led_blink", led_blink_entry,NULL,0x400,NULL,2); return 0;}

Then, as before, add the led_driver_demo.c file to the makefile in user_demo.mk and add the compilation:

Finally, configure to open the macro definition in .sdkconfig:

Compile, burn, and you can see that the LED starts flashing:

At this point, I believe you have a deeper understanding of "what is the method of LiteOS driver migration?" you might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.