TI中文支持网情况是这样子的：硬件使用OMAPL138+射频，使用DSP内核控制MCBSP解析射频过来的数据，MCBSP每5ms产生一个EDMA中断，在中断中发出消息，用任务处理MCBSP收到的数据，在CCS环境下可以正常执行，解析数据，滤波这些操作都在2ms之内就完成了。
现在改为了用linux的平台的，这样就把dsp的输出格式从coff改为elf格式了，存储空间分配，DSP的频率，SDRAM的频率，dsp的cfg文件的配置都没有改变，只是在linux的环境下用ti提供的软件引导.out文件，虽然mcbsp依然能产生5ms的中断，但是解析数据，滤波这些操作需要15ms时间了，这样就造成了处理不过来，导致发送消息的速度大于接收的速度，会丢很多消息，处理就不正常了。
特别说明：一开始觉得两个环境下处理速度不一样，所以在两个平台下作3MBYTES的SDRAM内存空间相互拷贝，测出来的速度是一样的，这样可以说明指令处理速度都是一样的；5ms内的解析和处理只调用了TI提供的dsplib一个函数库，TI提供了coff模式和elf的格式库，这个是官方提供的，应该不会影响到运行速度的。
疑问：简单的一个没有调用库的两个函数的处理，处理之前和之后都调用硬件关闭中断功能，然后用gpio拉电平测量处理时间，在bios模式下只花了120us时间，但是在Linux模式下就需要2ms左右的时间，看了论坛里面TI工作人员的解析，只要不改变CCS编译属性的配置，只是把输出格式改为ELF，不会影响到运行速度的。但是编译出来的.out文件尺寸差别很大，COFF格式是4M，ELF格式为11M，请大侠分析分析。
PS：还有一个现象，在BIOS下面系统定时器时间很准的，但是在LINUX平台下系统定时器时间也不准了，本来20ms的定时只有几个ms了，调用的都是库代码，应用代码都是一样的。
bingliang chen：
最新调试进展：一直在怀疑是不是输出的格式不一样会有不同的ccs5.3的属性配置不一样，针对这个做了一个小的测试，讲5ms消息收到之后的处理函数单独摘出来，里面的实现就是800个点的运算，没有用到函数库，只有800个点的内容拷贝和float格式的减法和乘法的运算，就是这些运算for循环800次。
将这个函数第一次放在创建的线程里面运行，用while(1){led_on(); process();lef_off();process();}就是这样子的运行，process();函数运行完需要2ms；第二次将这个while(1){led_on(); process();lef_off();process();}就放在工程的main{}第一句话，不放在线程里面，相当于不初始化任何操作系统的东西，就是用Linux引导了一个while（1）死循环，这样测试出来process()；的执行时间只需要120us，120us这个结果就是我想要的值。
其实Linux的功能就是引导一下dsp的.out文件，dsp还是跑在实地址模式下面，调用的接口也是一样的，只是将TI的库文件对应的从coff格式改为elf格式而已，但是这个process（）；函数里面根本也没有调用库文件，是不是任务调度出现问题了（但是这个任务调度跟不用linux引导的任务调用函数是一样的，都是用的SYS/BIOS的接口）？
Denny%20Yang99373：
回复 bingliang chen:
感觉现在就是怀疑是否是LINUX引导造成的这个问题，可以改用CCS JTAG来引导DSP的程序，看看有没有区别。
