知識庫

遭遇到的問題

1 解決問題的方法

在做DSP硬體實作時，常常會遇到許多軟體或是硬體上的問題，甚至是編譯整合發展環境(CCS)的安裝，EVM板子驅動程式的問題。常常是束手無策好一陣子，在看過一些資料，慢慢地把一些懷疑的部分搞清楚之後，也就比較知道怎麼去下手，或是怎麼去詢問有經驗的人。以下我便摘錄我們所遇到的問題。

2 軟體發展上

2.1 軟體寫作時應注意的事項

在寫作軟體程式時，最需要注意的，是要做版本控制，做定期的備分。常常我們改程式，會改到死胡同裡，原來還可以運作得很好的程式，被我們一時之間改得亂七八糟，無法原還。這時，只有仰賴定期的備分，才能跳出原來的窠臼，從原來的方向，再次好好思考如果去修改我們接下來的程式。

此外，最好能做版本控制，在每完成一個有特定功能的程式時，額外再備分一次，說明清楚此版本修改的部分，以及完成的部分，如此一來，整個程式修改過程都能過完整的紀錄下來。一旦中間有了問題，也能夠從較前面的版本去還出原始的面貌。

2.2 Memory mapping

所謂的記憶體，在我們使用程式去撰寫時，是有以功能的不同而分成許多不同的區段的。比如放置程式的程式記憶體或放置資料的資料記憶體。這些區段，我們可以在CCS中，撰寫一個叫做command file的檔案，去描述我們欲分配的記憶體區塊，下圖便是一個command file大致上的樣子

(圖4-1 An example of command file)

(摘自TMS320C6201 CPU and Peripherals)

在我們AMR的程式碼上，總共約使用了320K Bytes，而原有的程式記憶體的位置僅有64K Bytes而已。故我們必須使用EVM板上額外提供的SRAM空間做為我們的程式記憶體。如此的動作即需要撰寫command file去描述我們的記憶體如何劃分，而我們的記憶體欲如何劃分，則來自於EVM板上所提供的實體記憶體分佈情形。

2.3 Heap size

在我們一般程式撰寫時，時常仰賴動態記憶體的使用。所謂的動態記憶體，即是其區塊是可以後來不足時新增，或使用完畢後可歸還的。如此的作用是有其必要性的，例如當我們撰寫一影像處理程式時，我們總是需要一大塊的記憶體區塊作為儲存像素的值。但我們並不知道使用者將會點選幾張圖，一但我們初設的記憶體太少，則不敷使用，若太多，則勢必拖垮系統的資源。此處的解決之即是使用動態配置記憶體。

使用動態記憶體配置時，我們需要注意的是所謂的heap size。此heap乃是記憶體區塊中某一種的section。用來處理隨時可劃分或規還記憶體所用的。一但heap size過小，我們將會配置不到我們所需要的記憶體區塊，如此會產生錯誤訊息。在我們AMR的進行中，原有的heap size約0x500 Bytes，經過實驗我們總共需要0x4000 Bytes的heap才夠使用。

2.4 Wrong header file without message

在我們AMR的移值過程中，發現了一個屬於CCS的bug。即是錯誤的檔頭宣告，並沒有正確的回應應有的錯誤訊息，造成看似不明原因造成的當機。

在ANSI C中，有提供記憶體區塊的操作行為，諸如memcpy()等等，均被歸類在<memory.h>的檔頭中。但是在CCS的整合發展環境中，我們發現到這些記憶體操作函式竟被歸屬於<string.h>的檔頭裡。原來的標準程式碼在CCS編譯過後並沒有產生任何錯誤訊息。但後來將檔案置換後，行為立刻正常。像這樣的情況應是CCS本身的bug所致。