DSP編程技巧之31---答疑解惑哪家強(qiáng)之（6）

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

　　35. 雖然可用的存儲空間看起來比section的長度要大，但是鏈接器為何提示“placement fails for object”?

　　這種情況一般是因?yàn)槎蔚目臻g的分配是并不是我們想象中的連續(xù)的一個(gè)緊挨一個(gè)，而是被編譯器給“分塊”管理了。在內(nèi)存地址分配時(shí)，一個(gè)段需要完全適配到頁(page)中，或者從頁的邊界開始連續(xù)分配;為了滿足這個(gè)要求，段在分配到頁中時(shí)，可能無法完全利用某些頁，導(dǎo)致內(nèi)存地址中產(chǎn)生了間隙(hole)，使得實(shí)際所需要的內(nèi)存空間超過了根據(jù)變量大小計(jì)算出來的理論值。編譯器這樣做的目的是為了優(yōu)化數(shù)據(jù)頁(DP)寄存器的加載，達(dá)到減小代碼尺寸和優(yōu)化程序性能的目的。例如，針對一個(gè)數(shù)組，如果數(shù)組的長度小于64字(words)，則編譯器僅需安全地加載DP一次就可以訪問數(shù)組的全部元素;如果數(shù)組長度大于64字，則在訪問每64字的數(shù)組元素時(shí)，編譯器僅需加載一次DP，當(dāng)然如果訪問多個(gè)64字的數(shù)組元素則仍需要多次加載DP。

　　舉例說明：

　　在cmd里定義：

　　RAMM1 : origin = 0x000400, length = 0x000400 /* on-chip RAM block M1 */

　　commbuf : > RAMM1 PAGE = 1

　　在main.c里定義以下幾個(gè)變量

　　#pragma DATA_SECTION(sendT, "commbuf")

　　Uint16 sendT[260];

　　#pragma DATA_SECTION(receT, "commbuf")

　　Uint16 receT[260];

　　#pragma DATA_SECTION(CntPPR, "commbuf")

　　Uint32 CntPPR[250];

　　表面上共需260+260+250*2=1020，commbuf正好放得下.但ccs提示空間不夠：

　　(run placement fails for object "commbuf", size 0x474 (page 1).

　　Available ranges: RAMM1 size: 0x400 unused: 0x400 max hole: 0x400)

　　產(chǎn)生錯(cuò)誤的原因是根據(jù)DP加載的原則，page被劃分為64word的小單元，而數(shù)組被存儲在連續(xù)的、整塊的單元上，未使用到的空間不會(huì)再分配給其它數(shù)組或者變量使用。所以16位260長度的數(shù)組實(shí)際占用了64*5=320 (64*4=256<260)，32位500的長度實(shí)際占用了64*8=512，占用的總長度為：320*2+512=1152=0x480。

　　按照CCS的提示，commbuf占用空間是320*2+500=1140=0x474，但是事實(shí)上32位數(shù)組占據(jù)的最后那個(gè)page已經(jīng)無法被別的變量使用了，所以如果還有新的變量出現(xiàn)的話，會(huì)提示RAMM1塊缺少的地址更多。

　　根據(jù)我們的需要，可以在每次之間內(nèi)存讀取操作之前都加載DP，這樣就可以禁用上面的“分塊”管理特性了。這樣做雖然可以減小內(nèi)存地址空間中的“間隙”，但是每一次訪問內(nèi)存都需要加載DP，反而大大地增加了代碼的尺寸，實(shí)在是得不償失(看起來很少有人會(huì)這么做)。我們可以通過啟用編譯器的-disable_dp_load_opt，或者叫-md選項(xiàng)來實(shí)現(xiàn)這一方法。

　　確認(rèn)某個(gè)段是否被編譯器給分塊管理的方法就是使用.bss和.usect指令，具體內(nèi)容請參考http://www.ex-cimer.com/article/263821.htm。

　　36. 鏈接器提示“placement fails for object '.text'”，我們?nèi)绾螢?text分配更多的內(nèi)存?

　　.text段中包含包含所有可執(zhí)行的代碼，以及編譯器編譯產(chǎn)生的常量。如果我們的代碼比較大，超過了cmd文件中默認(rèn)分配的空間，則.text無法適配到內(nèi)存空間中，就會(huì)產(chǎn)生上面的錯(cuò)誤。通常有三種方法可以來為其分配更多的空間。

　　方法一：修改cmd

　　這個(gè)我們已經(jīng)提到過，請參考http://www.ex-cimer.com/article/256732.htm。

　　方法二：分割.text，把它平均分配到多個(gè)內(nèi)存區(qū)域中

　　這個(gè)方法比較直觀，前提是幾個(gè)內(nèi)存區(qū)域的總長度要滿足要求。例如：

　　.text : >> FLASHA | FLASHC | FLASHD, PAGE = 0

