优化有很多方法，主要是看你代码的结构以及指令的类型：
如果你代码有较多的地址访问，读取常量数据，那么将代码复制到 RAM 中会有很大的速度提升。 这地地址访问是编译时产生的，比如复杂结构体的使用，将造成大量的间接地址的访问。

如果你代码有大量的计算，特别是浮点计算，以及三角函数等高级代数的计算，那么在一些算法下，想办法，把算法改造成定点整数的算法，这样使速度会加快。 如果代码中，有大量的超函数计算，那么可以考虑查表法，不用调用系统的函数库。

另外就是代码指令优化，分析代码中重复运行比较高的段落，将此段落编为汇编代码，然后手动优化汇编代码，完成代码指令的优化。

使用多种方法，可以达到提升程序运行速度与效率。

一般直接用 Makefile 即可，很少在嵌入式上用cmake。 因为嵌入式开发，是从最基础的硬件寄存器，接口上进行操作，有太多的灵活性，而且依赖的SDK也很少。不需要一个通用的模板。

因为模块初始化的 MAC 地址都是一样的，连接路由器后，路由器根据你的MAC计算出动态分配的地址，也恰好一样了，你修改一个板子的MAC，再连试试看。

段码显示确实没有DEMO，因为段码显示没有标准的显示规范，比如：一个时间LCD屏，计算器的LCD显示屏，音响的LCD显示屏，空调遥控器的LCD显示屏，都是不通用的，显示的图形内容也完全不一致，驱动方法也不一样。

但段码显示原理却很简单，就是显示单元由一个数字或者图案的各段 和 图案 的位组合而成。

因此你可以根据你所接的段码屏的定义，分别划分好每个位，一个位占用一个IO，每个位的一个段占用一个IO，这样控制IO的输出波形从而达到显示的目的。此时支持把IO复用为GPIO输出态即可。

举例，一个4位数显的段码屏，每个为由一个8字加小数点组成，则占用8个段的Io。有4位数，则再占用4个位IO.

通过动态输出的方式，输出每个数字，比如给第一个位输出低电平时，同时输出段的电平，然后停留一段时间（一般20毫秒），然后给下个位输出低电平，其它位高电平，同时输出这个位的段电平。。。。依次类推，完成4个数字的动态的输出，反复的来回扫描输出就完成了数字的实时显示。由于LCD液晶具有残影保留和视觉的停留性质，感觉4个数就同时显示出来了。

WIFI 通信信道受干扰，或者距离太远，都会使连接中断，连接中断socket也就断了。

wifi 连接是不可靠连接，你要在应用层，加上心跳检测，断线重连的机制，才能保证业务通讯可用性。

这是在你路由器上做个设置就可以了，路由器一般使用 DHCP 方式，即动态分配地址，给连上的客户端动态的分配地址。 你也可以改为静态地址分配方式，使用 MAC地址与IP固定绑定的方式。 这样客户端每次连网后的IP都是固定的了。

建议你用一个单独的路由器来做实验，不然影响你全网的地址分配策略。

以你 makefile 为基地址，检查 user_gpio.h 所在的目录，是否在 include 的参数里，不在的话，加进去。
另外要注意加的位置，如果加进去，还不对，那就把它提前放置。

先用 t-scan 扫描周边可用网络，
用户输入的时候，如果输入的字符串不在扫描返回的 ssid 列表里，就提示 "输入的ssid 不正确"

如果输入的 ssid 正确，使用 t-connect 联网，但连不上网，那就提示 "输入的密码不正确"

Flash用户参数保存在 flash 中，可以规划特定的区域。
如果硬件可以自己修改，那么可以考虑增加单独的存储芯片，来存储用户参数.

TLS_CONFIG_UDP_ONE_SHOT 宏定义在 w80x_20211115\include\app\wm_wifi_oneshot.h 文件里

define TLS_CONFIG_UDP_ONE_SHOT ONESHOT_ON

