我在CSDN的第一篇文章

今天是2020年2月4日，立春。
正常来说，如果没有这次春节爆发的武汉新型冠状病毒的疫情，今天应该是正常上班的第二天，然而现在已经是我没出家门的第6天。
没上班的日子也没有闲着，还好带了一些开发板和模块，一些一直想完成的工程代码终于有时间可以完成。
最近完成的工程主要基于Modbus协议。我的目标是完成一个基于FreeModbus的Modbus TCP+RTU的主从站工程，当然移植的代码会很多参考网上其他程序的。开发板用的是基于STM32F103VE的野火指南者。板载没有TTL转485的电路，手头上没有TTL转485的模块，所以RTU的移植直接用板载的TTL转USB和电脑的Modbus模拟主从站通讯。
至于Modbus TCP部分，STM32F103VE系列MCU并没有集成MAC控制器的外设，因此我的这个工程的以太网控制器使用ENC28J60以太网模块。之前在PLC、DDC里面的一些项目用过基于以太网的设备，在毕业设计的时候也使用过基于W5500芯片的项目，但是对于这些以太网设备的使用都限于在应用层的使用，对于TCP/IP的了解也仅限于表皮。
我是一个喜欢追寻底层的东西的人。工作很多人都跟我说，不要太纠结于底层的东西。我对于这个说法不予置评，个人追求不同。但是我最近一个在一个项目中，项目本来要求使用以太网来组网，控制器开发完成Modbus TCP的部分后，现场又反馈现场并没有架设网线，这时候只能使用以太网转Lora的方式来组网了。当我在调试某厂家的以太网转Lora模块时，发现若用两台电脑模拟主从站时，Modbus通讯正常；当把从站替换成控制器时，控制器和电脑的模拟主站都会报非法的Modbus帧故障。在电脑模拟主站抓取数据时，显示返回帧是帧错误。而控制器这边底层完全封装好，串口的数据流根本无法读取，大大增加了查错难度。这时候找控制器厂家和以太网转无线模块厂家，因为两边的设备单独使用都是没问题的，但是组合在一起的时候就会出问题，两边厂家都说是对方的问题。
后面在无线模块厂家的协助测试下才发现问题出在无线模块在发送超过一点量的数据后会分包发，而控制器是不支持这种分包TCP数据的解析的。所以就会出现主站发出一帧正确的数据帧之后，无线模块对这个数据帧进行分包转发，而从站控制器接收到从无线模块发出的第一个TCP包后，因无法进行分包数据的解析，认为这就是一帧完整的数据，结果就是无法解析Modbus数据，从而向主站发出Modbus帧错误帧。
这个事情过后，我更坚定了要往底层走的想法。控制器开发是应用层工作，当然也有很多人坚持应用开发，也有很不错的发展。然而应用层开发的前提是底层的程序足够稳定。而尽管是一些著名的国际大厂（像这个控制器的厂家就是国际著名大厂），程序还是会有问题的。这个事情也让我意识到当底层完全封装，仅进行应用开发，当遇到问题时根本无从下手，只能依靠别人。
（又说远了。。。）
说回来，这次后面的发文计划
1、基于STM32F1+FreeModbus 的Modbus RTU 从站实现
2、ENC28J60驱动测试（ping测试）
3、基于STM32F1+ENC28J60的LWIP协议栈移植（ping测试）
4、基于STM32F1+ENC28J60+LWIP+FreeModbus的Modbus TCP从站实现。
还有几天就要上班了，发文的计划暂时先这样，我希望在上班之前我最后能完成这四篇博文。我也不知道我后面能不能坚持写下去，也不知道有没有人看，（哈哈我就是一个在CSDN只看不评论的人）。如果上班之后还有时间，我还会完成Modbus主机的移植，在做移植之前我查找资料发现网上很多基于FreeModbus的Modbus主站都是基于操作系统的，所以后面如果我还在坚持写，我会先把从站的裸机程序移植到操作系统上，再在基于操作系统的从站程序上移植主站程序。
好吧就这样