"RT-Thread Device Driver Development Guide" reading notes - project construction and device driver framework introduction - based on ADC

wakojosin

"RT-Thread Device Driver Development Guide" reading notes - project construction and device driver framework introduction - based on ADC [Copy link]

<i class="pstatus">This post was last edited by wakojosin on 2023-8-21 17:35</i> # Some code verifications during the preface reading process used RTT Studio, the hardware used was the AliOS Developer kit development board, the main control was STM32L496, and there were multiple sensors, TFT display, WIFI module, etc. on board. **Table of Contents** [TOC] # Preparation1. Download `RTT Studio`; 2. Run RTT Studio, then open `SDK Manager` 3. Install the `STM32L496-NOTIONI-ALI-DEVELOPER` software package4. File->New->RT-Thread Project, select `Based on Development Board`, select STM32L496-NOTIONI-ALI-DEVELOPER in the development board, enter the project name for project name, and finally click Finish, waiting for the project to be created5. Right-click on the project name->`Modify Project`->`System Version`->4.1.1, wait for the switch to complete6. Right-click on the project name->`Synchronize scons configuration to project`, and perform a configuration update (not synchronizing will not necessarily be wrong, and synchronizing will definitely not be wrong) 7. Compile, burn, run, debug, and start your learning journey# Framework Introduction```flow op1=>operation: I/O device model op2=>operation: Device driver framework op3=>operation: Hardware driver op1->op2->op3 ``` The following takes ADC as an example. ## ADC framework Since RTT has two sets of driver frameworks for hardware, there are two ways to implement application programming. ### 1. Device driver framework ```flow op0=>operation: ADC test command op2=>operation: ADC device driver framework op3=>operation: Hardware driver op0->op2->op3 ``` ADC test commands include probe, read, enable and other commands, which can be seen in the msh command line. The application (ADC test command) can perform corresponding control operations on the ADC through the API provided by the ADC device driver framework. ### 2.I/O device model ```flow op0=>operation: application op1=>operation: I/O device model op2=>operation: ADC device driver framework op3=>operation: hardware driver op1->op2->op3 ``` The application can provide operations to the hardware through the rt_device_xxx (xxx=open, read, write, etc.) provided by the I/O device model. For example, the ADC command can be rewritten as follows: ```c // enable interface rt_adc_enable(adc_device,<channel>); //Equivalent to rt_device_control(adc_device, RT_ADC_CMD_ENABLE,<channel>); // read interface value = rt_adc_read(adc_device,<channel>); //Equivalent to rt_device_read(adc_device,<channel>, &value, 1); ``` ### Summary The ADC device driver framework provides users with a unified adc operation interface, including rt_adc_read, rt_adc_enable, etc., and provides a standard interface for hardware, so that developers can implement the code more uniformly. The disadvantage of adc is also obvious, that is, it cannot be used more flexibly. For example, the driver needs to support interrupts, DMA and other functions at the same time, and switch flexibly at runtime (software-defined functions). At this time, the development of the overall driver will be more troublesome. # The overall implementation of other device frameworks is consistent with ADC, that is, a unified interface is provided to the upper side, rt_xxx_yyy, xxx is the framework name, yyy is the interface name, just like rt_adc_read, and a standardized operation set rt_xxx_ops is provided to the lower side, xxx is the framework name, such as rt_adc_ops. For buses such as SPI and I2C, there will be the concept of bus and device, which will be a little more complicated than the implementation of adc. It is the same for the lower side, and an additional step of registering the device through the bus is required for the upper side. After that, the operation of the device is consistent with ADC. Similarly, you can read and write devices through the device framework and I/O model. # Test```sh msh >adc probe adc1 probe adc1 success msh >adc read 3 adc1 channel 3 read value is 0x000003E8 msh > ``` # Summary RTT's device driver allows developers to see a different development process. In the 51 era or the STM32 standard library era, the development of drivers was to directly encapsulate the driver, and use several implementations. The overall style was very messy. When the amount of code increased, the content of the driver file would be very large, and there would be a lot of repeated code in it, so it would be very unfriendly to maintain later. After using the RTT driver framework, the driver implementation can be more pure, which is very friendly to later maintenance. It also provides a unified interface for the development of upper-level code, enhancing portability. # Reference ADC source code is located in `components/drivers/msic/adc.c` The rtt framework is introduced in the first chapter of this book, or refer to the official document ["Device and Driver"](https://www.rt-thread.org/document/site/#/rt-thread-version/rt-thread-standard/programming-manual/device/device) The adc introduction is in Chapter 9 of this book, or refer to the official document ["ADC Device"](https://www.rt-thread.org/document/site/#/rt-thread-version/rt-thread-standard/programming-manual/device/adc/adc) </channel></channel></channel></channel>

Jacktang

The RTT driver framework can be more convenient and user-friendly for later maintenance.

秦天qintian0303

Does ST also have chips based on RT-Thread?

lugl4313820

After using the RTT driver framework, the driver implementation can be more pure, which is very friendly to later maintenance. It also provides a unified interface for the development of upper-level codes, enhancing portability.

Fillmore

Qintianqintian0303 posted on 2023-8-23 17:23 ST also has a film based on RT-Thread?

Yes, I have

damiaa

Beautiful layout by the host!