红火火的日子，若有所思

由于Bokee的实在太慢，本博客将正式停止更新，请各位访客访问我的新博客地址。由于此服务器为动态IP地址，有时不能正常访问，出现这种情况时，请稍后再试。

http://hyry.dip.jp/blogt.py?lang=1

在此的留言和评论也恕不能一一回复。

经过一个多月的陆陆续续地开发, HYRY Studio已经初步成型，从昨天9月1日开始进入正式的公开测试运行阶段。这一个多月以来，几乎没有上DSP论坛，没有更新博客。Python和做网站并非我的专长，不过在这短短的一个月的业余时间里面，我也能做出点像样的东西，得归功于Python语言的简单易用而又功能强大。

现在可以通过如下地址访问：

http://hyry.dip.jp - 日本語
http://hyry.dip.jp/index.py?lang=1 - 汉语
http://hyry.dip.jp/blogt.py - 日本語
http://hyry.dip.jp/blogt.py?lang=1 - 汉语

最近网络换成了光纤，不甘心每天就用来看看网页，所以这些天忙着用KARRIGELL在自己的电脑上做一个网站，取名为HYRY Studio。KARRIGELL做开发很方便，看了它自带的几个例子之后，就着手自己写程序
了。经过2个星期业余的努力，已经初步成型。申请了一个DDNS，如果我的电脑开机的话，可以通过http://hyry.dip.jp:8000/jan访问。

C6727项目出现一个小问题：开关按钮在操作的瞬间，它产生的开关声会进入内藏的麦克风，带着耳机听的时候，感觉很不爽。于是想在开关操作瞬间，静音一段时间，这需要开关直接对DSP产生中断，可是原先的硬件设计上，是把开关和DSP的UHPI引脚相连，在DSP空闲时对开关进行轮询。
仔细查了C6727的datasheet，发现C6727没有通用的中断引脚，只能将McASP的AMUTEIN信号通过dMAX向DSP产生中断。而AMUTEIN也没有对应的引脚，它需要通过设置CFGMCASP寄存器来决定DSP的哪个引脚来做AMUTEIN信号。没想到弄一个外部中断这么麻烦，下面就把设置外部中断的完整步骤列出来，以McASP0为例：
1．    设置CFGMCASP0寄存器，这个寄存器决定DSP哪个引脚将作为AMUTEIN的信号输入。例如我选择了CFGMCASP0 = 0x00000001，也就是选择了AXR0[7]引脚。
2．    设置McASP的寄存器PFUNC和PDIR，使AXR0[7]成为通用输入引脚。
3．    设置McASP的寄存器AMUTE的INEN位为0，让McASP忽略AMUTEIN信号。
4．    设置dMAX的Event26(MCASP0ERR)的Event Entry，让MCASP0ERR信号直接对DSP产生中断，这个Event Entry中可以选择向DSP产生哪个中断，我选择的是INT15。这样，AMUTEIN信号会对dMAX产生MCASP0ERR event，再由dMAX把这个event转换为DSP的中断INT15。
5．    开启DSP的中断INT15，并编写中断服务程序。
6．    设置dMAX的DEPR寄存器的来决定中断的极性，即是上升沿还是下降沿产生中断。

在设置McASP过程中遇到一个难解的问题。在XFMT和RFMT寄存器中有XBUSEL和RBUSEL，它们为0时通过dMAX port来访问McASP XRBUF，为1时通过peripheral configuration bus address来访问XRBUF。
简单地说，如果XBUSEL和RBUSEL为0，则所有的XRBUF寄存器共享一个访问地址，例如C6727的McASP0的这个地址为0x54000000。如果XBUSEL和RBUSEL为1则通过相应的寄存器XBUFn和RBUFn来访问。也就说每个XRBUF都有一个单独的访问地址。采用dMAX port访问McASP有个好处，McASP会自动地遍历所有激活的serializers。例如如果DMA需要从serializers 0,4,5,7获取数据，则只需要设置0,4,5,7为输入并激活它们，那么DMA只从地址0x54000000复制，也可以同时获得serializers 0,4,5,7的数据。这样，dMAX的源地址或者目标地址就可以保持不变了。
这次移植C6713的程序到C6727时，却怎么也不能通过dMAX port来输入或输出数据，此问题困扰多日，最终没有解决，只好把XBUSEL和RBUSEL设置为1，然后通过相应的寄存器来传递数据了。幸好这次最多只用到2个输入和一个输出，就算修改dMAX的源地址也不困难。但终究留下些小小的遗憾，真希望日后有机会把这个问题弄明白。