t-oneshot 是使用UDP配网，板子向路由器发起底层的组播，附近的所有wifi 热点都会收到这个消息。
这时需要一个手机客户端同来来回应这个组播，客户端上输入这个热点的 ssid 和 密码，通过回应主播传给板子，板子再使用收到 ssid 和 密码来连接 AP
当板子连上AP时，手机客户端也会显示所有连接成功板子的mac地址和ip了。 后面手机客户端就可以跟板子通讯了。

这个客户端，OneShotConfig_2.0.0.apk ,只有android 版本，需要的自取：

链接: https://pan.baidu.com/s/1pdkkDXCjsRn67E94eZ9HMg
提取码: uieb

因为串口收发数据，没有开始结束的标志。 因此发送一段命令，是否结束，需要靠解析命令的格式来进行。这也就是为什么很多 GPS，GPRS，4G 通信模块 使用 AT+ 指令的接口，AT就是一个命令的开头，按一定的格式，来判断是否接收到了完整的命令，这种常使用 ASIC 编码通信。
还可以通过时隙来判断，比如，收发端约定，两个命令间隔必须大于 0.5 秒，那么只有超过0.5秒时，才去判断指令是否发送完毕，这种模式一般跟第一种一起用。因为很多链路不保证通信速率，因此可能造成通信延迟。
这也就是很多 AT 指令设计了回应口令的机制。即，发送端发送一个命令后，接收端如果接收完整，那么回应一个OK，发送端如果没收到这个回应，那么发送端将尝试重发....
另外可以通过，在指令前后加一个校验，比如包格式，内带长度，CRC, CHEKKSUM 等信息，来校验指令的完整性，这个一般用在可靠性要求高的通信上，常用二进制数据通信。

这样，通过通信过程的控制个约定机制，来保证发送数据的完整和可靠。

我在公网搭建了一个 websocket 的服务，开发板可以与它通信，通过业务层协议，可以实现多个开发板间的通讯，开发板一对一，开发板一对多，对网页客户端的多种通信模式。

网页客户端地址：
http://111.229.119.117/w80x/websocket.html

开发板连接地址 ws://111.229.119.117:8084
IP：111.229.119.117
端口：8084

以上服务为技术研发测试服务，请勿发送无关信息，违者进黑名单 。

不会的。

这是消息发送函数，发消息的数据打包发送到队列里，在队列处理后，会释放的。
具体释放的地方是在这里：

W801\w80x_20211115\platform\sys\tls_sys.c:356

void tls_sys_task(void *data)
{

u8 err;
struct tls_sys_msg *msg;
u8 auto_reconnect = WIFI_AUTO_CNT_OFF;

//u8 oneshotflag = 0;
//u8 auto_mode = 0;
for (;;)
{
    err = tls_os_queue_receive(msg_queue, (void **) &msg, 0, 0);
    if (!err)
    {
        switch (msg->msg)
        ...
        
                         break;
        }
        **tls_mem_free(msg);**
    }
    else
    {

    }
}

}

是它内部的 boot 区程序，在上电时会检测是否有 XMODEM 的 ACK 指令过来，如果有那么就会拉低 PA0 的电平，相当于你按下了 boot 键。于此同时乳沟检测到了 reset 信号，那么就是开始进入刷机模式，即按xmodem协议接收img数据，并且按img的头部的信息写到flash的相应区域。
如果上电时，在一定时间内没有等到ACK指令过来，那么就进入正常启动过程。
总体效果就是免按键进入刷机。

看 tools\w800\wm_tool.c 代码你会明白的。也可以根据这个代码，开发自己的刷机程序。

W801 可以使用 wifi 远程升级。
上级方法，先配网，可以用 web配网或者app配网。
配网成功，板子能连互联网后，可以用demo的这个命令来在线升级：
t-httpfwup=(http://xx.xx.xx.xx/WM_W600_SEC.img)

这里给你一个我搭建的测试服务器地址：
t-httpfwup=(http://111.229.119.117/w801_v04.img)