RT thread i/o device model and layering

RT Thread The idea of the device model is to inherit Linux Driven thinking .
commonly RTOS It is used in embedded systems with deep customization , Deep customization means that the system is used to perform specific tasks in a specific environment .
The embedded system with deep customization generally chooses the scheme with low power consumption and low cost . for example ARM M Series architecture MCU, In this environment RTOS The role played is limited
It usually provides limited services to the application layer , And the introduction of virtualized parallel threads ( Mission ), Put inconvenient or unsuitable in ISR The code running in is encapsulated as a task . Software timers are also provided , Synchronization and data communication between tasks , Scheduler function . There are not too many requirements for the underlying driver .

RT Thread The device model of , It is equivalent to providing equipment management API For application layer software .RTOS It specifies uniform naming rules for the application layer . The application layer uses these API Carry out corresponding task development . Under this structure , The application layer calls RTOS Equipment management of API To use the equipment , adopt RTOS Uniformly named user interface functions .

Generally speaking, it means RT THread stay The underlying and application layer mediations get involved . stay RTOS The layer specifies the underlying interface . Then the underlying driver should be implemented according to the specified structure .
The biggest advantage of the direct is decoupling , And introduce strong software layering .

Device drivers , Need to press on RT Thread Framework to write drivers .
The logical entity of the device , Created by the driver . And then register to IO Device manager .
Application call discovery device (RTOS service ) To get the device . Then pass some column standards API Access and control devices .

The definition of equipment is as follows
rt_object Is the kernel object managed by the operating system ,thread,timer, Semaphores and so on are all kernel objects

enum rt_device_class_type type; /* Device type /

rt_uint16_t flag; / Equipment parameters /
rt_uint16_t open_flag; / Device open flag /
rt_uint8_t ref_count; / Number of times the device has been referenced /
rt_uint8_t device_id; / equipment ID,0 - 255 /
/ Data receiving and sending callback function */
rt_err_t (*rx_indicate)(rt_device_t dev, rt_size_t size);
rt_err_t (*tx_complete)(rt_device_t dev, void *buffer);

/* common device interface */
rt_err_t (*init) (rt_device_t dev);
rt_err_t (*open) (rt_device_t dev, rt_uint16_t oflag);
rt_err_t (*close) (rt_device_t dev);
rt_size_t (*read) (rt_device_t dev, rt_off_t pos, void *buffer, rt_size_t size);
rt_size_t (*write) (rt_device_t dev, rt_off_t pos, const void *buffer, rt_size_t size);
rt_err_t (*control)(rt_device_t dev, int cmd, void *args);
Operation function of the device

app The application layer finally uses the device by calling these functions .

struct rt_device
{
    
    struct rt_object          parent;        /*  Kernel object base class  */
    enum rt_device_class_type type;          /*  Device type  */
    rt_uint16_t               flag;          /*  Equipment parameters  */
    rt_uint16_t               open_flag;     /*  Device open flag  */
    rt_uint8_t                ref_count;     /*  Number of times the device has been referenced  */
    rt_uint8_t                device_id;     /*  equipment  ID,0 - 255 */

    /*  Data receiving and sending callback function  */
    rt_err_t (*rx_indicate)(rt_device_t dev, rt_size_t size);
    rt_err_t (*tx_complete)(rt_device_t dev, void *buffer);

    const struct rt_device_ops *ops;    /*  Equipment operation method  */

    /*  Private data of the device  */
    void *user_data;
};
typedef struct rt_device *rt_device_t;

rt_device_t rt_device_create(int type, int attach_size);

establish device It's an application sizeof(struct rt_device) Space size of memory , Used to build device entities . It can be created statically .
The purpose of dynamic creation is to save memory space

rt_err_t rt_device_register(rt_device_t dev, const char* name, rt_uint8_t flags);
register

Add device to system container .

flag The value of the variable represents the property of the device .

rt_device_t rt_device_find(const char *name)
{
    
    return (rt_device_t)rt_object_find(name, RT_Object_Class_Device);
}

Find the device used name Indexes , Look in the air in the system , Get the first address of the equipment control payment - device handle .
rt_err_t rt_device_init(rt_device_t dev);
Call device handle , perform init

rt_device_open
Call device handle , perform open

has GPIO PIN For example

rtthread_startup->rt_hw_board_init->rt_hw_pin_init->rt_device_pin_register—rt_device_pin_register(“pin”, &_stm32_pin_ops, RT_NULL);
_hw_pin Statically defined rt_device_pin Type variable

struct rt_device_pin
{
    
    struct rt_device parent;
    const struct rt_pin_ops *ops;
};

After registration, there will be... In the device fission of the container name “pin”

_hw_pin.parent.write = _pin_write;
_hw_pin.parent. yes rt thread Infrastructure defined for each device
Define beyond the infrastructure ops To hold PIN Special basic API entrance
stay components\drivers\misc Folder has PIN.C
Component means operating system component , On behalf of equipment management .

Called here _hw_pin.ops Execute the write function .

