健康资讯 曾经80、90后上网必备的QQ PC版，现在真是被腾讯仍在一个遗忘的角落。快2022年了还在用着被全世界都抛弃的Flash技术实现基本的QQ秀、QQ相册功能，哪里有一点互联网大厂的样子。腾讯的技术肯定还是基本在线的，估计是内部不愿意投入资源尽快更新。
国服的Flash软件下载还被国内某流氓公司控制了，自带的FlashHelper.exe这个国产特色进程已经被微软认定为广告软件拦截了[微笑]
QQ小程序也是久久不见支持PC版，连微信PC版都支持小程序了，老大哥却落后了，甚至连为他呼唤的声音都不多，真是落寞。#QQ空间#
我通过以下步骤把网页下载到控制器的内存Flash:
内置编程网页是我们研发的控制器的最大特点。
不管是无线WiFi接口还是有线LAN接口的控制器，我们都自主设计了简易的HTTP服务器。
并把html网页存储在处理器的内部Flash，
我们所选择的处理器具有256Kbyte的Flash,
其中4Kbyte用于存储bootloader程序，100Kbyte用于存储应用程序。
100Kbyte用于远程升级固件时存储新的固件；
剩余的52Kbyte用于存储网页。
因为控制器并没有USB或者SD卡的接口，也没有移植文件系统的代码。
所以网页只能采用自定义协议通过串口通信或者TCP/IP的通信下载到内部Flash。
具体步骤：
1.用delphi设计网页文件拼接、下载的上位机工具。
2.用dreamweaver, notepad++, sumlime等编辑工具设计网页
3.通过上位机工具打开文件选择框选择首页，利用pascal程序编历该文件所在文件夹下的所有.html网页文件以及.js的脚本文件。
4.读出文件计算大小，并加入到一个统一的文件page.bin。
5.对每一个文件记录文件名、大小、以及在page.bin文件中的首地址。
如附图3，ajax.js文件的存储起始位置为0，大小为0x000010da=4314Byte.
将得到的数据存入到page.bin文件中的前1KByte字节中。
6.上位机软件从page.bin中按512Byte为一页读取内容、并指定存储位置通过串口或者WiFi/LAN发送给下位机。
下位机收到命令之后，从中读取存储位置信息，将接收到的网页内容存到指定位置。
7.当用于打开网页时，控制器程序根据接收到的http协议数据解析出要下载的文件名，
根据文件名从前面1024byte的数据中查找该文件名所对应的存储超始位置和大小。
以略小于MTU
比如1300的字节数为一页数据从指定的位置读取网页内容，逐页发送给浏览器.
flash被中国公司收购后，比腾讯，360还无耻。你做广告就做广告。弹出来几秒别人还会自动消失。它就一直杵着。然后打叉的框若隐若现，让你经常点错变下载。我可以去工信部告它吗？
打开自己21年前的电脑，好像又回到了千禧年。熟悉的拨号上网程序，QQ2000，听音乐的winamp，下载的网络蚂蚁，看视频的realplayer，还有各种Flash小视频和游戏。。。#图拉丁# #老照片#
力荐升级！Chrome 88正式版发布下载，CPU占用暴降！
Chrome 87版本之后，时隔多日的谷歌再次送上了新版本，Chrome 88也来了，这次带来了不少的变动，最明显的就是取消了对Flash的支持。
并且在其中也降低了占用CPU的比例，而且额外地增加了1.25小时的续航，整体来看谷歌这次的更新还是不错的。
前几天，用户反馈正常使用的控制器突然无法找到WiFi热点。
客户将WiFi模块-ESP8266寄回给我们分析，我通过esptool.py工具对故障件的flash进行读写等操作，没有发现异常。
通过ESP8266 download tool尝试重新下载固件，提示efuse检查失败。
于是又找到另一条串口线，对esp8266下载工具与模块的通信数据进行抓包分析。
并结合官网提供的固件下载协议逐条解析，以下是模块的应答：
C0 01 08 02 00 00 00 00 00 00 00 C0
C0 01 0A 02 00 01 00 70 B0 00 00 C0
C0 01 0A 02 00 FC 14 00 02 00 00 C0
C0 01 0A 02 00 00 B0 00 BE 00 00 C0
C0 01 0A 02 00 AB 62 24 00 00 00 C0
C0表示数据包的开始和结束；
01表示应答；
08以及0A都是操作代码，08是Sync Frame Send，估计是用于与模块同步，确认模块通过串口正常连接，0A表示读寄存器。
02 00即 0x0002表示数据的body是两个word的数据；
...
这两天，又收集了几片之前客户退回的故障件，读出其中的efuse数据，与正常模块对比如下：
00 00 DA 8A C8 07 00 02 00 B0 00 31 4D FF BC 00(OK)
01 08 75 35 E6 06 04 0A 12 B0 00 31 4D FF BC 00(NG 1)
01 01 EF 34 80 59 00 02 00 B0 00 B7 BE 5B C4 00(NG 2)
03 00 C6 5A FA 05 04 86 66 F0 10 71 7F FF BC 00(NG 3)
01 00 70 B0 FC 14 00 02 00 B0 00 BE AB 62 24 00(NG 4)
可见，故障件的第1、2个字节的efuse数据被改为了非零，导致efuse检验不过。
翻遍了乐鑫整个网站，也没有找到esp8266的efuse的介绍，只在网络上找到关于此的只言片语，说是esp8266的efuse并没有开放。
也没有找到esp8266的其它用户有提到类似的问题。
我的问题是，为什么我们使用时会有比较高的概率出现efuse的损坏。
是因为静电、电磁干扰、过温、还是模块的带电拔插。
有点整不会了。
GD处理器与ST处理器的重大差异，不容忽视！
Flash的擦写速度两者有重大差异，如附图1所示：
GD擦除1页(2kbyte)的时间的典型值为100ms，最大值高达450ms。
而ST擦除1页(2kbyte)的时间的最大值也仅为40ms。
很多人可能不知道，在Flash擦除期间，CPU被挂起，PC指针暂停而不往下执行。
对我们的产品，以其中两个影响为例；
1) 内部Flash当作EEPROM来使用，用于存储一些断电记忆的数据，比如用户的设置值，运行记录等等。
当相关程序需要往Flash写数据时，可能需要先擦除再写入，在此期间，由于程序不被执行，可能导致通信中断，输出时序发生变化，
比如我们设计的可编程控制器，当用户编写的程序为100ms的脉冲。
使用ST的处理器，输出信号的脉宽会概率性达到140ms；
而使用GD的处理器，却可以长达550ms，远远超过用户的设计；
2) 固件下载，按照我们的设计，上位机对控制器进行远程升级时；
首先会发送命令将所有存储固件的区域逐个page擦写成0xffff，
我们预留的存储区的大小为100kByte，共50个page。
使用st的处理器，50个page的擦除时间为2s。
而使用GD的处理器，50个page的擦除时间最长可达22.5s。
我们设计一个简单的状态机，在主循环中逐个page擦除flash，没有任何等待，保证了实时性。
如果使用死等待进行擦除，则应该加上喂狗操作，比如：
看门狗的溢出时间设定为6s，在存储区擦写过程中，没有进行喂狗操作。
当改用GD处理器之后，每擦除一个page，需要喂一次狗，
而且上位机等待超时的时间也应该延长。
凡此种种，需要深入做DFMEA的分析，必要时可以要改用外部的Flash。
今天提车了。。一切都没问题。。只有一个不太舒适的地方。
车机内自带的高德地图，无法更新到最新的5.2.0版本。逛了些论坛也得到了些许答案。
真希望早点适配最新的车机版本。不然只能用手机版本（没有巡航功能）或者下载共存版（最高5.1beta），别无他法。
现在尝试过的办法用。U盘更新、浏览器更新、应用市场更新，都没有用。系统不给更新内置软件。
