※ 引述《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