stm32_pin_write Corresponding PIN Write Come on dev It is a useless parameter for writing , That is, it does not require a control handle .
Should be PIN The incoming parameter for is PIN Address ,PIN The address itself is an absolute address , It has a similar function as a handle .
therefore PIN No, device find Steps for , Should be used PIN When PIN The foot name is already a handle .

static void stm32_pin_write(rt_device_t dev, rt_base_t pin, rt_base_t value)
{
    
    GPIO_TypeDef *gpio_port;
    uint16_t gpio_pin;

    if (PIN_PORT(pin) < PIN_STPORT_MAX)
    {
    
        gpio_port = PIN_STPORT(pin);
        gpio_pin = PIN_STPIN(pin);

        HAL_GPIO_WritePin(gpio_port, gpio_pin, (GPIO_PinState)value);
    }
}

Last call HAL Library GPIO Write.

Comb once

rtthread_startup->rt_hw_board_init->rt_hw_pin_init->rt_device_pin_register—rt_device_pin_register(“pin”, &_stm32_pin_ops, RT_NULL);

rt_pin_write As rt thread Provided device functions , Exist in conponents -->pin.c Of RTOS Under construction PIN Equipment management

The device management layer will call the functions of the underlying driver to execute
_hw_pin.ops->pin_write(&_hw_pin.parent, pin, value);

ops Of stm32_pin_write The corresponding is The underlying driver layer That is to say HAL layer bsp\stm32\libraries\HAL_Drivers
STM Of HAL Layer is layered again The first layer is processor agnostic , It implements the underlying logic layer, that is board abstract , Then call and MCU Register related hal function
bsp\stm32\libraries\STM32F1xx_HAL\STM32F1xx_HAL_Driver\Src

So use RTOS Device I / O functions called by the system , The call depth is 3~4 layer
APP-> RT_device_->ops->hal_obj->hal_LL
Application layer development should focus on RTOS The equipment layer is OK , It can efficiently develop applications .
But there are more layers , It will inevitably consume part of the real-time performance , This part is a double-edged sword , According to the needs of the project

UART equipment

Look back rt_device
1. Container standard structure rt_object
2. Type of equipment
3. Device callback function
4. General equipment interface
operations set for device object Namely ops

What you need to do to write a driver is to write it according to the type of device ops Interface .

Think in an object-oriented way
Using a serial port is a device object

1 To use objects, I first register
2 Open it after registration
3 ops The operation obtains the use of the equipment

This is the idea of the application layer
Low level BSP What the layer needs to consider is MCU There are a lot of them ADC modular , Which I want to use

Equipment layer What needs to be considered is to configure the serial port

rtconfig.h RT Thread Files used to configure specific projects , At the end of the document

/* On-chip Peripheral Drivers */

#define BSP_USING_GPIO
#define BSP_USING_UART
#define BSP_USING_LPUART1
#define BSP_LPUART1_RX_USING_DMA

To configure On-chip Peripheral Drivers

In this way bsp\stm32\libraries\HAL_Drivers Yes STM32 chip The driver interface is made IO Management or equipment management . That is to say, the equipment management is in accordance with RTT The way to define the hardware middle layer , Middle layer To connect with the bottom driver , The bottom drivers are based on various models MCU To order of .
The whole process is quite complicated .

A part component.c As the beginning of system initialization . Call function rt_hw_board_init Initialize the hardware
drv_common.c,drv_uart.c (B) be located bsp\stm32\libraries\HAL_Drivers yes RT thread Written BSP Layers are used to adapt ST HAL library , For docking IO Device model (D),IO Equipment management （E） Manage devices using a common model .E Yes OS Provide OPS operations set for device object.
APP Just care operations set for device object. General purpose API function
Bottom drive C, According to the basic requirements, complete the writing of the device driver .
LL Middle layer (B) Connected to the bottom drive , Upper connection D Device model . therefore RT Thread If you develop a driver , Mainly BC Two parts . Need to be right RT Thread Equipment model and MCU Understand the underlying and hardware configuration .

In another way

Application usage rt_device_xxxx API visit IO Device manager . The process is defined by RTT,RTT The equipment is classified and a special model is established
\components\drivers

├─audio
├─can
├─cputime
├─hwcrypto
├─hwtimer
├─i2c
├─include
│  ├─drivers
│  └─ipc
├─ipc
├─misc
├─mtd
├─phy
├─pm
├─rtc
├─sdio
├─sensors
├─serial
├─spi
│  └─sfud
│      ├─inc
│      └─src
├─touch
├─usb
│  ├─usbdevice
│  │  ├─class
│  │  └─core
│  └─usbhost
│      ├─class
│      └─core
├─watchdog
└─wlan

These models are composed of RT Thread Defined by , Belong to IO Manager .

\bsp\stm32\libraries\HAL_Drivers
According to RT Thread Defined by Board level support package built in the way of .

BSP The aim of is to build a bridge between the drive and equipment models , Remove the coupling . Whether it's RTOS Or the underlying changes , Just modify BSP that will do .