Toggle navigation
首页
问答
文章
积分商城
专家
专区
更多专区...
文档中心
返回主站
搜索
提问
会员
中心
登录
注册
RT-Thread一般讨论
既然是开源免费,为什么不所有源代码完全发布出来呢?
发布于 2010-01-04 22:17:36 浏览:11314
订阅该版
虽然我很支持RT Thread,但是总觉得好像有点藏着掖着似的。既然rt定位于一个内似于us 的实时操作系统,那就更应该把内核级的东西独立出来啊,其实大多数时候ftp ,ip,文件系统等东西并不是用得最多的东西。 我想usos 之所以出名,一方面是由于它的功能还行。另一方面试它的剪裁行很好。移植性也很好。其最小居然可以移植在51上,缺点就是收费。 不知道RTT 写的内核是否很容易支持跨平台移植。因为最近我在搞一些东西,想用到RTT ,目标平台式freescal 的HCS12系列单片机,以及英飞凌XC186,应用的行业主要是汽车现场控制。对实时性要求非常高。太高的地方直接非OS可接管中断。其余的通讯、安全监控、传感器采集、错误日志、故障诊断、智能判断等则用OS来接管。 就我接触的行业范围来看。很多用操作系统的地方基本不需要文件系统,也不需要TCPIP,也不需要GUI ,只需要简单的串行口,CAN,LIN等现场总线通讯。尤其是单片机系统基本不需要那些东西,不然怎么叫单片机呢,单片机的目标就是把能集成的东西集成在一块片子上,以提高稳定性,就像vxWorks就很支持单片机。,如果RTT 是一个给出C代码然后再改写与cpu,寄存器,定时器相关的内容就可以移植的操作系统的话,那就非常好了。 我也非常希望加入社区。但是我自己基本上不接触arm等,不知道RTT是不是可以移植到单片机上。如果是的话。怎样获取内核及其注释?如果能移植的话。我编好代码后会公布在社区上的
查看更多
17
个回答
默认排序
按发布时间排序
bernard
2010-01-04
这家伙很懒,什么也没写!
藏着啥,掖着啥?唉,真是无语了。。。 [s:183] 对于你说的两种单片机,不是很清楚,你可以说说这两种单片机的大致情况。RTT的代码是公开的,在google svn上即可获得RTT的全部代码。
mbbill
2010-01-05
这家伙很懒,什么也没写!
楼主多虑了。 不过这多少也反映了一些问题,我觉得可能很少有人会用svn去google code的项目主页上面同步代码,而且这个svn地址在主页上也看不到,必须耐心的到论坛里面找帖子才行。更多的可能就是从项目主页上面找download链接,然后顺藤摸瓜找到自己想要东西。 所以rt-thread主页左边最好加入一个download链接,然后把目前发布过的stable和beta rc之类的版本都放上去,最后放svn地址。
fengzi
2010-01-05
这家伙很懒,什么也没写!
楼主也忒心急了,看到注册时间和发帖时间,就知道注册就是为了发这个贴子 仔细在坛里走走看看,就不会有这样观念 支持RTT,同意楼上说法,不过主页已经有了些改善了
ffxz
2010-01-05
这家伙很懒,什么也没写!
有道理,网站主页得多完善些,不要求华丽但至少得达意
zf12862177
2010-01-05
这家伙很懒,什么也没写!
郁闷了。。google SVN 是干什么的啊。查了半天GOOGLE,百度。硬是没有弄清SVN 是干什么的。再说在SVN 上才能获得源代码那有本网站又有什么意思呢?还有啊。我觉得既然是中国的RTOS,注释之类写中文的话不是更好吗?即使对英文再熟练,但是读英文注释的感觉就是和中文不一样。而且中文注释的话,能使开源的代码在中国的受众更广。用英文虽然外国的朋友能看懂,但是真正会看中国人写的代码的外国人又有多少呢? 就好比SMALL RTOS,虽然简单但是看起来就给人一种亲切感。而事实上SMALL RTOS的普及还是挺广的。个人觉得一套开源代码要受众广,要发展必然需要一套好的注释方式。其实我们完全没有必要为了让不懂中文的外国人看得懂而写英文注释,除非RTT的目标是尽力在全球范围内普及。 (话说得不好,词有点不达意,还请不要计较,有时候真的是忠言逆耳哈,本人在此绝没有恶意) 另外上面我提到的是两大类芯片。两类芯片都主要用于汽车电子开发。以及其他一些对环境要求较高的场合,两个公司分别是飞思卡尔和英飞凌 要说特别嘛。没什么特别的,就是单片机啦,不过性能稳定。频率一般不高,多在25M-200M之间,ROM在64-512KB之间。内存在1kb-64KB之间。 通常带很多定时器(7-8个算正常,有的定时器高达20个,而且预分频范围广,中断种类多),带很多AD)16-40算正常),带很多PWM,SPWM控制,带很多通讯接口,不过通讯接口多是工业通讯接口比如CAN 总线。而且一带就是几个can接口。lin总线接口等。串口也是很多,SPI,SCI,3-8 个算是正常。这些都是控制需要用到的,他们对操作系统的要求就是稳定稳定再稳定。一旦操作系统挂了。控制的机器跑飞了。那搞不好人命就出来了。 通常这两大公司的芯片高端产品中CPU还带一个内部DSP协处理器。这些单片机与ARM的区别主要是ROM或者flash不多。ram也不是很多。而且一般不外加RAM,因为外加就意味着干扰。单片化是它们被制造的主要目的。 这些单片机都有自己特别的内核,即指令集是完全不同的,构架也完全不同于常见的其他处理器(主要是为了抗干扰设计)。所以移植的话通常需要经常接触到的人来移植。 就我接触的范围来看这些芯片被用到的情况还是很多的。但是大多数情况下都买的vxworks操作系统。因为它支持啊,可是有点贵,大多数时候不需要投入这么多金钱来买vxWorks。有的时候是用的它们公司送的操作系统。但是不的不说公司送的操作系统纯属鸡肋! 我一般用的编译环境是code warrior ,有的人把他叫做ADS,貌似这个东西的编译器不是GCC吧。 还有一点。我看RTT源代码的时候看得有点头疼啊。很难一眼就分清,哪些些是变量、哪些是函数、哪些又是数组、哪些是全局变量、哪些是函数局部变量、哪些是文件局部变量,在头文件里面也没有找见关于代码命名法的说明。不得不说这对推广有点障碍啊。不过作者可千万不要生气,我并没有恶意哈。因为一般在我接触的范围内很多时候都有规定严格的命名法,比如函数内局部变量首字母小写,后面的单词首字母大写。函数则全部首字母大写。 系统全局变量加上相应的系统名简写(大写),文件局部变量加上对应的文件头简写,数组用A大写结尾,结构体用S结尾等等。 个人愚见,把变量和函数从命名上区分开来很重要,比如一个函数指针,当传递参数的时候,如不能一眼分辨他是函数还是变量,对理解程序结构有点威胁
bernard
2010-01-05
这家伙很懒,什么也没写!
感谢你的建议,难得见码了这么多字的,赞一个! svn指的是版本服务器,用于控制代码的版本,可以方便的做多人协同开发,版本管理,版本回退等。google提供了一个svn的服务,所以这部基本上称为google svn。链接在 [http://code.google.com/p/rt-thread/source/checkout](http://code.google.com/p/rt-thread/source/checkout) 这里,可以通过工具取出完整的RTT代码(也能用工具提交相应代码和大家同步) svn的中文教程 [http://www.subversion.org.cn/svnbook/](http://www.subversion.org.cn/svnbook/) 你的建议代表了很多国内开发人员的心声,只是比较难满足: 1. 注释的问题。不得不说,目前是一个非中文流行的环境,包括编译器。所以我们依然在为使用了中文如何让编译器少产生warning而努力,一直还未找到好的解决方案。对于英文界面软件,有i18n做国际化的支持,可惜注释上没找到相应工具。是否可以考虑自己做一个类似工具呢? 2. 函数、变量命名,这个大多延续了linux下的风格,而对缩进则采取了ANSI的风格。类似MS匈牙利命名的方式,虽然在代码不多的时候能够帮助理解,但代码规模大了后,则变成了一种累赘。 (不附带匈牙利风格命名方式大致存在两种,一种是英文单词,词头是大写形式;另一种是英文单词,词与词之间采用'_'下划线的形式,而整个符号则采用小写的形式。这里采用的是第2种) 您提到的两种单片机,很抱歉,我们没接触过,所以不能给太多和这些单片机相关的帮助。如果你决定把RTT移植过去,和RTT相关的部分,大家肯定会给予最大努力的支持。
mbbill
2010-01-05
这家伙很懒,什么也没写!
>郁闷了。。google SVN 是干什么的啊。查了半天GOOGLE,百度。硬是没有弄清SVN 是干什么的。再说在SVN 上才能获得源代码那有本网站又有什么意思呢?还有啊。我觉得既然是中国的RTOS,注释之类写中文的话不是更好吗?即使对英文再熟练,但是读英文注释的感觉就是和中文不一样。而且中文注释的话,能使开源的代码在中国的受众更广。用英文虽然外国的朋友能看懂,但是真正会看中国人写的代码的外国人又有多少呢? > > 就好比SMALL RTOS,虽然简单但是看起来就给人一种亲切感。而事实上SMALL RTOS的普及还是挺广的。个人觉得一套开源代码要受众广,要发展必然需要一套好的注释方式。其实我们完全没有必要为了让不懂中文的外国人看得懂而写英文注释,除非RTT的目标是尽力在全球范围内普及。 > (话说得不好,词有点不达意,还请不要计较,有时候真的是忠言逆耳哈,本人在此绝没有恶意) > > 另外上面我提到的是两大类芯片。两类芯片都主要用于汽车电子开发。以及其他一些对环境要求较高的场合,两个公司分别是飞思卡尔和英飞凌 >要说特别嘛。没什么特别的,就是单片机啦,不过性能稳定。频率一般不高,多在25M-200M之间,ROM在64-512KB之间。内存在1kb-64KB之间。 > 通常带很多定时器(7-8个算正常,有的定时器高达20个,而且预分频范围广,中断种类多),带很多AD)16-40算正常),带很多PWM,SPWM控制,带很多通讯接口,不过通讯接口多是工业通讯接口比如CAN 总线。而且一带就是几个can接口。lin总线接口等。串口也是很多,SPI,SCI,3-8 >个算是正常。这些都是控制需要用到的,他们对操作系统的要求就是稳定稳定再稳定。一旦操作系统挂了。控制的机器跑飞了。那搞不好人命就出来了。 > > 通常这两大公司的芯片高端产品中CPU还带一个内部DSP协处理器。这些单片机与ARM的区别主要是ROM或者flash不多。ram也不是很多。而且一般不外加RAM,因为外加就意味着干扰。单片化是它们被制造的主要目的。 > 这些单片机都有自己特别的内核,即指令集是完全不同的,构架也完全不同于常见的其他处理器(主要是为了抗干扰设计)。所以移植的话通常需要经常接触到的人来移植。 > 就我接触的范围来看这些芯片被用到的情况还是很多的。但是大多数情况下都买的vxworks操作系统。因为它支持啊,可是有点贵,大多数时候不需要投入这么多金钱来买vxWorks。有的时候是用的它们公司送的操作系统。但是不的不说公司送的操作系统纯属鸡肋! > 我一般用的编译环境是code warrior ,有的人把他叫做ADS,貌似这个东西的编译器不是GCC吧。 > 还有一点。我看RTT源代码的时候看得有点头疼啊。很难一眼就分清,哪些些是变量、哪些是函数、哪些又是数组、哪些是全局变量、哪些是函数局部变量、哪些是文件局部变量,在头文件里面也没有找见关于代码命名法的说明。不得不说这对推广有点障碍啊。不过作者可千万不要生气,我并没有恶意哈。因为一般在我接触的范围内很多时候都有规定严格的命名法,比如函数内局部变量首字母小写,后面的单词首字母大写。函数则全部首字母大写。 > 系统全局变量加上相应的系统名简写(大写),文件局部变量加上对应的文件头简写,数组用A大写结尾,结构体用S结尾等等。 > > 个人愚见,把变量和函数从命名上区分开来很重要,比如一个函数指针,当传递参数的时候,如不能一眼分辨他是函数还是变量,对理解程序结构有点威胁 --- 中文注释的问题,不敢苟同。 1,英文注释很浅显,看懂这点英文对一个coder是基本素质了,否则遇到几百页上千页的datasheet怎么办。用英文注释中国人外国人都能看懂,用中文注释外国人一定看不懂。 2,中文注释对编辑器,编译器,编译环境,都提出了更高的要求。举几个例子,中文的代码不可能用latin1字符集就表示下来,常用的文件格式gb2312或者utf8都是多字节编码,这样就要求编辑器或者编译器能够正确的识别编码,这在某些非中文语言环境下几乎是不可能的。甚至简繁字符集冲突也会让注释直接乱码掉。 编辑器识别不了是乱码,编译器识别不了就编译不过去了。 3,我印象当中ads大概十几年前的东西了吧,这个对中文支持就很差,中文字虽然有时候能显示出来,但是删除字符的时候可能会出现删一半的现象,一句话只要头一个字删掉一半,后面整句话全乱码。
zf12862177
2010-01-05
这家伙很懒,什么也没写!
>中文注释的问题,不敢苟同。 >1,英文注释很浅显,看懂这点英文对一个coder是基本素质了,否则遇到几百页上千页的datasheet怎么办。用英文注释中国人外国人都能看懂,用中文注释外国人一定看不懂。 >2,中文注释对编辑器,编译器,编译环境,都提出了更高的要求。举几个例子,中文的代码不可能用latin1字符集就表示下来,常用的文件格式gb2312或者utf8都是多字节编码,这样就要求编辑器或者编译器能够正确的识别编码,这在某些非中文语言环境下几乎是不可能的。甚至简繁字符集冲突也会让注释直接乱码掉。 编辑器识别不了是乱码,编译器识别不了就编译不过去了。 >3,我印象当中ads大概十几年前的东西了吧,这个对中文支持就很差,中文字虽然有时候能显示出来,但是删除字符的时候可能会出现删一半的现象,一句话只要头一个字删掉一半,后面整句话全乱码。 --- 楼上这位同志,对于你说的能看懂英文注释是对一个coder的基本要求这个我不否认。但是说过。如果想大大在中国推广,那么就一定需要受众广,而受众广的话,必然涉及到各种层次的人,并不是所有用RTOS的就是有一定素质coder,在这里提出用中文注释只是一种建议。 我不知道楼上仁兄所处的行业。但是在我这个行业常常写很多的中文注释是常事,当有些地方涉及到一些很“奇怪”的算法的时候,或者说控制策略的时候不要说英文,就是中文都很晦涩难懂。(当然一切都是为了控制安全),写注释有时候并不是为了维护方便。而是为了后来人学习容易。比如某个系统运行了很久都没出问题。结果就在某一天出了一个问题,”多次论证后深思熟虑“后决定在某一个地方加一个小算法,而这个”小算法“初看细看无论如何都想不通,唯有从整局出发,甚至从千里之外的地方出发才能想通加这个”小算法“的作用的话,那么这个时候我想用英文来表达实在是难之又难,因为用中文表达都是要字字斟酌。 另外,确实我用的code warrior有很久的历史了。不过没办法,人家芯片公司就只提供这么一个编译器,对中文的支持确实不好删字符删除一半。别说我们不想用,就是想用,人家还不把机密部分开放呢。 这几块芯片呢。我是想自己移植下看看。前提是要读懂RTT的运作方式。看能不能适合这些芯片,如果能移植。移植好了的话。我会共享上的
bernard
2010-01-05
这家伙很懒,什么也没写!
这些芯片是多少位的?如果不是32位的,可能得下翻力气,不过不管如何,当你下定决心要移植的时候,我会永远支持你的!
zf12862177
2010-01-06
这家伙很懒,什么也没写!
不是32位。是16位的。
撰写答案
登录
注册新账号
关注者
0
被浏览
11.3k
关于作者
zf12862177
这家伙很懒,什么也没写!
提问
3
回答
3
被采纳
0
关注TA
发私信
相关问题
1
有关动态模块加载的一篇论文
2
最近的调程序总结
3
晕掉了,这么久都不见layer2的踪影啊
4
继续K9ii的历程
5
[GUI相关] FreeType 2
6
[GUI相关]嵌入式系统中文输入法的设计
7
20081101 RT-Thread开发者聚会总结
8
嵌入式系统基础
9
linux2.4.19在at91rm9200 上的寄存器设置
10
[转]基于嵌入式Linux的通用触摸屏校准程序
推荐文章
1
RT-Thread应用项目汇总
2
玩转RT-Thread系列教程
3
国产MCU移植系列教程汇总,欢迎查看!
4
机器人操作系统 (ROS2) 和 RT-Thread 通信
5
五分钟玩转RT-Thread新社区
6
【技术三千问】之《玩转ART-Pi》,看这篇就够了!干货汇总
7
关于STM32H7开发板上使用SDIO接口驱动SD卡挂载文件系统的问题总结
8
STM32的“GPU”——DMA2D实例详解
9
RT-Thread隐藏的宝藏之completion
10
【ART-PI】RT-Thread 开启RTC 与 Alarm组件
最新文章
1
单片机也能聊天?RT-Thread上跑通大语言模型
2
【RT-Thread】【ci】【scons】将ci.attachconfig.yml和scons结合使用
3
Rt-thread中OTA下载后,bootloader不搬程序
4
ulog 日志 LOG_HEX 输出时间改为本地日期时间
5
在RT-Thread Studio中构建前执行python命令
热门标签
RT-Thread Studio
串口
Env
LWIP
SPI
AT
Bootloader
Hardfault
CAN总线
FinSH
ART-Pi
USB
DMA
文件系统
RT-Thread
SCons
RT-Thread Nano
线程
MQTT
STM32
RTC
FAL
rt-smart
I2C_IIC
ESP8266
UART
WIZnet_W5500
ota在线升级
cubemx
PWM
flash
freemodbus
BSP
packages_软件包
潘多拉开发板_Pandora
定时器
ADC
flashDB
GD32
socket
编译报错
中断
Debug
rt_mq_消息队列_msg_queue
SFUD
msh
keil_MDK
ulog
C++_cpp
MicroPython
本月问答贡献
出出啊
1518
个答案
343
次被采纳
小小李sunny
1444
个答案
290
次被采纳
张世争
813
个答案
177
次被采纳
crystal266
547
个答案
161
次被采纳
whj467467222
1222
个答案
149
次被采纳
本月文章贡献
出出啊
1
篇文章
5
次点赞
小小李sunny
1
篇文章
1
次点赞
张世争
1
篇文章
3
次点赞
crystal266
2
篇文章
2
次点赞
whj467467222
2
篇文章
2
次点赞
回到
顶部
发布
问题
分享
好友
手机
浏览
扫码手机浏览
投诉
建议
回到
底部