工作需要,用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有问题,惭愧!