开启第3版本TCPnet的Web Server + VNC Server +摄像头远程监控 +SNTP Client连续工作第510天（2018-02-28）
连续上电工作了510天，暂停后期测试，后面有精力做第4版。最后一天测试（2018-02-28）：
第3版测试开启
国庆假期时间过的太快，不过还是挤出两天的时间升级这个Demo。
本次依然是基于Web Server + emWin VNC Server + SNTP Client 三合一系统，不过在VNC上加入了摄像头。
---------------------------------------------
1. Web Serve使用这个：http://www.armbbs.cn/forum.php?mod=viewthread&tid=20096 ，页面基本可以替代TFTP Server和FTP Server。
2. emWin VNC Server 使用外部SRAM虚拟出一个显示屏，除了打点和读点，全部使用DMA方式实现，有效降低CPU利用率
3. SNTP Client就是实现一个简单的从NTP服务器获取时间和日期。
4. TCPnet的实现依然采用事件触发的方式，这样将有效降低CPU利用率。
5. 依然使用NAND Flash记录当前时间，日期，温度以及网线开关情况，这次改动较大，不再使用以前的fopen，fwrite，fclose模式了
这种模式虽然安全好用，但是快速批量写入，每次打开和关闭问题非常消耗时间，所有改成每4分钟fopen，fclose一次，中间时间每2
秒就调用fwrite进行写入，这样效率极高。
http://www.armbbs.cn/forum.php?mod=viewthread&tid=22045
6. 加入摄像头功能，摄像头功能对处理器的性能要求还是很高的，F407的所有总线带宽基本已经占用满了，
（1）首先是摄像头接口要DMA数据到外部SRAM。
（2）本身emWin的实现也是DMA方式虚拟到SRAM里面的，emWin动态内存也是SRAM。
（3）以太网也是DAM方式。
跑起来的时候CPU利用率最高可以飙升到70%。加上DMA的占用，基本F407已经不能干别的，而且使用VNC时，由于F407性能更不上
开启摄像头会有少部分错位。
http://www.armbbs.cn/forum.php?mod=viewthread&tid=22037
7.由于国庆假期时间仓促，没有升级更强劲的检测机制，后面逐渐加入吧。
----------------------------------------------------------------------------------------------
效果
发现的bug反馈：
1.文件记录部分无法下载整个文件了，每次下载仅可以下2MB左右，现在大小已经25MB了。发现还是每次写入就关闭文件比较靠谱。
临时停电：
曾经停机四次。
1. 第1次，停电10秒左右
2. 第2次，停电10秒左右
3. 第3次，停电不到1个小时。
4. 第4次，停电半个小时左右。
重新来电后，依然正常运行，重新获取新的IP地址。另外就是以后将一些重要的配置存到EEPROM里面，以后重新上电
从EEPROM里面加载参数。
第2版测试开启
Web Server + emWin VNC Server + SNTP Client 三合一系统。
1. Web Serve使用这个：http://www.armbbs.cn/forum.php?mod=viewthread&tid=20096 ，页面基本可以替代TFTP Server和FTP Server。
2. emWin VNC Server 使用外部SRAM虚拟出一个显示屏，除了打点和读点，全部使用DMA方式实现，有效降低CPU利用率
3. SNTP Client就是实现一个简单的从NTP服务器获取时间和日期。
4. TCPnet的实现首次采用事件触发的方式，这样将有效降低CPU利用率。
5. 给RTX增加一个CPU利用率的功能。
7. 依然使用NAND Flash记录当前时间，日期，温度以及网线开关情况，这次修改为每2秒记录一次。
8. 这次的测试，只要发现问题，或者对某个问题有好的想法，就关机烧写新的代码进行测试。
下面是emWin VNC Server的效果，用于测试稳定性：
2016/8/3115:51:22 死机一次，从设置的现象来看
timer_task任务
AppTaskTCPMain任务
AppTaskLED任务，这个任务是NAND Flash记录操作。
这个三个任务都死机了
--------------------------
下一次测试考虑将所有任务的运行状态都能够检测到，看看最终是死在那个任务了，或者死在硬件异常。
2016/9/7 12:22:36第2次死机
这几天有时间了，升级一个小版本V2.1，增强下检测机制，看看最终是死在那个地方了，增加看门狗虽然是解决办法
但是不能解决根本问题。目标是让这个系统能够连续运行几个月甚至几年不死机。
2016/9/29 01:32:17第3次死机
准备开启第三个版本的测试。RTC电池应该是没电了。重启板子后又回到最之前的时间了。
--------------------------------------------------------------
第三版要做的工作建议
1. CSV数据里面的数值前面不要显示中文了，方便做数据统计排线。
====================================================================
第1版测试已经结束
1.基于TCPnet的远程Web Server正式搭建起来，开启稳定性测试记录，存储到FlashFS文件系统的NAND Flash里面
2.Web服务器效果在这个帖子里面：http://www.armbbs.cn/forum.php?mod=viewthread&tid=20096
3.给NAND Flash创建文件系统FlashFS，每分钟记录一次时间，温度和网线的断开和连接状态，记录到CSV文件里面
这样直接从Web服务器下载了CSV文件后，用Excel打开就行，查看很方便。
4.服务器可以通过DDNS实现外网访问。手机和电脑端都可以访问。
============
服务器，2016-8-913点40分开始运行测试。
服务已经连续正常运行17天。
服务器于 2016/8/26 11:43:45连续运行17天后死机一次，重启板子，继续让其运行
原因分析：
原因1：
初步认为是获取STM32的RTC的日期和时间，并写入到NAND Flash的环节出问题了，这个环节是由一个独立的任务完成的，
因为进行网线插拔的时候，系统还可以正常的进行插入和拔出识别，说明系统没有死机，而是死机在了某个任务里面。
解决思路：
后面的新版本在这个FlashFS文件系统操作的时候，每个函数都做一个返回值处理。
原因2：
TCPnet死机了，测试中已经无法ping通过
解决思路：
后面的新版本打算支持重新插拔网线后，重新初始化PHY芯片，这样就防止了PHY芯片的死机。
原因3：
PHY芯片过热，死掉了，PHY一旦不通信了，温度立马降下来了。
=========================================
从这个子网页下载CSV文件，当前是存储到NAND Flash的，没有使用SD卡，页面文字未做修改。
系统已经正常运行一天
赶紧出教程 等的好辛苦 期待RL-RTX的系列教程呀。
正在购买18套STM32—V6开发板用于集成产品开发呢，期待着弄熟悉了RL-RTX各个中间件之后，将V6开发板用于更多的产品上。
系统已经正常运行2天
正常运行第3天：
正常运行第4天：
正常运行第5天：
正常运行第6天：
正常运行第7天：
正常运行第8天：
正常运行第9天：
正常运行第10天：
正常运行第11天：
正常运行第12天：
正常运行第13天：
系统已经正常运行14天
能先出个简单例程吗?刚把RTX给移植过来,keil的操作系统真心简单
回 jcx0324 的帖子
jcx0324:能先出个简单例程吗?刚把RTX给移植过来, keil的操作系统真心简单 (2016-08-23 13:30) images/back.gif现在还不打算出，等我对TCPnet的使用和认识都熟练以后就出，要不一旦开始TCPnet的相关例子和教程制作将大大增加我售后的难度，现在论坛和QQ群售后基本都是我一个人。 那能把你的接口共享下不 只用于通信即可, 其他功能用不到 能提供下""ETH_STM32F4xx.c""该文件不? 全部都是操作寄存器,难看 系统已经正常运行15天
系统已经正常运行16天
系统已经正常运行17天
服务器于 2016/8/26 11:43:45连续运行17天后死机一次，重启板子，继续让其运行
原因分析：
原因1：
初步认为是获取STM32的RTC的日期和时间，并写入到NAND Flash的环节出问题了，这个环节是由一个独立的任务完成的，
因为进行网线插拔的时候，系统还可以正常的进行插入和拔出识别，说明系统没有死机，而是死机在了某个任务里面。
解决思路：
后面的新版本在这个FlashFS文件系统操作的时候，每个函数都做一个返回值处理。
原因2：
TCPnet死机了，测试中已经无法ping通过，后面的新版本打算支持重新插拔网线后，重新初始化PHY芯片，这样就
防止了PHY芯片的死机。 用外部SRAM虚拟出来的显示屏效果，除了打点和读点，其余全部使用DMA方式实时性，有效降低CPU利用率。
重新修正的emWin VNC
第二版，第1天运行正常：
第二版，第2天运行正常：
第二版，第3天运行正常：
2016/8/3115:51:22 死机一次 重启继续跑。 第二版，第4天运行正常：
第二版，第5天运行正常：
一直有个疑问，当程序出现问题的时候难道就无法无侵入的连接上调试器然后从调试上获得原因吗
每次上调试器后都会复位，即使不复位也无法看到带反汇编调试信息的内容
回 myxiaonia 的帖子
myxiaonia:一直有个疑问，当程序出现问题的时候难道就无法无侵入的连接上调试器然后从调试上获得原因吗每次上调试器后都会复位，即使不复位也无法看到带反汇编调试信息的内容 (2016-09-02 13:00) images/back.gif
对的，所言极是。
我最近这几天一直在思考一种可以监测长期运行设备的方法，要不这种死机了只能用看门狗复位，但是不知道哪里出问题了。
uCOS的uC/Probe做的不错，可以用JLINK检测，不过JLINK和电脑得一直开着，不方便。
如果能够随时从SWD接口读取信息就好了。 第二版，第6天运行正常：
第二版，第7天运行正常：
第二版，第8天运行正常：