　　方法三：完整分割法

　　這個(gè)名字有點(diǎn)古怪，它本質(zhì)仍然是把.text分割，目標(biāo)區(qū)域也可以有多個(gè)，但是當(dāng)?shù)谝粋€(gè)區(qū)域就滿足要求時(shí)，則只把它分配到第一個(gè)區(qū)域中，剩余的目前區(qū)域?qū)嶋H上未被使用到。

　　在實(shí)際編程實(shí)現(xiàn)時(shí)，這些方法仍然存在一定的限制，包括：

　　1. 在包含控制律加速器CLA 的Piccolo器件中，只有特定的內(nèi)存區(qū)域可被CLA所使用。

　　2. 在含有DMA的器件中，并不是所有的內(nèi)存都可被DMA所訪問。

　　3. 一般情況下，SRAM都是單個(gè)機(jī)器周期內(nèi)只能訪問一次，但是0等待狀態(tài)的。但在一些器件中，程序內(nèi)存控制是包含等待狀態(tài)的，例如在某些2833x器件中，DMA可訪問的數(shù)據(jù)空間是0等待狀態(tài)的，但是程序控制是1等待狀態(tài)的。這些SRAM空間更適合純數(shù)據(jù)訪問類型的使用。

　37. 在cmd文件中，可以把連續(xù)的Flash模塊組合為一個(gè)整體的區(qū)間嗎?

　　答案是可以的。在Flash的燒寫中，可以在同一時(shí)間被燒寫的Flash的最小長度被稱為扇區(qū)(sector)，所以通過把我們的代碼進(jìn)行分區(qū)燒寫，就可以把它們對齊到扇區(qū)。

　　Flash模塊結(jié)合的方法一：直接合并法

　　以把兩個(gè)Flash扇區(qū)組和為一個(gè)段為例：

　　合并前，兩個(gè)扇區(qū)的定義是：

　　MEMORY

　　{

　　//

　　// Individual sectors E and F called out in the MEMORY description

　　//

　　...

　　FLASHF : origin = 0x310000, length = 0x008000 /* on-chip FLASH */

　　FLASHE : origin = 0x318000, length = 0x008000 /* on-chip FLASH */

　　...

　　}

　　合并之后的Flash區(qū)間為：

　　MEMORY

　　{

　　//

　　// Sectors E and F merged into one in the MEMORY description

　　//

　　...

　　FLASH : origin = 0x310000, length = 0x010000 /* on-chip FLASH F & FLASH E */

　　...

　　}

　　方法二：反其道行之，把段分配到多個(gè)Flash模塊中，與問答36的方法二是一致的，例如：

　　SECTIONS

　　{

　　.text: { *(.text) } >> FLASHE| FLASHH

　　}

　　38. 在cmd文件中，可以把相鄰的SARAM模塊組合為一個(gè)整體的區(qū)間嗎?

　　答案是可以的，方法與Flash組合的方法一樣。

　　雖然這樣做是完全沒有問題的，但需要牢記SARAM模塊都是單個(gè)機(jī)器周期內(nèi)只能訪問一次的，所以為了優(yōu)化程序的性能，最好把代碼給分區(qū)到不同的物理SARAM模塊中，這樣可以減少大量讀/寫操作中的資源沖突。

　　39. 對于DSP/BIOS的工程，如何了解鏈接的信息?

　　DSP/BIOS 的配置工具生成一個(gè)cmd文件，規(guī)定如何連接所有 DSP/BIOS 生成的程序段，并且默認(rèn)鏈接至所有 C/C++ 語言編譯程序生成的程序段。 當(dāng)從 RAM 運(yùn)行程序時(shí)，可能只需要這一個(gè)cmd文件就夠了。但在當(dāng)從Flash中執(zhí)行時(shí)，很有可能需要生成且連接一個(gè)或多個(gè)自定義的程序段。

　　此外，任何配置片載Flash控制寄存器(例如，F(xiàn)lash等待狀態(tài))的代碼不能從Flash執(zhí)行。我們也許需要從 RAM(而非Flash)中運(yùn)行特定時(shí)間關(guān)鍵函數(shù)來大幅提升性能。 必須創(chuàng)建一個(gè)自定義cmd來處理這些我們定義的程序段?？梢詤⒖糝unning an Application from Internal Flash Memory on the TMS320F28xx DSP這個(gè)文檔，其示例代碼在http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=spra958&fileType=zip。

　　需要注意的是，這些文檔和程序與新版本的CCS中所包含SYS/BIOS并不是完全兼容的。此外，如果我們想使用第三方的操作系統(tǒng)，例如VxWorks、us/OS、INTEGRITY等，則要根據(jù)這些RTOS的特點(diǎn)進(jìn)行內(nèi)存的分配與管理。

樹莓派文章專題：樹莓派是什么？你不知道樹莓派的知識和應(yīng)用