DSP編程技巧之30---答疑解惑哪家強之（5）

　　答疑解惑哪家強?當屬我們EEPW最強。。。接下來繼續(xù)我們的答疑解惑。

　　29. 如果不需要printf()/sprintf()的全部特性，怎么樣才能減小代碼體積?

　　初學者往往使用printf打印“Hello World”這樣的方式來完成第一個DSP編程的程序，這種方法雖然是非常直觀明了的，感覺起來功能也是非常簡單的，但是一編譯結果發(fā)現(xiàn)提示棧的空間不夠，或者有“program will not fit into available memory”之類的錯誤。這是因為標準的printf()/sprintf()提供了非常多的特性支持，造成了在DSP上實現(xiàn)時，產(chǎn)生的代碼尺寸非常大。

　　此時我們可以根據(jù)需要調(diào)整不同級別的格式格式限定符，例如通過鏈接器的選項，我們可以指定--printf_support=full, minimal或者nofloat, full為默認參數(shù)，表示支持所有的格式;nofloat不支持對浮點類型的數(shù)據(jù)的輸入/打印，包括%a，%A， %f, %F，%g，%G，%e和%E，支持其它的字符、定點格式等;minimal：對數(shù)據(jù)格式的最小支持，只包含了不指定數(shù)據(jù)寬度和精度標志的整形、字符型或者字符串，即只支持%%，%d，%o，%c，%s和%x格式。其詳細含義可參考http://m.butianyuan.cn/article/236048.htm。需要注意的是，如果--printf_support使用了不支持的格式，鏈接器并不能給出特定的實時運行庫的錯誤提示，在使用時要仔細檢查。

　　此外，如果不去指定鏈接器選項，我們也可以修改printf函數(shù)默認對應的源程序_printfi.c來實現(xiàn)類似的效果，它的路徑一般在編譯器的庫函數(shù)目錄下，例如ticcsv6toolscompilerc2000_6.2.5libsrc。在此路徑下，有3個printf函數(shù)對應的c程序，它們與鏈接器選項的對應關系如下表所示。

　　由此我們也可以看出，支持全部格式的printf的源程序的大小，達到了最小格式支持下源程序大小的23倍還要多。

　　30. CCS編譯器是否支持任何工業(yè)標準?

　　1) 所有的TI DSP支持的C語言標準：

　　C89 (ISO/IEC 9899:1990，或者叫NSI X3.159-1989)

　　C99 (ISO/IEC 9899:1999). 不完全支持。

　　2) 不支持的C語言標準：

　　C11 (ISO/IEC 9899:2011)

　　3) 支持的C++標準：

　　C++98 (ISO/IEC 14882:1998)

　　C++03 (本質是C++98的bug修復)

　　4) 不支持的C++標準：

　　C++ TR1

　　C++11 (ISO/IEC 14882:2011)

　　5) IEEE-754 (ISO/IEC/IEEE 60559)標準：

　　TI的ARM和DSP的C/C++編譯器支持32位和64位的二進制浮點數(shù)運算，能夠支持IEEE754標準中大部分特性。

　　6) MISRA-C

　　MISRA C是由汽車產(chǎn)業(yè)軟件可靠性協(xié)會(MISRA，motor industry software reliability association)提出的C語言開發(fā)標準，在控制有關的代碼中是非常有用的標準，具體使用方法可參考http://m.butianyuan.cn/article/247057.htm。

　　7) 其它標準

　　在工業(yè)領域中，safety安全特性在一些應用場合中已經(jīng)是要求必須具備的功能了，相關的標準包括IEC61508、TÜV認證等。目前已經(jīng)有一部分包含硬件safety特性的DSP器件了;如果使用軟件來實現(xiàn)這些特性，則目前還需要我們自己來編寫代碼以支持這樣的特征。

　　31. CCS編譯器對GCC擴展的支持如何?

