| 查看: 169 | 回复: 1 | ||
| 【奖励】 本帖被评价1次，作者sdlj8051增加金币 0.5 个 | ||
| 当前主题已经存档。 | ||
[资源]
[转贴]真情分享!(BlackFin相关，其它平台也适用)
|
||
|
在BlackFin上面关全局中断其实是很麻烦的事.它不是清除或者设置一个全局中断使能位,而是把core中断屏蔽寄存器所有位都清成0,这个时候你需要设置一个变量来保存以前在core中断屏蔽寄存器中的值,以便后面恢复，这里我给出前段时间写的两个函数。由于BlackFin的特殊硬件结构，只要你想，可以优化一下它，使用能并行执行的指令。 static inline void disable_interrupt(void *ptr) { asm("P0 = R0;"  ; asm("CLI R0;" ; asm("[P0] = R0;" ; } static inline void enable_interrupt(void *ptr) { asm("P0 = R0;" ; asm("R0 = [P0];" ; asm("STI R0;" ; } 另外，在系统设计中，我们经常会用到memcpy函数，尤其是在管理循环缓存时（这时可能就没有DMA能给你使用了，呵呵！）。移动的数据量很大，这时高效率的memcpy就很是重要了。对于SDRAM-->SDRAM的数据搬移，当需要memcopy函数传输超过35个字的时候，先把SDRAM中的数据搬到L1中暂存，然后搬到目的SDRAM中，这样效率会更高，这里我提供了一个在C语言级别优化memcpy函数的例子： void *memcopy(void *dest, const void *src, int size) { #define L1_BUFF 2048 long temp_array[L1_BUFF/sizeof(long)]; while(size/L1_BUFF){ memcpy(temp_array, src, L1_BUFF); memcpy(dest, temp_array,L1_BUFF); size -= L1_BUFF; } memcpy(temp_array, src, size); memcpy(dest, temp_array,size); return dest; } 熟悉C的都知道，定义的局部变量数组是在堆栈里面分配内存的，另外为了函数调用和中断的快速上下文切换的快速效率着想，堆栈一般是放在CPU内部的sram里面的，访问速度是core clk，所以temp_array就是在sram里面分配内存的。在使用循环缓存的管理函数的系统中，调用memcopy函数的函数一般都是比较靠顶层的函数，所以你使用了这个函数也不会对你构建的系统的堆栈空间提出更多的要求。（例如我前段日子做的MP4播放器，就几乎没有影响到原来的堆栈空间的size）。下面我来说说这段程序的设计原理： 有BF533硬件参考书的人可以翻到7-11的表，说到：16-bit SDRAM——>L1 Data memory的搬移n字的数据需要n+14个系统时钟周期，而反过来搬移n个字需要n+11个系统时钟周期，SDRAM——>SDRAM n字数据搬移需要10+（17n/7）个系统时钟周期。看到这里大家可以发现，SDRAM到SDRAM的n个字的数据搬移比L1到SDRAM和到L1的数据搬移同样n个字所花的系统时钟周期的总和还多，这样我们可以很方便的建立一个不等式： （17/7）n+10 > 2n+25 得n > 35时，对于SDRAM至SDRAM的数据搬移，改成先SDRAM至L1，然后L1至SDRAM的搬移效率会提高一些。这是理论值，实际的有些偏差。 为什么会出现这种情况呢？感兴趣的可以去查看SDRAM的原理中的突发模式，这里我就不多说了。下面给出我的测试数据： CCLK=594MHz，SCLK=118.8MHz 在传输10000字节时memcpy函数花费的时间是memcopy的1.92倍； 1000字节时为1.12倍，传输10000字节时更是在2.28倍之多。 可见熟悉了硬件原理，优化真的就是无止尽！ |
回复此楼» 猜你喜欢
材料/农业专业，07/08开头均可，过线就行
已经有4人回复
-
327求调剂
已经有5人回复
-
361求调剂
已经有3人回复
-
一志愿中南大学化学学硕0703总分337求调剂
已经有5人回复
-
一志愿北京化工大学 070300 学硕 336分 求调剂
已经有6人回复
-
材料专业求调剂
已经有10人回复
-
341求调剂(一志愿湖南大学070300)
已经有5人回复
-
0854 考研调剂 招生了！AI 方向
已经有15人回复
-
384求调剂
已经有6人回复
-
生物学学硕求调剂
已经有4人回复
简单回复
sinapdb2楼
2007-01-07 20:41
回复
