|--------|   |   |       |
         |   ARM  |-------| DSP板 |       
         |    板  |   |   | 多块  |
         |----|---|   |   |-------|
              |       |
       -------|------总线
              |
         |--------|   
         |   IO板 |        
         |   多块 |  
         |--------|
大家好，小弟现在要实现一个dsp调度任务的系统。采用的是linux操作系统，由arm板总控系统，arm板通过总线和IO板、DSP板进行通信。当然了，DSP板和IO板都可能有多块。系统需要把IO板上的数据交给DSP板进行处理，如果有多个IO任务到来，arm就需要用适当的算法（比如说先来先服务）把这些IO任务分配到不同的DSP板上运行（这个算法由其他人设计）。而我要做的就是想办法把他设计的这个算法，想办法实现在linux系统中。现在小弟我不明白的是这个系统应该使用一个什么样的结构来实现。在这里想请教一下大家如何设计方案来实现它。

这个问题我在网上问过，有朋友回答如下：照你所言，这四个DSP 对LINUX 来说，应该是一个入口，作为一个设备来看，对DSP 的调度，应在设备驱动程序内完成，在设备上建立IO 队列并绑定内核线程，可以用P,V操作实现调度。

由于小弟水平有限，所以有些不明白:IO设备驱动程序和DSP设备驱动程序是否都要写？应该在哪里实现所谓的IO任务分配到DSP板的调度算法？linux内核是如何对这些IO任务进行调度的？是否需要把以上的写成一个模块？或是几个模块？

如果谁能救小弟一命真是感激不尽，也希望大家能够就这个问题讨论一下，给小弟一些启示，谢谢了，如果大家能有看法，也希望大家多说两句，毕竟小弟比较愚笨，谢谢啦，我还会加分的。

一般说来DSP与ARM板通过HPI进行通讯，对于HPI通信，你可以理解为在DSP上有一段内存被映射到ARM的内存地址上来了（这里所说的内存不是真实的内存块，你可以理解为一段地址区域，你可以用一定的方法来读写这一段区域，从而实现与DSP的通信），而ARM板与IO板的通讯，一般都是通过IO口进行的，也相当于读写一段地址区域
理解上面所说的通信，下一步就是调度了，你需要完成这些调度，就必须依据你的具体需求
之所以有些人推荐你采用内核线程的方法，其原因就是让线程切换的开销最小，如果你觉得比较难理解，你完全可以用应用程序通信的思想来解决你的问题

将你的需求可以用应用程序通讯来模仿，现在假设你有九个应用程序，第一个是控制程序，四个是用于处理数据的应用程序，还有四个是用于采集数据的应用程序，现在你要做的是如何最大效率地让四个采集数据的应用程序得到最快的响应，让四个数据处理程序实现负载均衡（不要让某个程序累死，也不要让某个程序闲死），而控制程序与其它程序的通讯用信号加文件的方式，如果你能想出处理的方案，那么这个思路就完全可以移植到你真实的运用上去！！！！

再论另外一个人给你的方案，你暂时可以把内核线程当作普通进程来看，他告诉你用一个控制进程来负责处理IO需求，比如用论询的方法，如果发现一个IO板需要处理数据，就将这个需求放入一个队列中，再开辟一个进程来论询队列，发现队列中有一需求，就取出这个需求，再去查看那些DSP板中有哪一个是空闲的，如果找到一个就将些需求交给相应的DSP，如果都忙，那么就等待，直到有一个DSP空闲为至。到现在还有一个方面需要处理，就是DSP处理后的数据的返回，这个返回数据是由你自己的项目需求决定的，在这里你未提出，所以就不讨论这方面的问题了

结合LINUX来看你的方案，无论是与IO板还是与DSP通信，都需要在内核中进行，在内核中进行有两种方式，一是用户进程通过设备驱动进入内核，二是用内核线程，显然，无论是实现效率还是程序复杂度来说，内核线程都是很好的方式，其实创建内核线程的方法比较简单，具体可参见LINUX内核设计与实现一书，上面有例子，我在这里就不用多说了。需要注意的问题有两点：一是线程间的数据共享，共享的数据应包括两个，就是IO需求队列和向DSP传递的数据。二是线程间的互斥，死锁的防止，这个方面需要结合具体的编程才能说清楚，如果你以前写过多线程的应用程序的话，这方面就应该没有问题

哈哈，有意思，我记得你这个问题的:-)，上次的分好像还没有揭啊！

记忆力不错啊。
这个问题不会，友情帮顶。

小心泄露了研发秘密，这么大量的数据处理，很可能是...
大家都猜猜？

不算