DSP與數(shù)據(jù)轉換器協(xié)同工作考慮的10大因素

假設您接到一項工作任務，設計一套由ＤＳＰ與ＤＡＣ與ＡＤＣ等模擬器件組成的信號處理系統(tǒng)。如果您考慮到幾個重要因素，工作就會非常簡單。下面就來談談設計工作中應該考慮的這幾個因素。

詳細了解應用類型

第一步需要了解應用類型。對于控制型應用，既需要應對突發(fā)的大量數(shù)據(jù)處理情形，也要考慮間歇的閑置狀態(tài)；而對于音頻應用，則需要處理連續(xù)數(shù)據(jù)流的能力。了解應用的具體需求將有助于選擇適當?shù)慕涌诤驼_的數(shù)據(jù)讀取方法。

評估系統(tǒng)速率

第二步需要了解數(shù)據(jù)采樣的速率。舉例來說，音頻系統(tǒng)可能是一部ＣＤ播放機，采樣率為９６ｋＨｚ，也可能是電話語音系統(tǒng)，采樣率僅為８ｋＨｚ。當然，也可能是其他系統(tǒng)，如ＡＤＳＬ質量測量應用，采樣速率高達１０ＭＳＰＳ，或者是稱重應用，每秒只要１６次采樣就足夠了，但要求具備較高的分辨率（如２４位）。了解此方面信息，將有助于開展下一步工作，即選擇正確的ＤＳＰ接口。

選擇正確的ＤＳＰ接口

了解了應用及速率要求后，就對采用哪種ＤＳＰ接口有了一定的認識。大多數(shù)音頻設備均使用特定類型的串行接口，不過高速應用則要求并行接口。當采樣速率為１０ＭＳＰＳ、分辨率　為１２位時，如果采用串行接口，其端口的速率要達到１２０ＭＨｚ才能從轉換器向ＤＳＰ發(fā)送數(shù)據(jù)。這一要求大大超過了大多數(shù)５０ＭＨｚ串行端口的處理能力。若使用并行接口，則總線上信號交換的頻率為１０ＭＨｚ，速率顯著降低，因此處理起來非常簡單。

在選擇接口時，還要考慮的另一問題就是，并行總線能否滿足所需的數(shù)據(jù)速率要求，或者說并行總線芯片在滿足程序與系數(shù)要求后是否已經(jīng)達到了滿負荷。如果是的話，不妨考慮在ＤＳＰ與轉換器之間插入ＦＩＦＯ。

確定握手模式

一旦選擇了ＤＳＰ接口，下一步就要考慮轉換器與ＤＳＰ之間的握手模式（ｈａｎｄｓｈａｋｅｍｏｄｅ）。大多數(shù)轉換器在發(fā)出新的數(shù)據(jù)字之前都會給出某種類型的轉換結束（ＥＯＣ）信號。處理器使用上述信號的方式有兩種：一是輪詢（ｐｏｌｌ）；二是用其作為中斷。

使用ＥＯＣ信號作為中斷具有一定優(yōu)勢，因為ＣＰＵ不會被輪詢標記占用，因此在獲得數(shù)據(jù)前不會打斷ＣＰＵ的正常工作。不過，如果轉換器等待處理特定的協(xié)議來讀取數(shù)據(jù)，比如轉換器發(fā)出轉換結束信號后又需要讀取命令來檢索數(shù)據(jù)，每個讀取命令都會觸發(fā)新的中斷，那么就會造成過多的開銷，得不償失。在這種情況下，輪詢的方法就具有明顯的優(yōu)勢了。

如果中斷時延非常重要的話，那么使用輪詢方式就更具優(yōu)勢。輪詢可確保信號響應速度更快，這比進入中斷服務例程要快得多。如果數(shù)據(jù)檢索有短暫時隙（ｎａｒｒｏｗｔｉｍｅｓｌｏｔ），那么采用輪詢方式也是有利的。

確定傳輸模式

下一步就是實際收集數(shù)據(jù)的工作了。收集數(shù)據(jù)有兩種方法，各有千秋。第一種方法是采用ＤＳＰ的ＤＭＡ（直接存儲器存?。┛刂破鳎墒箓鬏斉c轉換器的轉換結束標記同步，并使ＣＰＵ不用承擔傳輸工作，因為數(shù)據(jù)陣列的填充是在后臺完成的，傳輸完成后再通知ＣＰＵ。

不過，這種方法只有在進行直接傳輸?shù)那闆r下才有效。如果數(shù)據(jù)轉換器在檢索數(shù)據(jù)時需要某些復雜的機制，那么ＤＭＡ就不太有效了。

在這種情況下，應讓ＣＰＵ參與傳輸工作。盡管服從特殊的協(xié)議相當簡單，但必須使用大量的ＣＰＵ資源來收集數(shù)據(jù)。如果中斷率非常高，那么ＣＰＵ可能很難有時間再去執(zhí)行數(shù)據(jù)收集之后的算法了。

是否采用數(shù)據(jù)猝發(fā)

假設數(shù)據(jù)轉換器連接至ＤＳＰ的并行總線，該并行總線在存儲器存?。ㄗx取正在執(zhí)行的數(shù)據(jù)）和Ｉ／Ｏ存?。ㄗx取采樣）之間需要幾個周期的轉換，而且數(shù)據(jù)轉換速率非常高，因此，轉換常常是必需的，幾乎每次采樣讀取都要進行轉換。

