問題現象如下：
自動搜尋沒有
107.7
這個臺，手動輸入是有這個臺的，而且訊號很好！
問題處理：
首先聯絡
rda的人在底層檢視
rda的**
，發現uint8 rda5802_validstop(int16 freq)
這個自動蒐台函式中
認為107.7
是個有效臺的，狀態位也是正確的，也就是底層上是沒有問題的。
那麼跟到上層，應該還是
mtk上層的演算法有問題，不知道它怎麼把
107.7
過濾掉的，
在這個函式中：
void mmi_fmrdo_preset_list_done(u8 *signal_band) 中有
mtk的乙個演算法篩選，將本來訊號還可以的
107.7
給過濾掉了，這個我們會提
eservice
問一下mtk
具體的原因，
和龍哥跟了很久的**後，也問了一下
fae，先做了以下處理：
for (i = j = 0; i < fm_bandwidth; i++) {
// if (fm_sig_mark(signal_band[i]))
原來的
if(fm_sig_lvl(signal_band[i]))//(i>175)// 107.7
出來,liem修改
這樣處理後
107.7
是能被自動搜尋到的，
這個問題
先做這樣的處理，以後會繼續跟蹤！
另外還說一下那個廢台多少的問題，就是訊號好的地方，都到很多臺，廢台很少，訊號差的地方，搜到的台少，但是還有廢台，
這個問題本來就跟訊號有關。然後廢台這個東西，也是晶元內部做了處理的，一般來講，如果晶元內部處理認為是個廢台，這個臺就不會上報給上層，底層直接過濾掉了。
6410平台上配置WIN CE的DDR引數
win ce系統中配置ddr引數主要有以下幾個檔案，當然ddr的時序引數就不贅述，此處敘述主要是大小和位址引數。1，檔案memparam mddr.inc中 dmc1 mem cfg memory configuration register dmc1 mem cfg2 memory configu...
2410平台上dm9000a網絡卡驅動分析（六）
上面已經分析到中斷處理的接收中斷處理函式，下面分析傳送中斷處理函式。在前面，我們說到系統呼叫dmfe start xmit來進行資料傳送，當資料傳送完成後，將產生乙個資料傳送中斷，由interrupt函式檢測到該中斷後，將呼叫dmfe tx done 進行處理 static void dmfe tx...
在x86 64平台上編譯龍芯平台go執行環境
系統 deepin v20 平台 x86 64 交叉編譯器 mips loongson gcc7.3 2019.06 29 linux gnu，即gcc 7.3.1。待後續更正 wget交叉編譯化境搭建見在x86 64平台上搭建龍芯mips64交叉編譯環境 安裝git sudo apt instal...