RNDIS和ECM的热插拔问题

　　RNDIS和ECM的热插拔问题
　　最近修复了一波 RNDIS 和 ECM的热插拔通信异常问题，添加了通过menuconfig配置RNDIS delay linkup的配置选项。问题修复点如下：
　　RNDIS：
　　当存在通信链接时 热插拔 Windows会发送REMOTE_NDIS_RESET_MSG，该指令未实现，现已实现。
　　当存在通信链接时 热插拔 eth_tx线程大几率会死等传输完成的信号量通知，导致LWIP卡死。
　　当存在通信链接时 热插拔 eth_rx的接收缓冲未重置，导致接收数据异常。
　　ECM：
　　当存在通信链接时 热插拔 eth_tx线程大几率会死等传输完成的信号量通知，导致LWIP卡死。
　　当存在通信链接时 热插拔 eth_rx的接收缓冲未重置，导致接收数据异常。
　　现已测试stm32f469i-discovery / LWIP2.0.2 / Windows 10 1903下 RNDIS，iperf传输过程中反复热插拔后功能正常， delay linkup宏开启前后功能正常，连续热插拔功能正常。
　　现已测试stm32f469i-discovery / LWIP2.0.2 / MacOS Mojave 10.14.2下 ECM，iperf传输过程中反复热插拔后功能正常。

　　RNDIS全称Remote NDIS 是Microsoft定义的一种USB以太网卡模型，说到RNDIS 必须要说说另一个东西，NDIS。
　　NDIS（Network Driver Interface Specification）是网络驱动程序接口规范的简称。它横跨传输层、网络层和数据链路层，定义了网卡或网卡驱动程序与上层协议驱动程序之间的通信接口规范，屏蔽了底层物理硬件的不同，使上层的协议驱动程序可以和底层任何型号的网卡通信。NDIS为网络驱动程序创建了一个完整的开发环境，只需调用NDIS函数，而不用考虑操作系统的内核以及与其他驱动程序的接口问题，从而使得网络驱动程序可以从与操作系统的复杂通讯中分离，极大地方便了网络驱动程序的编写。另外，利用NDIS的封装特性，可以专注于一层驱动的设计，减少了设计的复杂性，同时易于扩展驱动程序栈。
　　而RNDIS 就是NDIS这种规范基于USB的一种具体实现，RNDIS目前可以在Windows7 or later（讲道理Vista也是可以的）上自动加载驱动，无需第三方驱动。而对于Linux和MacOS来说RNDIS则需要安装第三方驱动了，部分Linux发行版内置了RNDIS的驱动（谁叫Windows用的人多了）。至于Linux Mac 下如何使用RNDIS这里不跟你多解释，因为我提供了另一种解决方案--------CDC-ECM。
　　CDC-ECM（Ethernet Networking Control Model）是USB联盟定义的标准USB以太网控制器模型（很遗憾，Windows下没有驱动），绝大部分Linux发行版和MacOS都支持该种USB设备的驱动。这里讲的绝大多数包括了各种pi，当然如果你自己编译的linux手动剔除了这份驱动就没办法了。

　　如何在RT-Thread上使用这个功能
　　要用这玩意 首先你的RT-Thread bsp得有u***驱动 -- 推荐大家使用下面的bsp或者仿照下面的bsp对STM32F4系列的USB驱动进行快速移植。（超简单）
　　bsp/stm32/stm32f469-st-disco
　　有正点原子 L4 IOT Board的朋友也可以用相关的bsp。
　　大概的操作步骤如下：
　　1） 如果你的bsp的menuconfig有配置USB的驱动加载开关（比如bsp/stm32/stm32f469-st-disco），那么把它打开。
　　这里不是每一个bsp都有此配置，有些bsp直接通过u***组件是否开启来判断是否使用u***驱动
　　
　　2） 把LWIP打开
　　这里必须先打开LWIP才能在USB Device找到RNDIS/ECM
　　
　　3）把RNDIS/ECM打开
　　RNDIS：
　　
　　ECM：
　　
　　4）编译下载插USB。
　　然后你的Windows/Mac/Linux 上就能看到网卡了。是不是超简单。