许多声音效果都基于延时，例如合唱（Chorus），回声（Echo），混响（Reverberation）等等。它们共同的特点就是都需要很大的存储空间来保存最近的一段声音片断。以双声道16bit、44.1kHz的声音信号为例，如果要保存最近的0.5秒的声音信息的话，则需要88.2kB的存储空间。DSP的内存通常都是很珍贵的，用来存放声音当然不划算，所以一般都把延时用的声音信号储存在扩展内存中（SDRAM或SRAM）。然而扩展内存的存取速度却比DSP的内部内存慢得多，如果直接通过程序来存取扩展内存的话，将会浪费很多MIPS。这样在内存和效率上就产生了矛盾。
以前我在C5416DSP上实现一个混响效果，每计算一个数据需要对扩展内存进行14次读操作，2次写操作，双声道的混响则需要存取32次扩展内存，一次存取扩展内存大约需要10个DSP时钟周期，这样单单存取扩展内存一项就需要14MIPS。为了减少存取扩展内存所带来的消耗，我决定采用DMA来进行扩展内存的存取。在每次混响计算结束之后，就启动DMA把下一次计算所需要的数据全部复制到内部内存中，并把这次计算的结果保存到扩展内存。然而5416的DMA不能自动地支持这样复杂的复制工作，因此为了完成这32块内存的复制工作，我只能响应DMA中断32次，在每次中断时，设置下一次DMA的源地址和目标地址(最后一次中断只是简单地停止DMA)。由于混响运算全部在内部内存上操作，因此内部内存的消耗也是很大的。我的混响程序每次处理64个数据，因此需要64*32=2048words的内部内存。为了节省内存当然可以把每次处理的数据量减少，然而因为处理一次数据，就得为准备下一次的数据响应32次DMA中断，若减少每次处理的数据量，将会增加DMA中断的频率。结果仍然产生了内存和效率的矛盾。
最近学习C6727，发现它的dMAX的FIFO模式彻底解决了上述问题。它可以在不产生中断的情况下连续地复制间隔的内存块，如果C5416有这个功能的话就不需要相应32次中断了。剔除了中断对DSP的影响之后，减少每次处理的数据量也不会带来额外的负担。
关于dMAX在这方面的应用的详细信息请参照：
http://www-s.ti.com/sc/psheets/spraaa5/spraaa5.pdf
http://www-s.ti.com/sc/psheets/spraaa5/spraaa5.zip

由于是移植以前在C6713上开发的程序，因此工作量不大，到目前为止已经基本实现要求。在dMAX和McASP设置方面遇到不少问题，不过依照CSL的例子和相关文档，倒也不难解决。
这次开发中最大的一个问题就是C6727没有数据缓存，因此它存取SDRAM时的速度就大不如C6713了。我大概测量了一下，存取100MHz的SDRAM所需要的时间大概是On-Chip内存的30-50倍。这样，之前直接在SDRAM上进行的计算都必须修改为在On-Chip内存上执行。由于数据量很大，不能把所有的数据都放在On-Chip内存上，因此需要计算一部分就复制一部分到On-Chip，计算完毕之后再放回到SDRAM。这样修改之后，算法终于能够实时运行了，而且运算速度比200MHz的6713快不止1.5倍，寄存器多一倍的确不一样啊。

最近这个工作是要把以前的6713上的一个程序移植到6727上，本来以为这两个芯片只有两个数字不同，应该差别不大，可是开发过程中却遇到了许多新问题。第一个重要的问题就是从flash自举。

由于6727的EMIF的地址线太少，只有13根，当要对较大的flash存储器寻址时，必须想办法确定地址的高位。硬件设计上将flash的A14-A17与DSP的HD0 – HD4相连。HD0 – HD4 属于UHPI单元，因此在启动之后第一件事情就是将HD0 – HD4设置为GPIO模式。对flash寻址的时候，先设置好GPIO这几根线，然后再读取地址0x9000xxxx中的值。

