優化有很多方法，主要是看你代碼的結構以及指令的類型：
如果你代碼有較多的地址訪問，讀取常量數據，那麼將代碼複制到 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)