工作需要，用c#寫了一個串口調試的工具。很小比較簡單。功能就是給允許用戶查看當前kernel中的某些SDram,Flash地址的值，以及部分寄存器值。其size如下：
Register: 4 byte
memory: 4 *n byte. 如果n > 1，那麼這段區域即爲map類型。
工具的架構類似於C/S，非常簡單。
kenerl運行的console線程，基於UART驅動，用於與外界通過串口通信。
而PC端則向kernel通過串口發送讀取和保存的命令，進而獲得相應地址或地址段的值以及將用戶設置的值回寫到kernel的地址中。
界面以及所謂握手相關的東西，實在沒有什麼可寫的。c#的界面開發事件委託機制像極了Eclipse中的SWT。
唯一有意思的是窗口通信這一塊：c#有serialPort這樣一個組件，比較方便的封裝了串口的相關操作。
但是在開發測試中發現了一些小問題：
1. 當寫回的內存值塊是 128字節時(參考了XModem協議)，kernel端不能保證寫回的正確。經過很多調試後，發現16 bytes時，工作正常。後來詢問了相關同事，才得知Uart的驅動的fifo深度有限。猜想可能是緩衝的問題造成的。
2. 讀寫小塊數據的時候，工作正常，當碰到幾十k的大段數據時，就會有問題。調試後纔想到，pc端的緩衝區也不是無限大，如果pc只管發，kerneal端只管接，其緩衝必將耗盡。反之也是一樣。有必要加入一些握手的機制。保證其能夠同步發送和接受。
3.誤解了Serialport的read接口，我以爲它是一個阻塞函數，返回是將bytes緩衝區全部填滿。其是加上工作機制大致如下：如果input緩衝區有數據則將其拷貝到bytes中。否則阻塞。但是並不保證能夠讀取read參數中的給定的緩衝區大小的字節數。
這樣如果按我的理解，與keneral端交互的時候，只需調用seralport.read函數，就會得到kernel中的所應該返回的信息。
而調試中發現，bytes中會有很多空值，這樣纔想到可能是read有問題，慚愧！