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

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

本文引用地址：http://www.eepw.com.cn/article/266820.htm

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

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

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

　　此外，如果不去指定連結器選項，我們也可以修改printf函數默認對應的源程序_printfi.c來實現類似的效果，它的路徑一般在編譯器的庫函數目錄下，例如\ti\ccsv6\tools\compiler\c2000_6.2.5\lib\src。在此路徑下，有3個printf函數對應的c程序，它們與連結器選項的對應關係如下表所示。

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

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

　　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位的二進位浮點數運算，能夠支持IEEE754標準中大部分特性。

　　6) MISRA-C

　　MISRA C是由汽車產業軟體可靠性協會(MISRA，motor industry software reliability association)提出的C語言開發標準，在控制有關的代碼中是非常有用的標準，具體使用方法可參考http://www.eepw.com.cn/article/247057.htm。

　　7) 其它標準

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

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

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

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

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

　　避開老舊的「傳統」bug的最好辦法當然是定期升級編譯器和開發環境了。通過配置，新版本的CCS在啟動後會自動檢測升級並自動升級，這也簡化了我們對開發環境的維護工作。

　　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?為何編譯器不能自動分配存儲空間並進行內存管理?

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

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

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

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

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

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

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

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

　　8) 存儲器在程序空間、數據空間中是否具有等待狀態?

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

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

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