Closed Guozhanxin closed 2 years ago
测试框架这部分有啥具体的动作吗?
测试框架这部分有啥具体的动作吗?
直接移除掉吧
借楼整理一下正式发布前需要解决的问题:
CFLAG flag issue 已解决 https://github.com/RT-Thread/rt-thread/pull/5397
使用rtthread如鲠在喉的一个点:串口终端作为日志输出,即使ulog设置为异步也仍然为阻塞查询输出,占用cpu且输出效率低。
希望版本发布后,能与之前的所有包兼容。并且给出从老版本升级到新版本的官方文档。
前的所有包兼容。并且给出从老版本升级到新版本的官方文档。
https://github.com/RT-Thread/rt-thread/pull/5277 可以看一下这个,新版本有专门的legacy文件夹
打开之后,仍然很多不兼容的地方。特别是我自己写的应用层(大概8万行代码),用在新内核上很多地方不兼容了,主要是一些宏之类的做了调整,没去细看为什么要这样改,但希望尽量减少这种调整吧,或者用宏都老的定义管起来,但仍然保留。
打开之后,仍然很多不兼容的地方。特别是我自己写的应用层(大概8万行代码),用在新内核上很多地方不兼容了,主要是一些宏之类的做了调整,没去细看为什么要这样改,但希望尽量减少这种调整吧,或者用宏都老的定义管起来,但仍然保留。
再不改,里边很多东西都变成毒瘤了。 https://github.com/RT-Thread/rt-thread/issues/5230 https://www.bilibili.com/video/BV15f4y1u7yA
使用rtthread如鲠在喉的一个点:串口终端作为日志输出,即使ulog设置为异步也仍然为阻塞查询输出,占用cpu且输出效率低。
请看论坛我发的文章,我刚对串口框架做了个重构,阻塞 io 情况下,降低阻塞时间。
https://club.rt-thread.org/ask/question/434195.html ps或者list_thread最后一栏错误码,显示的是错误码代码 非常的不友好,别人根本不知道什么意思
所有的 msh 命令,增加 c 函数调用接口,类似 https://gitee.com/thewon/rt_thread_repo/tree/master/user 这里实现的命令一样,既有终端命令入口,也有对等的 c 调用入口。
v4.1.0版本release后,可以拉分支出来。然后master也会尝试拉pre-v5.0.0分支,然后把smart相关的一些代码合并。如果春节期间能够合成功,那么再合并回master分支,做为后续的v5.0.x分支而存在。
另外,建议v4.1.0分支也不用做alpha, beta, rc版本,直接出v4.1.0版本,有问题可以快速修正到v4.1.1版本
打开之后,仍然很多不兼容的地方。特别是我自己写的应用层(大概8万行代码),用在新内核上很多地方不兼容了,主要是一些宏之类的做了调整,没去细看为什么要这样改,但希望尽量减少这种调整吧,或者用宏都老的定义管起来,但仍然保留。
可以一些点上多做沟通,如何在新特性和兼容性上做到平衡
另外,建议v4.1.0分支也不用做alpha, beta, rc版本,直接出v4.1.0版本,有问题可以快速修正到v4.1.1版本
建议用beta,因为4.1.0 beta版本还有一部分功能原计划4.1.0需要实现的还没有实现。4.0.4已经吃了一次亏了,变化太大,用户反应有些不适应,4.1.0作为大版本,得一次性把较大改变的内容全部都搞定,从4.1.1版本开始就不能剧烈地增加新功能了。否则,如果4.1.0直接发出去了,4.1.1还要增加新功能,可能要重踩4.0.4发布时的问题。
FINSH_FUNCTION_EXPORT
FINSH_FUNCTION_EXPORT_ALIAS
可否提供一个相对统一的 lcd 框架,对上提供统一的接口。这样在 lvgl 包中实现 rtt 的屏幕驱动,底层让用户和 bsp 去对接就好,然后直接编译就可以直接使用了。
可否提供一个相对统一的 lcd 框架,对上提供统一的接口。这样在 lvgl 包中实现 rtt 的屏幕驱动,底层让用户和 bsp 去对接就好,然后直接编译就可以直接使用了。
这个问题想过,当时rtt自己维护的lvgl软件包(7.0)就是采用直接和rtt lcd框架对接的方式。但是经过实践之后发现,本身lvgl自己就已经提供了底层的抽象层,如果再对接一个lcd框架就显得脱裤子放屁,因此在lvgl官方软件包中,就采用了lvgl原生的api,方便用户做出选择,既可以直接怼lcd原生驱动,也可以自行怼lcd框架。我们这侧就不强制用户非得使用lcd的框架了,给予最大灵活性
文档是关键!! 哪怕什么功能都不改进,只补充、丰富文档,看似原地踏步,实则也是坐着直升机原地踏步! 论坛里很多文章应该整合到文档中心,过于分散,论坛中的优秀帖子、文章很容易随着时间的流逝而压箱底,需要将精华整理到文档中心。
设备框架文件命名不统一,API命名不统一,很容易把初学者搞蒙 杨老师那边怎么办?
无论是宏定义也好、函数名也好、文件也好,一定要有我们自己的标识前缀,因为我们是有众多软件包的,如果名字起的太过于普遍,很容易和其他软件包的名字冲突。
建议设备框架统一前缀为:dev_pwm.c/.h dev_adc.c/.h
建议考虑CMake作为未来的构建工具,现在越来越多的IDE都在支持CMake了,scons确实有点老了。
目前正在考虑把公司的下一代产品构建在RTThread上,但是这个scons的构建系统让人望而却步。
建议考虑CMake作为未来的构建工具,现在越来越多的IDE都在支持CMake了,scons确实有点老了。
目前正在考虑把公司的下一代产品构建在RTThread上,但是这个scons的构建系统让人望而却步。
可以提一份方案上来,cmake也有些古老,其中的语法方式也不那么友好。scons部分在RTT这边做了挺多的一些调整,有好的有坏的,一下就想更换构建系统,不容易/很不容易。
@jifanchn 反对将RT-Thread Scons转移到其他构建方式。这相当于是自废武功。scons构建方式很灵活,基于python语法的优势,很多复杂的文件和路径添加逻辑几句话就可以完成,而且可以引用python丰富的内置函数。Scons是RT-Thread定制化的构建工具,我们可以根据需求自行对scons进行修改,处理更加灵活。
此外RT-Thread支持Keil,IAR VSCODE VS Cmkae Makefile等其他工程的生成,这也全都得益于scons。如果转换到Cmake构建方式,如何构建Keil IAR等等其他的project?Scons是支持生成Cmake工程的,在env里,敲scons --target=cmake
即可
目前Scons的主要问题是文档太少了!这也是很多人望而却步的主要原因,实际上常用的Scons函数没有几个,如果有文档或者教学视频,照葫芦画瓢很简单。文档和教学视频是RT-Thread目前依然要急需填的坑!
@mysterywolf 如果能用SCONS完美构建CMAKE工程也是可以接受的,但是也要考虑到公司的静态库权限管控和SDK升级需求。Keil和IAR这样的IDE我们已经深受其害了,在多人维护的系统和持续迭代更新的产品中,编译目标的控制无法被GIT等源代码版本控制系统维护是造成嵌入式产品源代码碎片化的重要原因之一。另外构建系统不仅需要支持嵌入式代码编译,也要能支持整个软件生命周期的源代码测试用例、并行仿真、第三方算法工程代码生成、开源代码的引用的调用等一系列操作。CMAKE的开发者数量与生态已经不是SCONS能比的了,甚至可以说已经是C/C++事实上的标准构建系统了。想想QMAKE/MAKEFILE,甚至微软VS的构建系统都已经转向支持CMAKE,JB家的CLION甚至只支持CMAKE。换句话说,SCONS生成Keil和IAR这样的工程,也只是对不熟悉开源社区的“传统”嵌入式程序员的兼容罢了。看看还活跃的C/C++开源库,不支持CMake的太少了。缺少说明文档库,其实就是生态缺失的重要标志之一。 RTThread作为国产的优秀、稳定的嵌入式操作系统,不仅应该做到兼容,同时也应考虑能“温和地”正确引领嵌入式开发的发展方向,为嵌入式开发生态转变甚至超越目前的互联网生态模式做出更多努力。 这也是我建议转向CMake的原因之一。
----看看zephyr吧。
@jifanchn zephyr的模式学不来的,门槛太高了,得要求使用者有Linux使用经验,全面转到Linux环境或类unix环境下开发,其开发方式很不符合我国国情。
中国开发嵌入式的工程师来自于两部分,一部分是计算机专业以及软件工程专业毕业的,受过Linux等良好的软件开发教育,可以轻松应对 Cmake,makefile,shell等等这些东西。还有一部分是电子、电子、通信专业毕业,其专业内,Linux等软件开发科目并不是必修科目,他们更喜欢用Keil IAR这类集成性IDE来点点点按钮。
当然如果你觉得目前RTT CMake应该如何做,欢迎提出意见,因为我们确实也收到类似希望采用CMake来开发的建议了。但是很难全面转型到Cmake,就像上面说的,我们会完善scons的Cmake脚本生成能力,或者下次发布版本的时候可以把Cmake脚本直接刷到仓库里,让CMake用户可以直接用起来,直接无视Scons,这都是可以讨论的。但是scons肯定是不能动的,我们得保证中国所有专业方向的嵌入式工程师的死活,不能仅仅服务于那一部分非常专业的、熟悉Linux开发环境的嵌入式工程师。
同意你的说法,keil和IAR是要支持的。
CMake能有某种方法直接和scons并行这是最好的。
互联网最近已经开始卷了,国内未来深入设备底层的开发也会越来越多,我司目前也看到招聘中人员收入,学历和行业的错位。未来也会有越来越多的熟悉Linux的专业程序员进入。
在 2022年3月3日,上午9:10,Man, Jianting (Meco) @.***> 写道:
zephyr的模式学不来的,门槛太高了,得要求使用者有Linux使用经验,全面转到Linux环境或类unix环境下开发,其开发方式很不符合我国国情。
中国开发嵌入式的工程师来自于两部分,一部分是计算机专业以及软件工程专业毕业的,受过Linux等良好的软件开发教育,可以轻松应对 Cmake,makefile,shell等等这些东西。还有一部分是电子、电子、通信专业毕业,其专业内,Linux等软件开发科目并不是必修科目,他们更喜欢用Keil IAR这类集成性IDE来点点点按钮。
当然如果你觉得目前RTT CMake应该如何做,欢迎提出意见,因为我们确实也收到类似希望采用CMake来开发的建议了。但是很难全面转型到Cmake,就像上面说的,我们会完善scons的Cmake脚本生成能力,或者下次发布版本的时候可以把Cmake脚本直接刷到仓库里,让CMake用户可以直接用起来,直接无视Scons,这都是可以讨论的。但是scons肯定是不能动的,我们得保证中国所有专业方向的嵌入式工程师的死活,不能仅仅服务于那一部分非常专业的、熟悉Linux开发环境的嵌入式工程师。
— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you were mentioned.
在4.1.0需要升级的:
新版本有计划增加获取USB是否连接的接口吗?USB DTR标志是必须的吗?ChibiOS的usb驱动(STM32F427),上位机勾选DTR,似乎也能通信
软件包
在4.1.0需要升级的:
- [ ] https://github.com/RT-Thread-packages/paho-mqtt issue中反馈了一些bug并提出了解决方案,需要整合到仓库中
- [ ] https://github.com/RT-Thread-packages/fal FAL根据龙哥建议,应当放到主仓库
- [ ] https://club.rt-thread.org/ask/question/433049.html
- [ ] https://club.rt-thread.org/ask/question/431576.html
- [ ] https://club.rt-thread.org/ask/question/430162.html
libmodbus软件包编译报错问题也可以修改下,主要涉及几个头文件,论坛里已有解决方案 https://club.rt-thread.org/ask/article/3280.html
STM32F1 RTC读写日期不正常 https://club.rt-thread.org/ask/question/434910.html
新版本有计划增加获取USB是否连接的接口吗?USB DTR标志是必须的吗?ChibiOS的usb驱动(STM32F427),上位机勾选DTR,似乎也能通信
@BreederBai 是 RTT 的 USB 协议栈还是 TinyUSB 呢?
FAL添加到 rt-thread 主仓库:https://github.com/RT-Thread/rt-thread/pull/5662
内核可以考虑用这种方式来设置堆栈大小,例如对于龙芯,其idle main线程的栈大小要高于32位的
第二个源文件被删了吧 https://club.rt-thread.org/ask/question/430704.html
是的可以不用管了~
新版本有计划增加获取USB是否连接的接口吗?USB DTR标志是必须的吗?ChibiOS的usb驱动(STM32F427),上位机勾选DTR,似乎也能通信
@BreederBai 是 RTT 的 USB 协议栈还是 TinyUSB 呢?
@tfx2001 RTT 的 USB 协议栈
软件包
在4.1.0需要升级的:
- [x] https://github.com/RT-Thread-packages/paho-mqtt issue中反馈了一些bug并提出了解决方案,需要整合到仓库中
- [x] https://github.com/RT-Thread-packages/fal FAL根据龙哥建议,应当放到主仓库
- [x] https://club.rt-thread.org/ask/question/433049.html
- [x] https://club.rt-thread.org/ask/question/431576.html
- [x] https://club.rt-thread.org/ask/question/430162.html
- [x] https://club.rt-thread.org/ask/question/430162.html
- [ ] libmodbus软件包编译报错问题也可以修改下,主要涉及几个头文件,论坛里已有解决方案 https://club.rt-thread.org/ask/article/3280.html
第三个作者修了 https://github.com/gbcwbz/canfestival-rtt/issues/9#issuecomment-1068134572
v4.0.4 已经发布了,所以我们开始筹备下个版本的发布了,下个版本按计划是一个次版本的更新,将会包含更多的新特性。
如果您也有一些功能想法或对当前计划的看法,请发表评论。
v4.0.4 has been released, so we have started to prepare for the release of the next version. The next version is planned to be a minor version update and will contain more new features.
please comment if you also have some features ideas in mind or share your opinion about the planned features.
Features
BSP
Package
LVGL https://github.com/lvgl/lvgl/issues/2790
Exquisite
Rename finsh to mshOthers