　　GNU編譯器結合GCC支持許多標準ANSI/ISO C/C++所不支持的特性。在開源應用和Linux等開發(fā)中，GCC的編譯器gcc和g++等都被廣泛使用。所以為了保證對GCC工具所開發(fā)的代碼的兼容性，TI的編譯器也支持某些GCC的擴展特性。目前支持的一些特性基本都包含在GCC4.3中，可查看：http://gcc.gnu.org/onlinedocs/gcc-4.3.6/gcc/C-Extensions.html。

　　32. 如何了解有關編譯/代碼產(chǎn)生工具的已知問題，并獲得最新進展?

　　老外喜歡用IBM的ClearQuest系統(tǒng)來報告bug并分享解決方案，我們可以使用TI提供的開放鏈接https://cqweb.ext.ti.com/cqweb/#/SDo-Web/SDOWP&format=HTML&version=cqwj來報告bug、查看/分享解決方案等，其界面如下圖所示：

　　避開老舊的“傳統(tǒng)”bug的最好辦法當然是定期升級編譯器和開發(fā)環(huán)境了。通過配置，新版本的CCS在啟動后會自動檢測升級并自動升級，這也簡化了我們對開發(fā)環(huán)境的維護工作。

　　33. 鏈接文件中包含那么多個段，有什么快速識別的方法?

　　把下面這個例子記牢就好了：

　　//

　　// Global variables x & y ==> .ebss

　　// Initial values 2 & 7 ==> .cinit

　　//

　　int x = 2;

　　int y = 7;

　　void main()

　　{

　　long z; // Local variable => .stack

　　z = x + y; // Code => .text

　　}

　　34. 為什么我們需要鏈接文件.cmd?為何編譯器不能自動分配存儲空間并進行內(nèi)存管理?

　　在操作系統(tǒng)存在的情況下，這些工作確實不需要我們花費太多的心思。但是在嵌入式的DSP處理中，這樣做的主要原因是處理能力和存儲空間是十分有限的，必須要我們進行一定的介入，例如我們需要考慮的因素包括：

　　1) 運行速度：在RAM中比在Flash中快，在Flash中又比在外部存儲器(使用XINTF)中快。

　　2) 代碼是否需要存儲在非易失的存儲器中(例如Flash)?

　　3) 任務是否是時間關鍵的?例如需要把某個時間關鍵的ISR被保存在Flash中，然后運行時復制到RAM里。

　　4) 一些RAM可被DMA模塊所訪問，而另一些則不行。

　　5) 使用單獨的物理RAM模塊來避免資源的沖突。例如，在C2000 DSP中，RAM模塊都是在單個機器周期內(nèi)只能訪問一次的SARAM(Single-access RAM)。

　　6) 資源是否位于外部存儲器中?

　　7) 代碼是否需要保存在包含緩存或者預讀的存儲器中以提高性能?在C2000DSP中，我們幾乎見不到緩存或者預讀的概念，它們一般出現(xiàn)在包括ARM處理器的器件中。

　　8) 存儲器在程序空間、數(shù)據(jù)空間中是否具有等待狀態(tài)?

　　9) 是否有需要被代碼安全模塊CSM所保護的代碼?CSM并不能保護所有的代碼空間。

　　以上這些因素，在我們編程時也是需要特別關注，甚至是較為頭疼的事情，顯然讓編輯器去自動實現(xiàn)它們，在目前階段是不可能的(除非編譯器的算法有一天能實現(xiàn)一定程度的人工智能)。所以在現(xiàn)階段，我們需要使用鏈接器命令文件cmd去描述每個段所需要使用的內(nèi)存情況。

　　如果我們沒有把某一個特殊的或者自定義的段給指定到特定的存儲空間中，則此時鏈接器會自動把它給分配到一個可用的存儲空間里，這有可能會影響到程序的執(zhí)行效果。所以我們要開啟編譯器的-w選項，這樣在在未定義的輸出段被創(chuàng)建時，開發(fā)環(huán)境的控制臺窗口中會產(chǎn)生相關的警告信息。