这个OS真不错，国产也NB，继续努力

发布于 2010-12-28 00:00:43 浏览：3202 订阅该版

看了这个系统，有点相见恨晚的感觉。这个系统就是我想要的系统，既有LINUX的奢华又有UCOS的简洁，结合的这么好，一个字，赞！我搞硬件的，经常写点嵌入式软件，前后台的从汇编写到C，前后台的我觉得写到一个状态机系统算一个头了。再玩了一下UCOS，果然玩了UCOS就不想回前后台了（看需要，状态机系统对成本特别，强调一下特别，呵呵，现在的IC真是够便宜了。当然，考虑极端要求速度的情况，想想看OS系统光一个临界处理就要耗费多少指令，对我们这些玩惯前后台的人来说真是看了心疼。。。），玩了OS系统，看看人家的编程思想，确实NB，所以由俭入奢易，由奢入俭难真没错。看了LINUX的代码后，呵呵，再看看UCOS，再看看自己原来写的东西，真惨不忍睹啊。也就这个月吧，看了LINUX后觉得要是有个怪胎系统能结合一下LINUX和UCOS的优点就好了，毕竟在只有几十kRAM的嵌入式系统中使用LINUX真是容器太小了，而UCOS对设备驱动的处理很不规范，没有设备对象层次结构。对，现在找到了，而且是国产的，呵呵，NB。
提个见意，今天刚下载，最近忙项目没时间仔细看源码，但是粗看了一下类型定义，感觉别扭，不要老是RT-什么的，人家LINUX类型定义好像也没搞什么LINUX-吧，一个类型定义都要搞那么长，写程序的不觉得麻烦吗。没必要，采百家之长是好事，但是也得尊重一下前辈吧，很多命名能继承的就继承一下，也是对前辈表示个敬意对吧。个人意见。
这是一个好系统，对你们的出色工作表示感谢，继续努力！

3 个回答

bernard 2010-12-28

这家伙很懒，什么也没写！

采用前缀命名法，在遇到重名的情况下比较容易规避，所以这个几乎成了业界统一的做法了，例如linux下的GTK+系列，RTOS中的，NucleusPlus，ThreadX等。

在RT-Thread中，原来的文件系统部分，重命名部分是个老大难问题，现在是采用无数个宏的方式绕过去的，如果换一个编译器，还得继续加宏。

总体上，RT-Thread不会刻意的去加很多独立特行的部分，仅对于自身OS部分会这样考虑。对于用户上层应用而言，RT-Thread强调能够和标准libc兼容，和标准POSIX标准兼容。例如0.4.x开发分支上，可以直接使用类似Linux上POSIX Thread方式进行编程。

jovisheng 2010-12-28

这家伙很懒，什么也没写！

banord,这两天做系统有个小想法不知道有没有用。关于设备驱动方面的，设备缓冲不要只设一个，设计成多级缓冲，比如说*in_buf[n]吧，读设备缓冲先用设备的get_lock的到一个可用的in_buf，而设备本身在写in_buf的时候也要用get_lock得到一个可用锁（这样做的意义在于，想像一下如果buf很大，光取buf数据可能就要浪费很多时间，而这时候设备如果有实时处理要求得不到buf的话要么等待要么会丢失数据,对于一个1ms就可能会响应多个数据包的设备）。不要使用信号量什么的，太费处理时间。
对应lock函数区分中断和非中断调用，中断处理lock的时候用最快速度（不需要临界处理，用其它方式）。对于中断处理要保证至少能得到一把锁可以对in_buf操作（不要在中断等待）。
当然还要free_lock了。
考虑通用性和实时性。