自行开发兼容目前常用的MCU/DSP的superRTOS实时操作系统! MCU, DSP, superRTOS, 实时操作系统, 开发

esky

当然，工作量是比较大的。
首先要统计大家目前所使用的MCU和DSP，我来搭框架好了。各人做一类CPU的移植好了。其实就是初始化CPU，交权给RTOS就好了。

esky

谢谢大家的支持，可以多谈一些自己的看法。

esky

DSP的结构不适合OS的观点我是不支持的. OS只需要一个Timer来驱动其调度就可以了.
关键是DSP是为算法设计的,而对算法而言,根本就不需要操作系统. DSP+CPLD的结构我是认同的.

esky

正式报名参加这个项目的同志请到http://www.eskytech.com/bbs/newthread.asp?forumid=9报名.
我会在2004年春节前理一份项目开发计划书,正式启动此项目.
这个项目最大的意义在于提供强大的嵌入式开发平台软件.

esky

两位，我完全同意ARM＋DSP的结构。在其实ARM作用就只是数据中转和操作维护。这将增加成本和硬件复杂度。
eDSP，你从DSP结构上来分析不适合OS，我是完全同意的。流水线是DSP结构的重要持点，必须要得到维护。真正进入流水线操作后，中断的请求都将被滞后响应。我认为你提出的合作建议是很不错的想法，我很有兴趣。欢迎交流！

esky

两位,
如果抛开具体应用,只从技术层面分析,我也是同意eDSP的观点的.分析得比较透彻.
而且我也可以举例子,在VIA Telecom的3G基带处理芯片中,采用的是1*ARM7+2*OAKDSP+peripherals结构,可谓典型得很.
但关键是我们如果做成硬件平台+软件中间件,必须要仔细分析需求,并不能假设客户都能掌握ARM,并且愿意去掌握. C51+DSP阵列也可以考虑啊...
呵呵.

esky

eDSP,32KMCU,
我们在Feb. 1st前提出一份方案来吧,然后放上来open review,之后就开始动手做如何?
我的大概想法是必须要有产权的,所以可能采用linux内核,支持的不只是DSP,包括MCU+DSP,和MCU.

esky

如果完全不考虑市场,我感觉很难接受.
open是肯定的.我完全赞同.

esky

当然,但作为开源社区,如果要分享成果,就自己也要有所贡献才行.
我想这是一个原则吧.

esky

针对汽车操作系统市场，我非常看好这个市场。

esky

当然目前基于DSP为CPU的商用实时操作系统早就出来了。
但说到自己来做，比如将基于PPC 的vxworks porting 到DSP上，恐怕没有多少人有这个技术实力。不过我想我们可以一齐来探讨这个问题。
做一个很强的实时操作系统，可以自行识别兼容目前所有最常用的MCU和DSP，这就是idea了。这个产品就会有其存在的价值。大家有兴趣吗？可以一起来做。