在TI DSP生成.out文件转换为.Bin文件中上传了转换工具，但是有些同学不知道怎么用，今天写个小说明。
在CreateBin文件夹实际是一个转换的例子，包含5个文件，TestC.bat、hex6x.exe、boot.cmd、hextobin.exe、TestC.out。直接双击TestC.bat文件就会生成TestC.hex、Test.map、TestC.bin。
hex6x.exe就是将out文件转换为hex文件的工具，它是命令行的，需要在windows控制台下使用，为了便于应用，我们将其命令行写在boot.cmd文件中，然后通过TestC.bat批处理文件调用hex6x.exe boot.cmd，会根据boot.cmd命令的不同生成不同的.hex与.map文件。可以通过右键编辑通过记事本或UltraEdit编辑。
例子中的boot.cmd文件是针对8位Flash的，如果是16位Flash将boot.cmd文件中的8换成16就可以了。
hextobin.exe是将刚才生成的hex文件转换为bin的工具，也是windows控制台下的程序，我们一样通过批处理调用。
TestC.bat文件也可以通过右键编辑，通过记事本或UltraEdit等工具编译。
前面讲过TI的out转换为bin，其中也说hex转bin，通过VC2005编写了一个hex转bin的工具（点击下载），下面说说hex转bin的方法。
hex文件的格式说明参见百度百科http://baike.baidu.com/view/1229888.htm，文中提到了三类地址
00类型对应的记录地址，
02类型对应的扩展段地址，
04类型对应的扩展线性地址。
可以看出hex文件支持32位地址空间，地址的起地址从0×0000 0000开始，02扩展段地址相当于地址的高16bit，04扩展线性地址相当于段地址，00记录地址相当于段内偏移地址，最终对应的存储器地址=(扩展段地址<<16)+(扩展线性地址<<4)+记录地址。如扩展段地址为0×0001，扩展线性地址为0×1111，记录地址为0×1234，最后的存储器地址为0×00022344=(0×0001<<16)+(0×1111<<4)+0×1234。转换为bin即在存储器位置开始写入数据记录中的内容，注意将ASCII形式的十六进制数转换为数值形式的。
bin文件已经不包含地址信息了，它仅包含从0×0000 0000地址开始往后顺寻写入二进制数字，又由于一般的程序文件不会占用32bit的地址空间，所以此二进制文件的起始地址实际是Flash存储器的段内的偏移地址，只需将bin文件的数据顺序写入Flash即可。
TI公司的CCS3.3开发工具生成的目标文件是.out文件，它是COFF（通用目标文件格式）格式，尽管COFF文件可以直接在TI TMS320C6000芯片上运行，但对于烧写还是不方便。TI CCS3.3提供了.out文件转换为.Hex文件工具Hex6x.exe，可以方便的将.out文件转换为符合Intel HEX标准的.Hex文件。然后此hex仍然不能方便的烧写到DSP中，需要进一步转化为二进制.bin文件，然后更过Flash烧写软件将文件数据顺寻的写入Flash中。为了配合IT的Hex6x.exe文件使用批处理生成.bin，我在VC2055下写了一个命令行格式的HexToBin工具，使得转换一键搞定。
PS：例子中的.cmd文件是控制.out文件转换为.hex文件的。指令了待转换的.out文件的名称，与生成.hex文件与.map文件的名称，以及烧写目标Flash的数据位宽。HexTobin只完成了从Intel Hex转换为.bin文件的工作。
下载.out文件转换.bin文件示例
TMS320VC33是TI经典的浮点运算DSP，是从c3x中演变而来的，具有低功耗，大RAM（与c3x相比），在2000年的设计中使用较多，目前已经停产。就这么个片子把我搞惨了。
首先是原本的程序用C编程，使用File级的优化-03，优化级别最高了，对于代码的分析就有困难了，但原本的程序经过使用验证是没有问题的。现在的工作是需要加入一个CRC校验函数。首先通过VC2005编写一个可以在windows下正确运行的crc c程序，用cc编译后下载到片子上运行，从串口看数据crc校验错，程序有问题。开始怀疑编译器优化有问题，将此文件的优化去掉，还是不对。又怀疑是crc算法效率太低，采用bit移位法计算，改变crc算法，采用查表法，但是不对。
由于完整程序太大，不能在线仿真，所以调试起来很麻烦。最后没有办法，单单将crc函数挂上仿真器单独跑，结果crc错。这么就好找原因了，将每次crc查表的结果printf出来，很快就找到原因了。在程序中查表的位置号用unsigned char变量，crc结果用unsigned short，从中间结果看unsigned char型变量可以达到0×400值，unsigned short可以达到0×1287D0，这crc能校验对才有问题呢？printf sizeof 各种数据类型发现，在VC33中unsigned char、unsigned short、unsigned int、unsigned long int的长度都是1，位长度都是32bit，也就是说在VC33定义的变量类型只是个符号，与内存的分配无关，通常情况在cc下将float赋给int，连个warning都没有。在软件仿真和硬件仿真下都可以验证，这是编译器决定的。找到了原因，在每次运算完之后，根据理想的数据类型，取有效的位数即可（铵位与运算）。
另外VC33的地址空间也是与1字（int）对应的，就是一个地址对应一个存储空间，只是这个存储空间是32bit长。
最早使用ADI的BF系列芯片也没有这样的，到后期使用TI的C6000系列数据类型也是与存储空间严格对应的。
Recent Comments