UDP实现的下板子运行之2

书接上篇。

这篇我们主要抓图一下，展示整个上篇开头所描述的过程。写这篇文字的时候代码已经全部调试通过了，这里只是抓图分析和展示。

 上图，红色框内第一条：板子要给192.168.3.11发送UDP包，但是不知道其物理地址（MAC地址）,就在发送物理地址48个1的局域网ARP广播请求。

红色框内第2条，电脑主机收到这个广播，对比IP是自己的IP，就回复了你要找的192.168.3.11的物理地址是 00.1b...58.

红色框内第3条，板子将32个字节组装成UDP包发给PC。从时间上看，就是PC机发从ARP_REPLY的50uS内，就收到了板子发来的UDP协议。

红色框内第4条，以后每间隔两秒就是收到板子发来的UDP包，这是板子设置的自动发送程序。从上图看，宏观的实验是成功的。

----------------------------

再看看我们发送的以太网数据包。这里电脑只给板子发了一个ARP_REPLY数据包，我们在电脑段用WIRESHRK抓出来，在板子段用内置的逻辑分析仪抓出来，对比一下。

WIRESHARK显示的数据包内容如下：

 而实际从RTL8211EG芯片抓到的数据显示如下：

上图我们看到PHY芯片发出的DV（Data Valid）指示的有效数据中并没有包含前导码和起始字节。

 我们看到截至上图箭头处是没有错误的。 接着往下看觉得有点不对劲了：

这里我们看到明显多了8个字节。我在想应该是芯片的某些寄存器要设置一下能去掉这个8个字节。这里我们可以简单的模块，在数据包尾部，将DV提前8个周期。

 因为我们之前写的VERILOG协议栈在解析ARP数据包时从数据包开头顺序提取信息之后将多余的字节当作校验，同时也暂时没有进行FCS的校验，所以这里是可以兼容这个包的，我们暂时处理(稍后我写代码处理下)，继续往下截图。

--------------------------

接下来查看发送给以太网的UDP数据包是否正确：我们发送段设置一个计数器，发送0-31数字，在WIRESHARK里面看到了这31个数字没有问题。

 下图框内看到32个字节没错。这里看到UDP的CHECK SUM没有被比对（写任何数值都一样），这就有点没劲了：我们在生成UDP的CHECK SUM 时候，因为CHKSUM在头部，而要得到CHKSUM遍历整个UDP包文，所以用RAM块缓冲，消耗硬件资源不说处理起来多了很大延迟，接收方却不领情，直接忽略。这个问题需要继续看看，有没有别的选项或者别的系统设置可以用上这个checksum，如果都用不上，则可以考虑修改代码，不要费力不讨好...

--------------------------------------

我我们看到上述MAC层报文是大于64字节的，没用用到填充，这样就无法覆盖我们MAC_TX代码中填充部分的覆盖。

我们直接设置把下面代码的TEST_LEN设置为4，发送的UDP字节数为4，

 编译运行后再抓包看看：

 看到确实填充到了64字节，是用0填充的，这是习惯的做法。我们换成别的数值玩玩看看？

 这里用'H88填充试试，

 实验OK，这说明我们写全栈代码能控制每个细节，还是很有成就感的。但是实际的应用中大家还是不要标新立异，随大流用00填充。

--------------------------------------------------------------

在空闲期间，PC尝试对FPGA板子的物理地址发送ARP请求，FPGA板子毫不示弱不卑不亢有理有据字正腔圆斩钉截铁地做了回复，如下图。

不知道PC这是什么操作，明明在和FPGA板子通讯说明ARP表里面有了板子IP地址对应的物理地址，还要发起ARP地址转换请求，并且还不是广播的形式发出，非要指名道姓让FPGA板子回复（IP和物理地址都指向板子）。

 这里看到ETHENET 层显示黄色，点进去看应该是咱们自己编写的MAC地址 A1....A6不合规，这小事不必在意。

最后

以上就是狂野服饰为你收集整理的UDP实现的下板子运行之2的全部内容，希望文章能够帮你解决UDP实现的下板子运行之2所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。