DSP与数据转换器协同工作所必须考虑的10大因素

数据转换器针对所用的数据采用不同的格式。有的使用标准二进制(即无符号二进制)数据类型，有的则采用带符号的二进制数据类型，这就是问题的复杂所在。如果有一个 12 位数据转换器，那么在带符号二进制数据情况下，如何使用将是一个问题。符号位占据最重要的位置，即第"11"位(这里的起始位是第"0"位)。如果将此数据字赋予"c"变量，宽度为"16"位，那么假定"c"符号位为第"15"位。如果从转换器读取的数字为负，那么 dsp 就不能识别其为负值，因为符号位的位置错误。如何解决这一问题呢？第一种方法是在读取数据时进行数据位移。不过，这只有在 cpu 读取数据时才有可能，因为 dma 控制器不可能在传输时进行数据位移。另一种方法是在数据块完全传输后在环路中将数据位移至正确的位置。不过这必须使用 cpu，并要求额外的 mips。

如果改变连接后转换器的第"11"位刚好连接至 dsp 数据总线的第"15"位，那么符号位从首位算起刚好位于正确的位置，这就能实现基于dma 的传输，而且也不用再进行数据位移。

确保处理的是正确数据

现在，数据已经进入系统，数据字存储在阵列中，数据大小也合适，于是开始处理数据，但没有获得预期的结果，这时需要思考到底出了什么问题。首先应该检查 dsp 的高速缓存，dma 传输数据进入存储器时是否启用高速缓存，在这种情况下，高速缓存很可能保留拷贝的旧数据，并在算法工作中使用它们。如果发生了此类问题，就必需注意高速缓存相关性与转储清除问题，或者是存储新数据的高速缓存区失效。这样就能确保 cpu 处理的数据是传输完成后的最新数据。

如果用 c 语言编程应分配易失关键字

在调试嵌入式系统时，采用变量查询外设的状态后，发现 cpu 所用变量

值是错误的，这时就要思考到底哪里出了问题。先看看下面这个结构：

unsigned int *pcontrol = (unsigned int *)0x00coffee; file://错误

while (*pcontrol == 0); file://等待一个外部事件

这里的 *pcontrol 指向一个外设。通过 while 循环，期望 eoc 能从"0"转换为"1"。但在大多数情况下，恐怕得一直等下去，因为编译器认为它已经完全控制了变量及与其相关的存储器，只加载 *pcontrol 指向的存储器位置的内容一次，就会对其进行循环测试。但问题在于，由于不会重新读取存储器内容，也就不能结束循环。

解决这一问题的方法就是将 *pcontrol 的声明作一下修改，通知编译器其指向的存储器位置可由外部事件修改，而每次使用该变量时都必须重新载入，如下所示：

volatile unsigned int *pcontrol = (unsigned int *)0x00coffee; file://正确

while (*pcontrol == 0); file://等待一个外部事件

确保采样等距

如果要在频域中处理采样数据，那么还要提到一点：不是所有转换器都有启动新转换的自身时基。在这种情况下，应采用外部时基或 dsp 定时针 (timer pin)