📋📌 v5.0.0 特性征集与讨论 | v5.0.0 discussion

[BernardXiong]

v5.0.0是一个大版本发布，一些前期的准备也在推进，考虑到的部分包括：

• 内核相关
  • 线程控制块 隐性继承rt_object的问题
  • 对ipc.c进行拆分，这样也可以更清晰；
  • 完善整体的多核代码，特别是内核代码，核心组件（文件系统，网络协议栈，命令行）的多核支持；
    • 对调度器进行拆分，分成公共部分，单核部分，SMP多核部分；
  • 加入tls（Thread Local Storage）特性，可以在tls基础上加入更多的辅助功能
  • 消息邮箱消息队列返回消息长度的问题 消息队列接口设计不合理，rt_mq_recv应该传出消息的实际大小 #5730

• 更好的Cortex-A支持；
  • 在Cortex-A上启用device tree，fdt代码大部分以软件包方式存在；
• 更好的64位支持；
  • TCP/IP协议栈部分整体验证过，保证64位情况下都没问题；
  • 文件系统相关的都进行验证通过；
• 合并rt-smart分支，尽可能的影响只涉及到components/lwp组件的情况即可支持MMU下全进程的特性；
  • 支持用户态下以rust方式编程；
  • 支持用户态的rust egui移植（应用）；
• 集成Flash管理组件，如FAL或类似的；
• 整理，梳理驱动框架、及bsp驱动命名规则。
  • rtdef.h中和设备相关的，都尽可能分离到rtdevice.h中；
  • 实现LLRB和栈数据结构，将ipc文件夹拎出来

其他请多多补充。

[Guozhanxin]

#5619

[Guozhanxin]

驱动框架、及bsp驱动命名规则整理。

[mysterywolf]

LLVM #5551

---

#7521 <- 已经在此PR中得到支持

[mysterywolf]

线程控制块 隐性继承rt_object的问题 #5500

---

已经在此处 完成 #7131

[armink]

目前缺少 Flash 管理类的组件，挺多嵌入式产品上都会用到相关功能。存储也算是系统基础能力，是不是可以把 FAL 从软件包移动至组件里。

---

已完成

[mysterywolf]

GCC下完整的自主的libc，不依赖newlib

[BernardXiong]

• 对调度器进行拆分，分成公共部分，单核部分，SMP多核部分；
• 对ipc.c进行拆分，这样也可以更清晰；
• rtdef.h中和设备相关的，都尽可能分离到rtdevice.h中；
• 🙋‍♂️ 讨论：纳入nimble stack到发布版本中；

[mysterywolf]

不建议nimble stack放在主仓中，到时候又搞的和lwip一样，三个版本一坨

[heyuanjie87]

device.c移动到驱动目录

[mysterywolf]

ipc 的FIFO模式也有问题： #4940

[BernardXiong]

• 加入tls（Thread Local Storage）特性，可以在tls基础上加入更多的辅助功能

[mysterywolf]

赞同，TCB的user_data成员变量应该由TLS取代，否则很容易出现多个上层应用抢一个user_data的问题。

[mysterywolf]

更新（2022年8月28日13:39:00）在此处实现 #6340

---

版本控制规范：https://semver.org/

目前的版本子号不是很规范，其中RT_VERSION甚至和VS那边造成了冲突

/* RT-Thread version information */
#define RT_VERSION                      4L              /**< major version number */
#define RT_SUBVERSION                   1L              /**< minor version number */
#define RT_REVISION                     1L              /**< revise version number */

参考ESP32：

/** Major version number (X.x.x) */
#define ESP_ARDUINO_VERSION_MAJOR   2
/** Minor version number (x.X.x) */
#define ESP_ARDUINO_VERSION_MINOR   0
/** Patch version number (x.x.X) */
#define ESP_ARDUINO_VERSION_PATCH   3

建议改成：

/* Major version number (X.x.x) */
#define RT_VERSION_MAJOR   4
/* Minor version number (x.X.x) */
#define RT_VERSION_MINOR   2
/* Patch version number (x.x.X) */
#define RT_VERSION_PATCH   0

[mysterywolf]

消息邮箱消息队列返回消息长度的问题：#5730
消息邮箱不返回消息长度可能还能理解一下，因为要保持小巧、简单。但是消息队列应该返回实际消息的长度。

[jiuxiaxixi]

USB 方式连接4G 网络？

[jiuxiaxixi]

目前缺少 Flash 管理类的组件，挺多嵌入式产品上都会用到相关功能。存储也算是系统基础能力，是不是可以把 FAL 从软件包移动至组件里。

好像latest 已经这么做了，不过好像是默认支持STM32F2 这个搞得有点尴尬

[jiuxiaxixi]

支持用户态下以rust方式编程； 这个棒！

[mysterywolf]

好像latest 已经这么做了，不过好像是默认支持STM32F2 这个搞得有点尴尬