如果一步就能讀取多個數(shù)據(jù)字，且不用每次都進行數(shù)據(jù)總線交換，肯定是非常有價值的。在這種情況下，不妨考慮在數(shù)據(jù)轉換器與ＤＳＰ之間采用ＦＩＦＯ。一旦ＦＩＦＯ達到一定的水平即中斷ＤＳＰ，達到一定數(shù)量的數(shù)據(jù)字一步完成傳輸，這就大大降低了總線轉換的開銷。

針對變量選擇正確的數(shù)據(jù)類型

數(shù)據(jù)轉換器針對所用的數(shù)據(jù)采用不同的格式。有的使用標準二進制（即無符號二進制）數(shù)據(jù)類型，有的則采用帶符號的二進制數(shù)據(jù)類型，這就是問題的復雜所在。如果有一個１２位數(shù)據(jù)轉換器，那么在帶符號二進制數(shù)據(jù)情況下，如何使用將是一個問題。符號位占據(jù)最重要的位置，即第“１１”位（這里的起始位是第“０”位）。如果將此數(shù)據(jù)字賦予“Ｃ”變量，寬度為“１６”位，那么假定“Ｃ”符號位為第“１５”位。如果從轉換器讀取的數(shù)字為負，那么ＤＳＰ就不能識別其為負值，因為符號位的位置錯誤。如何解決這一問題呢？第一種方法是在讀取數(shù)據(jù)時進

行數(shù)據(jù)位移。不過，這只有在ＣＰＵ讀取數(shù)據(jù)時才有可能，因為ＤＭＡ控制器不可能在傳輸時進行數(shù)據(jù)位移。另一種方法是在數(shù)據(jù)塊完全傳輸后在環(huán)路中將數(shù)據(jù)位移至正確的位置。不過這必須使用ＣＰＵ，并要求額外的ＭＩＰＳ。

如果改變連接后轉換器的第“１１”位剛好連接至ＤＳＰ數(shù)據(jù)總線的第“１５”位，那么符號位從首位算起剛好位于正確的位置，這就能實現(xiàn)基于ＤＭＡ的傳輸，而且也不用再進行數(shù)據(jù)位移。

確保處理的是正確數(shù)據(jù)

現(xiàn)在，數(shù)據(jù)已經(jīng)進入系統(tǒng)，數(shù)據(jù)字存儲在陣列中，數(shù)據(jù)大小也合適，于是開始處理數(shù)據(jù)，但沒有獲得預期的結果，這時需要思考到底出了什么問題。首先應該檢查ＤＳＰ的高速緩存，ＤＭＡ傳輸數(shù)據(jù)進入存儲器時是否啟用高速緩存，在這種情況下，高速緩存很可能保留拷貝的舊數(shù)據(jù)，并在算法工作中使用它們。如果發(fā)生了此類問題，就必需注意高速緩存相關性與轉儲清除問題，或者是存儲新數(shù)據(jù)的高速緩存區(qū)失效。這樣就能確保ＣＰＵ處理的數(shù)據(jù)是傳輸完成后的最新數(shù)據(jù)。

如果用Ｃ語言編程應分配易失關鍵字

在調試嵌入式系統(tǒng)時，采用變量查詢外設的狀態(tài)后，發(fā)現(xiàn)ＣＰＵ所用變量值是錯誤的，這時就要思考到底哪里出了問題。先看看下面這個結構：

ｕｎｓｉｇｎｅｄｉｎｔ＊ｐＣｏｎｔｒｏｌ＝（ｕｎｓｉｇｎｅｄｉｎｔ＊）０ｘ００ＣＯＦＦＥＥ；ｆｉｌｅ：／／錯誤

ｗｈｉｌｅ（＊ｐＣｏｎｔｒｏｌ＝＝０）；ｆｉｌｅ：／／等待一個外部事件

這里的＊ｐＣｏｎｔｒｏｌ指向一個外設。

通過ｗｈｉｌｅ循環(huán)，期望ＥＯＣ能從“０”轉換為“１”。但在大多數(shù)情況下，恐怕得一直等下去，因為編譯器認為它已經(jīng)完全控制了變量及與其相關的存儲器，只加載＊ｐＣｏｎｔｒｏｌ指向的存儲器位置的內容一次，就會對其進行循環(huán)測試。但問題在于，由于不會重新讀取存儲器內容，也就不能結束循環(huán)。

解決這一問題的方法就是將＊ｐＣｏｎｔｒｏｌ的聲明作一下修改，通知編譯器其指向的存儲器位置可由外部事件修改，而每次使用該變量時都必須重新載入，如下所示：

ｖｏｌａｔｉｌｅｕｎｓｉｇｎｅｄｉｎｔ＊ｐＣｏｎｔｒｏｌ＝（ｕｎｓｉｇｎｅｄｉｎｔ＊）０ｘ００ＣＯＦＦＥＥ；ｆｉｌｅ：／／正確

ｗｈｉｌｅ（＊ｐＣｏｎｔｒｏｌ＝＝０）；ｆｉｌｅ：／／等待一個外部事件

確保采樣等距

如果要在頻域中處理采樣數(shù)據(jù)，那么還要提到一點：不是所有轉換器都有啟動新轉換的自身時基。在這種情況下，應采用外部時基或ＤＳＰ定時針（ｔｉｍｅｒｐｉｎ）。