写了一个协议栈。
上个星期四开始，看了看代码，上了上网。周六周日研究了一下AVR的板子，研究了一下AT指令。
最后发现AVR的板子有问题。
对代码还是一头雾水。
这周星期一换了块ARM开发板，花了一天时间调试ARM的两个串口。
顺便在电脑上写了一个误码率测试的程序。
然后写了一个解析ppp的程序，辅助分析串口收到的数据。
星期一晚上正式开始调试协议。
通宵，基本把ppp协议弄明白了，能够拨上网，睡觉。
星期二下午调通用户名密码验证，请求DNS和本机IP成功。ppp连接完毕。
星期三上午tcp第一次握手成功，后来发现ARM编译器处理高低字节有问题，大幅度修改程序。
对固定ip，服务端有返回第二次握手，而笔记本gprs上网，则不返回。怀疑是校验码算得不对。
找了一堆标准的tcp包，折腾了很久才把校验码凑对，似乎和标准上说的有出入。
然后发送第三次握手，理论上应该连接完毕，但是收发数据没响应。
原因：确认码没填对，服务端认为没收到确认包。
终于晚饭前搞定，能正常收发数据。至此，tcp连接算基本通过。
实际工作才两天而已。主要是ppp调试比较痛苦。网上的资料说得都含糊其辞，到关键地方就略过不谈了。
很多数据项都不知道具体含义。tcp相对就比较简单了，就是确认码和标志位费点代码。
udp还没调，应该比tcp更简单，毕竟没有状态。
总结：
1. 外围的准备工作总是花掉80%的时间。
2. 不懂的时候看书看代码怎么看都不明白。懂了以后怎么看都明白。
比如那本经典的《TCP/IP详解》，个人认为讲述的思路是值得商榷的。
很多类似的协议、标准的数据都喜欢用大段的描述性的文字，而相对很少用表格，尤其是国外的书。
举例的程序段也是调用库函数的程序，看完以后还是一头雾水。其实用到的那个函数才是关键性的东西。
如果我写书的话，会直接把收发的16进制码列出来，然后一层层的剥皮抽丝，分析具体含义，这样绝对
比市面上的书效果好一百倍。
