1. 用c語言能否對DSP寄存器進行位域讀取
這里不是用C語言指令完成的，包括讀取。用的是聯合
請看，
【SciaRegs的定義】volatile struct SCI_REGS SciaRegs;
【struct SCI_REGS的定義】
struct SCI_REGS {
union SCICCR; // Communications control register
... //這里我剪裁了其它部分
};
【union SCICCR_REG的定義】
union SCICCR_REG {
Uint16 all;
struct SCICCR_BITS bit;
};
【struct SCICCR_BITS的定義】
struct SCICCR_BITS { // bit description
Uint16 SCICHAR:3; // 2:0 Character length control
Uint16 ADDRIDLE_MODE:1; // 3 ADDR/IDLE Mode control
Uint16 LOOPBKENA:1; // 4 Loop Back enable
Uint16 PARITYENA:1; // 5 Parity enable
Uint16 PARITY:1; // 6 Even or Odd Parity
Uint16 STOPBITS:1; // 7 Number of Stop Bits
Uint16 rsvd1:8; // 15:8 reserved
};
既然你已經用SciaRegs.SCICCR.bit.SCICHAR=7給這個控制寄存器的低3位賦值，那麼讀取時你可以直接用，比如：if ( SciaRegs.SCICCR.bit.SCICHAR==7 ) ...即可，系統會讀取這個寄存器，你可以按照.all的方式來讀，也可以利用union讀局部位。
2. DSP可不可以用C語言寫
當然可以啦... 只要有編譯開發環境，比如Code Composer Studio，編譯就可以了
3. DSP庫函數cfft32_SCALE、cifft32_NOSCALE、cbrev32分別是干什麼的，最好能給出C或C++語言實現
以上DSP的函數雖然是匯編的，但在庫函數的目錄中有相滑頃關文檔，其中詳細解卜薯釋了C語言的調用規則，還有演算法原理，大部分會有相應C代碼。你可以去目錄中查一下。
匯編是針對DSP進行過優化的，目的是為了實現效率最型讓者大化。
4. DSP的C語言，菜鳥起步，高手幫幫忙；感激不盡
這是非整數的定點計算, 無論加減法, 乘除法, 都需要移位.
5. 同一C語言程序寫進不同型號的DSP晶元，他們結果相同嗎
看看你所用到的功能在這兩個不同型號的晶元說明書里軟體操作上，功能上是否有差別。如果沒有差別，編譯正常 且外圍電路都一樣能正常工作的話，結果電路所完成的功能一般都會相同。只是不同晶元，性能不一樣，執行速度等都有所差別
6. CDSP課程有什麼內容
這個缺睜課程內中搏容還是挺豐富的，比如谷安天下的課程涵蓋了數伏培歲據安全的基礎知識、安全架構、關鍵設計和最佳實踐等多個不同的方面。
7. 關於c語言和dsp編程的問題
這個問題太常見了呀，原因是路徑設置錯了。
進入界面後，選擇OPTIONS--選擇Directories
然後稿氏設置路徑,（以下是我的設置，你參考）
1：INCLUDE文件夾所在路徑，Include directories: E:\散升TC2\INCLUDE
2：Library文件夾所在路徑，Library directories: E:\TC2\LIB
3:OuPut文件夾即文件編譯輸出到哪個目錄下
4：TurbroC程序所在的目錄
最後選擇 OPTIONS下的鍵掘散SAVE OPTIONS即可。一定要SAVE呀。
8. C語言文件中的文件格式*.dsp,*.dsw,*.ncb,*.opt是什麼意思
.DSP：VC開發環境生成的工程文件，VC4及以前版本使用MAK文件來定義工程。
.DSW：VC開發環境生成的WorkSpace文件，用來把多個工程組織到一個WorkSpace中。
.NCB：NCB是「No Compile Browser」的縮寫，其中存放了供ClassView、WizardBar和Component Gallery使用的信息，由VC開發環境自動生成。
.OPT：VC開發環境自動生成的用來存放WorkSpace中各種選項的文件。
去這個網站，裡面有VC開發環境下各種文件後綴的VC6中的文件後綴名的意思。
http://www.21shipin.com/html/95386.shtml
9. DSP中C語言
你好 你的握拍罩問題段鬧賀祥我可以解決 這個10.000L L代表的是長整型long型 32位數據
位數越多可表示的精度越大
10. 對DSP而言，CCS用C語言編程和匯編編程，二者的效率相差多少
我用的是28XX系列的，不知道經驗對你有沒有用，因為不同系列的晶元多少有些差別。
TI提供的庫已經相當可以了，兼顧易用與效率。我當時做過這樣的測試
1. 用IQMATH實現
2. 直接C語言實現
3. C語言優化實現
4. 原生匯編實現
IQMATH的運行周期在1000左右，比方案3快幾十個周期，比方案4慢幾個周期，方案2是10000多個周期。
另外，因為只是單獨測的演算法，匯編之所以快是快在寄存器的使用上，操作數可以直接入寄存器，但是考慮到程序其他部分是用C語言編寫的話，把操作棧的時間也加上，並不比方案1快。畢竟我對TI的匯編吃的也不透。
在編寫上，無疑是方案1提供了最接近C語言風格的實現，幾乎不用考慮ISA方面的問題。
另外對於執行效率，我覺得主要考慮三點：
1.分支的使用
CCS對C語言的優化我沒做過太多比對。其實單從反匯編的結果看，我接觸過的嵌入式開發環境的編譯器都能做出很好的優化。但是幾乎每個編譯器都會在邏輯的優化上有欠缺——它只能對一些顯而易見的判斷條件進行優化，而在寫程序的過程中，我們經常出於易讀性的考慮，或者穩定性的考慮，或者其他的考慮加入幾乎不會發生的分支，這樣的分支判斷會消耗一定比率的代碼段執行效率，視乎代碼段內有用功能的長度而定，越長這個比率越小，越短這個比率越高。
2.一般操作，就是各種賦值操作
在一般的操作上，編譯器的優化已經很令人滿意了，基本上可以作為編寫匯編的範本。我覺得所謂效率能達到90%就是針對這個部分說的。
3.特殊操作，比如對整塊內存的操作，或者是浮點運算上。
在一些特殊的操作上，就要看是否有現成的庫，或者看硬體是否支持。比如對整塊內存操作就別用循環一個位元組一個位元組的搬了。
以上三點都能考慮到的話，相信執行效率方面已經沒有太大的提升空間了。
另外如果你的代碼發生在初始化部分，也就是只在系統運行開始的時候運行一次，那麼優化不優化其實沒有太大的必要，除非你對系統初始化的時間有嚴格的要求。但是如果你的代碼是作為任務要被反復運行的，那就有優化的必要了。
在CCS里有代碼消耗時鍾周期的統計，如果你覺得某段代碼效率低下的話，可以先分段進行消耗時鍾周期的計算，這樣優化比較有針對性。