rt-thread
rt-thread copied to clipboard
RT-Thread is an open source IoT real-time operating system (RTOS).
在touch文件夹多了个touch.h,历史遗留问题?
## 拉取/合并请求描述:(PR description) Fix smart link script for vexpress a9. ### 当前拉取/合并请求的状态 Intent for your PR 必须选择一项 Choose one (Mandatory): - [ ] 本拉取/合并请求是一个草稿版本 This PR is for a code-review...

[package->mp3player] rt-thread版本 4.0.5 bsp 某个ARM BSP 工具链 arm-none-eabi-gcc -v(5.4.1) 复现步骤:当在scons中的menuconfig选中mp3player时(PKG_USING_MP3PLAYER),编译报错 ``` CC build\packages\wavplayer-latest\src\wavrecorder.o CC build\packages\wavplayer-latest\src\wavrecorder_cmd.o LINK rt-thread.elf d:/env/tools/gnu_gcc/arm_gcc/mingw/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: error: build\packages\helix-v1.0.0\real\arm\asmmisc_gcc.o: Conflicting architecture profiles M/A d:/env/tools/gnu_gcc/arm_gcc/mingw/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld.exe: failed to merge target specific...
目前libcpu/risc-v下的代码,基本上接入一家芯片厂商或芯片就会来一份文件夹,后面需要严格控制者部分的代码,尽可能合并。如果需要独立的文件夹,需要给出完善,完整的理由出来,否则不会进行合并。 同时开启libcpu/risc-v下代码的合并,可以是这样的模式: ```text libcpu └── risc-v ├── common └── vendor ├── chip └── common ``` 尽可能的重用代码,例如`rt_hw_stack_init`, `rt_hw_interrupt_disable/enable`等
# 报错内容: arm-none-eabi-g++: fatal error: cannot execute'c:/programfiles/env-windows-v1.3.2/tools/gnu_gcc/armgcc/mingw/bin/../lib/gcc/arm-none-eabi/10.3.1/collect2.exe: CreateProcess: No such file or directory  # 原因: 链接时参数(.o文件集合)长度超过windows限制的最大长度。CreateProcess WINAPI[函数](https://www.jb51.cc/tag/hanshu/),它接受参数的最大长度是32767个字符。因为代码保存的路径比较深,编译的文件又比较多,导致在链接的时候长度超过了32767  # 解决办法 - 缩短文件路径 - 分模块编译 第一种,比较简单的做法就是给代码库换个存储位置,但这样做不太优雅,而且别人也很容易再遇到相同问题。所以我使用了另一种方式,把编译生成的.o文件统一放到一个文件夹下面来缩短路径。这个方式需要更改的地方并不多,具体如下:  通过下图可以看出,编译时的路径,明显缩短了很多,而且不再受代码库存储位置的影响。当然这种方式如果文件很多,还是会出现问题,目前对于我的应用(编译二三百个文件)来说是够了。如果这个方法不能满足您的需求,那有可能得用第二种方法了。  很抱歉,第二种方法我还没搞明白该怎么弄,,,
## 拉取/合并请求描述:(PR description) Mdio总线需要锁 挂上两个从机之后会抢总线 [ #### 为什么提交这份PR (why to submit this PR) #### 你的解决方案是什么 (what is your solution) #### 在什么测试环境下测试通过 (what is the test environment) ] ### 当前拉取/合并请求的状态 Intent...
## finsh和console以不同标志重复打开相同设备可能导致的潜在BUG finsh和console(ulog基于console)默认使用同一个设备,二者会重复打开,问题如下: ```c static rt_err_t rt_serial_open(struct rt_device *dev, rt_uint16_t oflag) { // ... ignore some code /** * BUG: 重复打开串口设备将会清空之前的标志。 * * 例如首次打开是以RT_DEVICE_FLAG_DMA_TX标志,第二次是以轮询发送方式打开, * 则之前的RT_DEVICE_FLAG_DMA_TX标志将会被清除,而硬件上实际是配置成了DMA发送,这样会导致发送时卡死在轮询实现函数上。 * * finsh和console默认使用同一个设备,将会导致重复打开。 *...
rt_event_recv的timeout参数的单位是什么?源代码中看是tick,文档中看起来遗漏了这块,建议加上。
## 拉取/合并请求描述:(PR description) [ #### 为什么提交这份PR (why to submit this PR) #### 你的解决方案是什么 (what is your solution) #### 在什么测试环境下测试通过 (what is the test environment) ] ### 当前拉取/合并请求的状态 Intent for your...