6727从0x00000000 – 0x10000000的地址空间属于片内ROM，当DSP启动时从ROM中的0x00000000开始运行，这里面有一段程序将自动读取DSP的几根启动配置线的值，以决定采用何种方式载入程序。这个项目从flash启动，当ROM中的程序确定从flash启动之后，它读取flash中的第一个字节的数据（地址为0x90000000），若为0则表示此flash为8bit，若为1则表示为16bit，然后它进行相应的EMIF的配置，接着复制flash中的头1024个字节到0x10000000。0x90000000 – 0x90000400 到 0x10000000 – 0x10000400，然后设置程序指针寄存器到0x10000004开始运行。

放在0x90000000 – 0x90000400的程序就是所谓的Bootloader。它负责把剩下的程序从flash复制到指定的位置，然后跳转到c_int00开始程序的执行。TI提供的Using the TMS320C672x Bootloader文档有这方面的详细介绍。但是其中推荐的启动格式是Application image script(AIS)。这和以前的6713的Boot table完全不同。为了能够识别AIS格式，1Kbyte的程序远远不够，因此TI提供的例子采用了二级启动。先由0x90000000 – 0x90000400这1Kbyte的程序将放在flash中的一个二级启动程序复制到内存中，然后运行这个二级启动程序，它分析flash中的AIS格式的数据，并将相应部分复制到内存中，然后再跳转到c_init00运行。

我觉得这样的程序写起来太复杂了，于是干脆还是用以前的那个boot table格式，和6713的程序基本相同，就是要多注意flash地址页更换的情况。

期待已久的C6727的板子终于到了，C6727果然厉害，同样是300MHz的芯片，C6727看上去大概只有C6713的1/4，且功能更加强大。由于C6727太新，需要升级SD的emulator的驱动程序。可是即使升级了，仍然无法连接，找了半天文档，终于发现说要让XDS510USB emulator正确识别C672x的芯片，必须编辑windows\system32\sdopts.cfg文件，找到EmuFirmware = sdxds510usb_v10_1.out这一行，去掉前面的注释。这样emulator就可以正确连接C6727了。
接下来又遇到一个问题，Build Options下的Target Version最高只能设置到C671x (-mv6710)，看来还得升级，找了半天文档，发现要正确编译C6727的程序，必须使用Code Generation Tools v5.3.0，赶紧上网寻找最新的升级包，升级之后，Target Version就可以设置为C67x+ (-mv67p)了。
C6727的CSL(chip support library)也必须自己下载，此CSL和以前的CSL区别很大，最好不要放在CCS的目录下，我把它直接放在工程文件的目录下了。
C6727的变化很大，例如它已经没有DMA或者EDMA了，取而代之的是DMAX，也没有了McBSP，取而代之的是3个McASP。看来要在这个芯片上实现声音的输入输出还得费一番功夫呢。

在CCS中可以设置多种断点，给艰难的调试工作带来了许多方便。选择Debug菜单下的Breakpoints…选项，就可以打开断点设置窗口。
在Breakpoint type中选择所需要的断点类型，下面详细举例介绍一下我常用的两种断点：
break on data write: 在DSP写数据存储区中的某个地址时中断程序执行。这个在调试缓冲区溢出等BUG时经常可以用到。有时候DSP常常出现一些不可捉摸的错误，很多情况下是因为数组越界，把不该修改的地址修改了。有一次我的程序偶尔会出现CF卡不能读取的错误，经过跟踪调试发现保存磁盘0扇区信息的内存被修改了。由于这段内存只在启动的时候写一次，其后只是读取其中的信息，为了找出是什么程序修改了它，我就设置了break on data write断点。这样当程序被中断的时候，就找到了罪魁祸首。经过一些分析发现原来是一段完全不相干的SRC程序的错误。它出错的时候，正好会改写保存0扇区的那段内存。
Break on Prog read:当DSP读取某个地址的代码（读取程序空间的内容）的时中断程序运行。一般情况下这种断点用不上，因为可以直接在程序旁边设置断点。但是如果程序是放在flash中，则不能直接设置断点了，只能使用Break on Prog read。有一个项目我使用了自己编写的boot load程序，当DSP需要更换自己的程序时，就跳转到flash中执行这段boot load程序，它再根据设置从flash中载入相应的程序。这样DSP就可以不同的功能之间切换，如果把这些功能写成一个程序的话，DSP的内存是装不下的。为了调试这段boot load程序，我大量地用到了Break on Prog read。