RT-Thread-RT-Thread studio的驱动5.1.0报错修改RT-Thread问答社区

RT-Thread studio的驱动5.1.0报错修改

发布于 2025-05-03 13:48:03 浏览：32 订阅该版

[tocm]

RT-Thread studio的驱动5.1.0报错修改
---

# 前言
我发现，好像很多芯片使用最新的驱动包5.1.0都会有报错和警告（5以上好像都有些问题），于是参考多方资料，终于修改成功。

---

# 开始修复

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20250503/563c243bbfdc90698193959374dacbcc.png)
接着点击重新构建项目会有如下报错

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20250503/72c1c2136f17f1ec6ce5fcbc9badfcbd.png)
我们定位到第一个报错

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20250503/d8fa87de9a107b241ada6130dedc54cb.png.webp)
先不管错误信息，这个好像有点不准，看官方手册，将变量RT_WEAK 改成了小写，而这里没有更改，那我们改成小写再编译一下。
> 5.0.0
RT_WEAK 改为 rt_weak
ALIGN 改为 rt_align
新增 driver.c 文件
scheduler.c 分为 scheduler_mp.c（SMP 相关） 和 scheduler_up.c（单核）

这里我们要用重新构建，也就是锤头图标那一个，。
在RT-Thread Studio中，构建（Build）和重新构建（Rebuild）是两个不同的操作，它们的主要区别在于执行的操作范围和目的。
**1. 构建（Build）：**
构建操作会编译整个工程，但不会重新编译那些没有发生变化的文件。这意味着，如果某些源文件或头文件没有被修改，构建过程会跳过这些文件的编译，从而节省时间和资源。构建操作通常用于在开发过程中，当你修改了部分代码并希望快速看到结果时。
**2. 重新构建（Rebuild）：**
重新构建操作会强制编译整个工程，无论文件是否发生变化。这意味着，它会重新编译所有的源文件和头文件，确保生成的可执行文件是最新的。重新构建操作通常用于以下情况：
   - 初次编译整个工程
   - 需要确保所有文件都是最新版本时
   - 需要清除旧的编译结果，避免潜在的编译错误
排查警告需要用重新构建，否则不会显示警告，结果如下

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20250503/8470182c9b297d3075818b86eaef3122.png)
可以看到错误信息没有了，只剩警告了，看警告信息，警告几乎都是函数未声明，经过我对很多函数的溯源，发现文件rtsched.h(RT_derive5.1.0\rt-thread\include\rtsched.h)里有一段预处理指令没有编译

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20250503/785d8da049d27760d4e5c4db51ad679e.png)
而这里面包括了很多前面警告没有声明函数的声明，那我们通过定义__RT_KERNEL_SOURCE__或者__RT_IPC_SOURCE__宏就能编译这一段代码，于是我在rtsched.h加入了一句预定义`#define __RT_KERNEL_SOURCE__`，如下。

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20250503/1bf69438756e678147d799d3eb55c402.png)
编译后发现警告大幅度减少

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20250503/66dda444c4ecbef329bfe4b1e74d7cfe.png)
接着继续定位，发现这里的报错是类型不兼容

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20250503/89c7aa86cdde1f342b7fec64b9a3d8a3.png)
我们找到结构体rt_pin_ops的声明，然后也看一下第一个警告函数的声明

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20250503/8e15dd2f5474cec955b7630d8b812d80.png)
```c
static void stm32_pin_mode(rt_device_t dev, rt_base_t pin, rt_base_t mode)
```
发现函数stm32_pin_mode第三个新参类型与rt_pin_ops定义的函数新参类型确实不同，那我们就保持一致就行。rt_base_t 与rt_uint8_t保留哪一个都行，在这里我是保留rt_pin_ops结构体的声明，改变了_stm32_pin_ops里的函数声明。应为我发现函数声明的形参需求的内存都很大，而实际都用不了，rt_pin_ops结构体的声明更加贴切。结果如下

```c
static void stm32_pin_mode(rt_device_t dev, rt_base_t pin, rt_uint8_t mode)
static void stm32_pin_write(rt_device_t dev, rt_base_t pin, rt_uint8_t value)
static rt_err_t stm32_pin_attach_irq(struct rt_device *device, rt_base_t pin,
                                rt_uint8_t mode, void (*hdr)(void *args), void *args)
static rt_err_t stm32_pin_irq_enable(struct rt_device *device, rt_base_t pin,
                                        rt_uint8_t enabled)
```
继续编译，警告更少了，而且还是同样问题，

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20250503/dd0867b01d60449f066434ab75d1d883.png)
经过查看发现，下面的返回类型不一样。经过查找发现，rt_size_t  与rt_ssize_t  类型就是有无符号的区别，这里我保留了rt_size_t  ，因为这个定义使用面更广
```c
static rt_size_t stm32_dma_transmit(struct rt_serial_device *serial, rt_uint8_t *buf, rt_size_t size, int direction)
rt_ssize_t (*dma_transmit)(struct rt_serial_device *serial, rt_uint8_t *buf, rt_size_t size, int direction);
```
```bash
rt_size_t  = long unsigned int
rt_ssize_t  = signed long
```
索引的时候会发现有两个文件serial.h与serial_v2.h都有rt_uart_ops的声明，这两个文件工程会根据使用的串口版本是v1还是v2声明其中一个，默认v1，也就是声明serial.h，那这里我们两个都该就行。
继续编译

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20250503/e943a6161052a8c26f7a14fb33990436.png)
这行代码#pragma GCC diagnostic ignored “-Wimplicit-fallthrough” 的用途是让 GCC 编译器忽略 switch 语句里隐式贯穿（fallthrough）所产生的警告。隐式贯穿指的是在 switch 语句中，某个 case 分支结束时没有 break 语句，从而导致程序流程直接进入下一个 case 分支。
注释掉这一句//#pragma GCC diagnostic ignored "-Wimplicit-fallthrough"整个工程0错误0警告了

![screenshot_image.png](https://oss-club.rt-thread.org/uploads/20250503/fcc5963323a9a5bbdcb56f391648ba52.png)