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

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

更好的Cortex-A支持；
- 在Cortex-A上启用device tree，fdt代码大部分以软件包方式存在；
更好的64位支持；
- TCP/IP协议栈部分整体验证过，保证64位情况下都没问题；
- 文件系统相关的都进行验证通过；
完善整体的多核代码，特别是内核代码，核心组件（文件系统，网络协议栈，命令行）的多核支持；
合并rt-smart分支，尽可能的影响只涉及到components/lwp组件的情况即可支持MMU下全进程的特性；
- 支持用户态下以rust方式编程；
- 支持用户态的rust egui移植（应用）；
集成Flash管理组件，如FAL或类似的；
整理，梳理驱动框架、及bsp驱动命名规则。

其他请多多补充。

#5619

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

LLVM #5551

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

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

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

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

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

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

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

康康已经在4.1.0移动完毕 #5662

版本控制规范：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

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

USB 方式连接4G 网络？

有没有 x64 支持？？

https://github.com/RT-Thread/rt-thread/tree/master/bsp/x86

这是 x86 32位的吧，x86_64 也支持？

#6011 (comment)

有没有 x64 支持？？

https://github.com/RT-Thread/rt-thread/tree/master/bsp/x86

这是 x86 32位的吧，x86_64 也支持？

是的，这个是32位的，欢迎来推进x86 64。

NimBLE stack sucks. 千万别。

A few reasons:

Configurations sucks;
Organization of headers/sources sucks;
struct os_mbuf is the worst design I have ever seen.

RT Smart上 asio 有支持计划吗？

#6103 (comment)

有支持fdcan的计划吗？我现在发现设备驱动框架里面好像还没有对FDCAN数据包的处理，都是支持CAN2.0AB标准的数据包。之前我看到论坛有人发帖说在artpi上实现了fdcan实际上好像也是支持到CAN2.0AB的数据包。
https://club.rt-thread.org/ask/question/01ee2cb8a03be0ab.html
https://club.rt-thread.org/ask/question/5c1416f99e0cea0f.html

话说 can 设备驱动，发送和接收的结构体不一样，能忍？……

rt-thread上有计划ADC/DAC驱动模型的DMA支持嘛？

https://club.rt-thread.org/ask/question/a6da7113f233e704.html

这里我写一些关于BSP驱动的想法吧。

最近梳理了一下gd32片上flash的情况
1 flash容量 64k/128k/256k, page 1kb/2kb/4kb
2 flash容量分成bank0, bank1, page 1kb/2kb/4kb
3 flash容量分成bank0, bank1, 使用sector
4 flash容量512k, page 8kb
5 flash容量 <= 128kb, page 1kb

个人把drv flash分成以下系列：
drv_flash_l23x.c
drv_flash_f1x0.c
drv_flash_f10x.c
drv_flash_f20x.c
drv_flash_f3x0.c
drv_flash_f30x.c
drv_flash_f4xx.c
drv_flash_f403.c
drv_flash_e10x.c
drv_flash_e23x.c
drv_flash_e50x.c
drv_flash_c10x.c

对于现在的bsp驱动架构：
drv_flash.c形式
1 同一个文件可能存在几千行代码混杂着大量的宏定义，个人认为过于复杂了
2 不断适配新的芯片有可能频繁改动同一文件，以及为了适配新芯片而加入新的宏定义，频繁改动意味着有可能引入bug风险

drv_flash_xxx.c形式
1 减少改动，减少出现同一个文件修改冲突，以及忘记git pull最新源码造成丢失最新pr的情况
2 利用开源的力量完善驱动，有利于任务分发
比如在开源中国分发完善gd32的drv_flash驱动任务，每个挑战者就可以领取不同系列的drv_flash驱动，加快完善驱动的进程

Navigation Menu

Repository navigation

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

28 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

Guozhanxin commented on Feb 28, 2022

Guozhanxin commented on Feb 28, 2022

mysterywolf commented on Mar 1, 2022

mysterywolf commented on Mar 1, 2022

armink commented on Mar 2, 2022

mysterywolf commented on Mar 16, 2022

BernardXiong commented on Mar 24, 2022

mysterywolf commented on Mar 25, 2022

BernardXiong commented on Mar 25, 2022

mysterywolf commented on Mar 28, 2022

mysterywolf commented on Apr 5, 2022

mysterywolf commented on Apr 8, 2022

jiuxiaxixi commented on Apr 10, 2022

28 remaining items

wxuefei commented on May 31, 2022

mysterywolf commented on Jun 4, 2022

BernardXiong commented on Jun 5, 2022

foldl commented on Jun 21, 2022

Zmmfly commented on Jun 22, 2022

mysterywolf commented on Jun 25, 2022

cazure commented on Jun 27, 2022

grissiom commented on Jul 18, 2022

flyucc commented on Jul 20, 2022

mysterywolf commented on Jul 29, 2022

charlown commented on Aug 2, 2022

mysterywolf commented on Aug 3, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions