自行开发兼容目前常用的MCU/DSP的superRTOS实时操作系统!
|
- UID
- 157066
- 性别
- 男
|
当然，工作量是比较大的。
首先要统计大家目前所使用的MCU和DSP，我来搭框架好了。各人做一类CPU的移植好了。其实就是初始化CPU，交权给RTOS就好了。 |
|
|
|
|
|
|
- UID
- 15
- 性别
- 男
|
|
|
|
|
|
|
- UID
- 157066
- 性别
- 男
|
|
|
|
|
|
|
- UID
- 80026
- 性别
- 男
|
|
|
|
|
|
|
- UID
- 80187
- 性别
- 男
|
| 标准的DSP结构属于“OS不友好”的，虽然我认为DSP最终会大量支持OS，但是目前主流DSP做OS移植难度实在不小。唯一的例外是Blackfin，那是在设计时就考虑了支持OS的。 |
|
|
|
|
|
|
- UID
- 15
- 性别
- 男
|
| Blackfin也是ADI准备在中国的主推产品，相信大家可以看到2004年里ADI有一系列的举措。 |
|
|
|
|
|
|
- UID
- 80187
- 性别
- 男
|
| TI的解决方案是DSP+(ARM)MCU，优势是分工明确，缺点是开发需要学习两套系统，而且存在DSP和MCU间的通信、同步等问题。我个人觉得DSP+FPGA/CPLD倒是一种可以解决硬件构成和软件移植复用的方案。这个方案可行的前提主要近来FPGA/CPLD工艺、技术的提高和成本的大幅度降低。毕竟现在不论是MCU还是DSP，不用到FPGA/CPLD的地方不多了。 |
|
|
|
|
|
|
- UID
- 157066
- 性别
- 男
|
DSP的结构不适合OS的观点我是不支持的. OS只需要一个Timer来驱动其调度就可以了.
关键是DSP是为算法设计的,而对算法而言,根本就不需要操作系统. DSP+CPLD的结构我是认同的. |
|
|
|
|
|
|
- UID
- 157066
- 性别
- 男
|
正式报名参加这个项目的同志请到http://www.eskytech.com/bbs/newthread.asp?forumid=9报名.
我会在2004年春节前理一份项目开发计划书,正式启动此项目.
这个项目最大的意义在于提供强大的嵌入式开发平台软件. |
|
|
|
|
|
|
- UID
- 80187
- 性别
- 男
|
| DSP的结构不适合OS的主要原因是DSP一般是RISC加流水线结构，尤其是高端的DSP。比如说吧，X86上跑OS在切换任务的时候只需要压栈比较少的寄存器，而即使是ARM这样的RISC CPU需要压栈的寄存器数量也不是太多。但是DSP一般为了提高运算速度，都作了比较多的寄存器，这些寄存器的压栈需要的时间就比较多了，当然现在DSP的主频比较高，这也是能接受的，但更大的问题是流水线被打断，这样浪费的时间就比较多了，DSP的工作特点是保证数据流的高速输入、运算、输出，所以DSP做硬件全寄存器压栈结构的都不多。通常OS的工作特点是以定时地中断来切换任务，可是DSP怕的就是中断，当然并非DSP不可中断，一般DSP都有中断机制，可是一旦用OS的时间片轮转的方式来定时中断DSP，其性能将大打折扣。所以我说在DSP上跑OS必定是未来的方向，但现在还有一些困难。这者转折点就在软件成本高于硬件成本的时候，这基本上和通用CPU的发展历程是一样的。我个人对在DSP，尤其是高端的DSP上跑OS非常感兴趣，但每当考虑到细节问题是，总是觉得困难多多。我曾经请教过邵贝贝（清华大学翻译uCOS/-II的那个教授），因为我认为象uCOS/-II这样的OS是很适合向DSP移植的。实际上uCOS/-II也确实支持TI以及ADI的一些DSP，但是效果呢？问题还是存在的。所以当时邵贝贝的回答基本上也和我上面所表达的看法类似。 |
|
|
|
|
|
|
- UID
- 15
- 性别
- 男
|
| 目前来看，使用ARM加DSP是个不错的选择，在价格上并没有太大的改变，就可以得到较好的性能。 |
|
|
|
|
|
|
- UID
- 80187
- 性别
- 男
|
| 对，这样OS可以跑在ARM里面，而DSP用于密集型运算任务。一般DSP都有个主机接口，也是这个原因。 |
|
|
|
|
|
|
- UID
- 157066
- 性别
- 男
|
两位，我完全同意ARM＋DSP的结构。在其实ARM作用就只是数据中转和操作维护。这将增加成本和硬件复杂度。
eDSP，你从DSP结构上来分析不适合OS，我是完全同意的。流水线是DSP结构的重要持点，必须要得到维护。真正进入流水线操作后，中断的请求都将被滞后响应。我认为你提出的合作建议是很不错的想法，我很有兴趣。欢迎交流！ |
|
|
|
|
|
|
- UID
- 80187
- 性别
- 男
|
我总的意思是：DSP并非不能跑OS，DSP也是个CPU，当然能跑，但跑了OS的DSP性能要下降，这是我们不愿意看到的结果。但是为了提高软件开发效率和降低软件成本，我们又希望DSP系统有OS支持。
这就让我们必须要来考虑各种可能的方案。ARM+DSP是一个比较经典的方案，象TI已经将其做到一个芯片里面了。ARM在这个系统里主要是做控制密集型任务，比如人机界面，任务调度什么的，DSP则作语音、图像等运算。从保证数据流的连续性来看，ARM也不适合作数据中转，FPGA更合适。比如TS201，IO带宽达到了40G bps，少有ARM芯片能胜任这个中转任务。DSP最重要的是保证进出数据流的流畅，所以现在ADI将TS201的IO口做成了DDR的LVDS(这是现在的FPGA直接支持的)，而TI的64系列还采用总线方式，在BDTI的评测可以看到，TI的高端芯片最大的问题是IO带宽相对小了。对于ARM+DSP系统，我认为最大的问题还不是硬件成本问题，现在的ARM芯片价格已经很低了，而且这个系统已经有了DSP这个运算引擎，也不需要ARM又很大的运算能力，所以硬件成本增加很少，但有了ARM后就需要增加一套开发调试的系统以及掌握相关技术的工程人员，这主要是软件成本。这个方案未来的前途如何取决于ARM的发展，如果ARM最后一统天下，掌握ARM相关技术成了每一个搞嵌入式设计的工程师必备的技能，那这个方案是比较有前途的。当然现在看来，出现这种情况的可能性很大。
我的另外一个考虑是，现在用DSP，系统中不用FPGA的可能性很小，而FPGA是不但可以支持各种接口转换，更重要的是在FPGA中可以做一个小的CPU出来（当然也可以在其中做出DSP，但考虑性能价格比，那不是我们考虑的范畴），在这个小CPU中跑个小OS来做任务调度，又如何呢？嵌入式设计工作现在离不开FPGA/CPLD，未来更是可以肯定的预见不能离开，那么为什么不考虑用IP核的方式来支持OS呢？这样还可以完全根据系统需求来订制。现在100万门的Spartan-3也就12美刀，完全可以考虑呀。
很高兴和两位在这里讨论问题，希望更多一些交流。 |
|
|
|
|
|
|
- UID
- 157066
- 性别
- 男
|
两位,
如果抛开具体应用,只从技术层面分析,我也是同意eDSP的观点的.分析得比较透彻.
而且我也可以举例子,在VIA Telecom的3G基带处理芯片中,采用的是1*ARM7+2*OAKDSP+peripherals结构,可谓典型得很.
但关键是我们如果做成硬件平台+软件中间件,必须要仔细分析需求,并不能假设客户都能掌握ARM,并且愿意去掌握. C51+DSP阵列也可以考虑啊...
呵呵. |
|
|
|
|
|
