※ 引述《niceguy (Enjoy my life)》之銘言： : ※ 引述《kikiow (隨浪逐流)》之銘言： : : 不是的, : : 下給monitor的address,不管是read或者是write都是0x6E : : 讀monitor 回給PC的ACK address是0x6F : : 至於對monitor而言,是讀取資料或者是寫入資料,都是monitor FW在 control : : 另外上一篇我有些寫錯,0x6E=1101110 向左向右shift對那tool而言, : : 指的是最後那bit設為0或1,所以不是C/C++裡面的shift : : 所以要下command就用0x6E(1101110) 要讀回ACK 就用0x6F (1101111) : k大講的正是我疑惑的地方! : 對pc來講 monitor address不論R/W都是0x6E : 我看spec的是source 0x51, destination都是0x6E : 而對monitor reply給pc, source是0x6E, destination是0x6F : 但是chechsum卻是說要用0x50來計算... : (依我的解讀是雖然packet訊號是0x6F, 但事實上卻是0x50??) : 這樣設計是有什麼特殊含意? 看spec並沒有特別說明啊... : 所以我還以為spec的sample code寫錯啊>"< spec沒有錯, address是0x6E,舉例來說通常送進monitor的command會像下列 0x6E 0x51 0x82 0x01 XX CS 然後收到的ACK是 0x6F 0x6E 0x88 0x02 XX .... CS 在PC端收到的資料是從0x6E開始,非0x6F 至於你說到的0x50 spec上是有寫,那是針對收到ACK的command CS計算,為何要如此計算 需要作個小實驗,我才能大致了解..因為當初碰DDC/CI是為了讓monitor的FW可 套在另一個自動化測試AP上,所以必需在PC-->monitor中作了一個小治具去轉換 所以我開發的是小治具的FW,開發時間很短,所以對SPEC細節並無非常深入。 另外說明address作法,定義是0x6E會先往右shift 1bit變成0x37 若要送command 0x37會往左補 0 後開始送,所以command則會變成0x6E 若要讀ACK 0x37會往左補1 所以會變成0x6F --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 219.84.252.238