前言

目前我們討論的這個(gè)問題，并不是說WIFI方案不具備以應(yīng)的功能。而是指在同一個(gè)AT指令固件下可能存在的問題。由于各廠商AT指令的開發(fā)深度不同，導(dǎo)致AT指令固件差異很大。我總結(jié)了一些問題，其中是否存在你認(rèn)為AT指令不好用原因

一、底層庫問題

由于原廠在開發(fā)過程中，會(huì)不斷的修補(bǔ)SDK包中的BUG以及優(yōu)化適配性能，致使你購買到的AT指令WIFI模塊，還停留在以往舊版本SDK包的基礎(chǔ)上設(shè)計(jì)。自然而然你使用的模塊也會(huì)存在以往舊版本的問題。而這種情況在WIFI模塊行業(yè)中特別嚴(yán)重，由于工廠生產(chǎn)的超前性以及庫存的存在，往往你買的AT指令模塊，燒錄的不是基于最新SDK開發(fā)的固件。

二、指令格式無規(guī)律

如果只是單純的指令命令無規(guī)律，這也不是致命的，因?yàn)?a target="_blank">單片機(jī)代碼一但寫成，這部分就不用人腦記憶。但是我指的指令沒有規(guī)律，是指AT指令集回復(fù)結(jié)果的多樣性，根本在數(shù)據(jù)手冊(cè)中無法找全，如回復(fù)AT指令數(shù)據(jù)有大小寫區(qū)分。還有一種情況很糟糕，就是在發(fā)送指令后等待回復(fù)時(shí)，中間夾渣了數(shù)據(jù)內(nèi)容，這大大增加單片機(jī)應(yīng)用開發(fā)者的難度!

三、指令回復(fù)響應(yīng)性

一條AT指令發(fā)出去，回復(fù)的指令時(shí)間間隔忽長忽短。先不說不同指令，就算是同一條指令也有這種現(xiàn)象，單片機(jī)用戶很難找到一個(gè)最長等待時(shí)間去設(shè)計(jì)代碼。一但等待過去模塊又回復(fù)了，這就對(duì)單片機(jī)的邏輯造成影響。還有一些AT指令，在快速輸入指令后，可能會(huì)進(jìn)入卡死狀態(tài)，只有在重啟后可以使用，這種情況多出現(xiàn)在早期版本的ESP8266的AT指令固件中。

四、指令交叉使用性

AT指令之間存在依賴性，如ESP系列的模塊，連接一個(gè)TCP服務(wù)器，步驟必須是：設(shè)置STA模式、設(shè)置連接路由器賬號(hào)密碼、設(shè)置連接TCP服務(wù)器的IP地址和端口。只要指令不按步驟下去，功能無法實(shí)現(xiàn)。

五、配網(wǎng)功能缺失

在BLE+WIFI雙模模塊時(shí)代，應(yīng)該保持具有BLE配網(wǎng)，airkiss配網(wǎng)，AT指令設(shè)置連接路由器賬號(hào)密碼及在AP狀態(tài)下的內(nèi)置網(wǎng)頁配網(wǎng)功能。而市場上大部分模塊只有其中一種或者幾種功能，并不能全功能具備，導(dǎo)致在不同環(huán)境下的配網(wǎng)功能缺少無法連接路由器。

六、透傳功能封包慢

這個(gè)是整個(gè)行業(yè)的通病，目前整個(gè)行業(yè)透傳封包速度在50ms。我們知道對(duì)于模塊來說，模塊無法通過串口數(shù)據(jù)判斷串口數(shù)據(jù)的開始和結(jié)束，所以封包數(shù)據(jù)越長，則模塊設(shè)計(jì)難度越大，而對(duì)于用戶來說，就會(huì)把數(shù)據(jù)的延時(shí)至少放大50ms。而對(duì)于單片機(jī)設(shè)計(jì)者來說，在透傳狀態(tài)下至少發(fā)下一條數(shù)據(jù)的需要等待50ms以上。

七、協(xié)議層功能缺失

目前市場上大部分的WIFI模塊只支持UDP，TCP客戶端，TCP服務(wù)器的功能。而TCP服務(wù)器狀態(tài)下也無法進(jìn)行透傳功能。部分新開發(fā)的模塊可以支持HTTP和MQTT功能，但是無法支持HTTPS和MQTTS等功能，導(dǎo)致應(yīng)用環(huán)境大大缺失。未來是信息安全的時(shí)代，HTTPS和MQTTS對(duì)于物聯(lián)網(wǎng)來說，勢在必行!

審核編輯：湯梓紅