那个F2只是个例子，你需要自己适配到自己的具体型号，部分bsp也适配了fal，你可以参考

[mysterywolf]

#6235 (comment) RTC框架日期和时间分成了两个函数，容易在比如2023年12月31日23时59分59秒这种节点出问题

[mysterywolf]

实现LLRB和栈数据结构，将ipc文件夹拎出来

[mysterywolf]

是否考虑干掉一个？

[mysterywolf]

对滥用inline以及宏函数的行为展开筛查

[winfenggao]

usb协议栈进行梳理，大部分时候要完全做到拿来就用；可以的话要开始支持OTG了.

[heyuanjie87]

单核情况下定义struct rt_spinlock

[winfenggao]

动态添加的device要有机制避免应用层调用异常；比如U盘热拔插的过程中读写文件等；

[heyuanjie87]

清理libcpu代码调用list_thread();

[armink]

• rtc 框架重构，默认使用软件模拟 RTC ，硬件 RTC 定期自动对时。降低频繁的硬件 RTC 访问次数。

如下图所示，通过 J-Trace 可以发现，大型项目中 timegm 、 HAL_get_time 、HAL_get_date 占用系统负荷较高

[mysterywolf]

正有此意！😁

[mysterywolf]

https://club.rt-thread.org/ask/article/0242e9ce774e161c.html

[Yohozzy]

想要一个统一性的驱动事件回调机制 可以把rx_indicate tx_complete也统合进来
有些场景 例如我的蓝牙带着一个connect信号
当我同步读取的时候 蓝牙断开了 卡死在了rt_device_read
当我异步读取的时候 卡在了等回调
现在的方法是 rx_indicate 回调传入buffer长度为0 再去检查是否已经断开 写起来很奇怪

[BernardXiong]

@Guozhanxin @mysterywolf

随着v5.0的推进，一些原来预先设定的工作可以开展起来的，例如：

• ipc.c拆分，目前这部分太大了；另外也可以参考smart分支，引进例如 RT_INTERRUPTIBLE，RT_KILLABLE，RT_UNINTERRUPTIBLE的特性；
• 对scheduler.c进行拆分，分成scheduler.c（公共部分），scheduler_up.c，scheduler_mp.c三个部分。

[linshire]

可以实现一下控制台二级命令甚至参数的自动补全

[mysterywolf]

建议暂时不考虑，目前会导致ROM底噪进一步恶化。

[mr-cn]

1. 文档中心可以再完善一下
   目前好像文档中心是没有历史版本的，新版本的改动是以文字补充的形式体现的。个人认为文档也可以进行版本控制，新版本有新特性，也可能会导致旧版本的部分接口变化，不同的源码应该对应不同的文档。
   文档可以新增一个一级栏目，提供对不同平台以及不同BSP目前支持情况，以及跟具体架构、具体平台相关的内容。没看源码的bsp文件夹之前，真不知道RTT已经适配这么多平台了。这样原本的文档也可以再整理，尽量避免通用特性的文档中出现特定平台的内容。设想中的结构类似如下：

• 硬件支持
  • 概况
  • 指令集
    • risc-v
    • arm
    • ...
  • BSP
    • Cortex-A
      • i.MX family
      • ...
    • Cortex-M
      • STM32 family
        • STM32 相关支持总览
        • stm32f103-atk-nano
        • ...

2. 开发流程可以有更灵活的策略
   bugfix的小版本更新可以独立于原有的版本发布节奏，有关键bug被修复后可以更快速的发布新版本。
   拿 [armlibc] 修复AC6更新至6.19后_sys_tmpnam()函数编译报错 #6647 这个pr举例，去年底MDK更新后，AC6的libc变化了，导致rtt的libc与之冲突，内核无法通过编译。虽然第一时间就有PR修复了，但是到目前为止还暂时没有新的release发布，目前最新的release-4.1.1还是无法在MDK5.38以上版本通过编译。
   可以参考语义化版本和gitflow。

3. ADC驱动框架还不够灵活
   目前的ADC框架还是有些不够灵活，高速采样时缺少DMA和连续转换等支持，也没法很方便的使用自定义采样时间、硬件过采样、外部触发等特殊功能，开发时或多或少都要对原有驱动架构大刀阔斧地修改。不过ADC其实应该是挺难统一抽象的设备了，本身就有很多完全不同的工作模式和应用场景；外设差异也大，不要说不同平台不同架构了，就连STM32不同系列之间都有不小的差异。

4. 图形API和USB协议栈管理
   这两条其实还有些为时尚早，开发代价很大，在单片机上的应用价值也不大。不过考虑到RT Thread Smart的存在，不同的GUI应用程序直接控制硬件是不现实的，由OS统一管理是十分有必要的；在已经抽象好的文件系统管理和网卡管理等条件下，USB Host应用其实也有相当的想象力了。

[Luanuxe]

请问rt-smart的用户态Rust支持目前情况咋样啊