主要是針對之前產品中web應用的設計的重構，把業務與一些東西分離出來，方便維護，本身比較簡單, 注意這個不是說寫web服務程式的。
goahead
json-c
jquery
web服務與主應用互動
web服務程序同應用程序在同乙個嵌入式系統中，兩個程序的互動使用unix域udp方試通訊，主要的是資料是，web前端的資料請求，資料的提交或控制命令，資料都用json的格式傳輸。
web服務與web前端互動
web前端的html請求都通過goahead處理了，在資料上面，我們用ajax傳輸json的方式,goahead通過udp服務轉給主應用，主應用處理後返回進goahead,再回應給web前端。
之所以用unix域udp通訊，乙個是速度，也可靠，json交換的資料也不是太大，雙向通訊，簡單，包與包之前不用再去分隔了。
web服務使用開源的goahead這個工具，它相對於web前端來說是乙個服務端，在與我們的主應用來說又是乙個unix域udp客戶端。
web服務端的初始化
goahead的初始化可以參見它的例子中，其實我對這個工具也不太熟悉，在它提供的例子裡來改一下，它的初始化操作中有乙個initwebs 的過程，這裡面設定了一些必要的引數，如預設的網頁，比如我的設定的是 index.html 是乙個巨集定義的：
分別定義了預設的主頁，埠。
因為要與主應用中通訊，使用的是unix的域udp方式，所以在goahead裡我們要初始建立乙個socket的來與主應用互動。
在乙個合適的地方，定義乙個web_client_init,它的作用就是初始化建立乙個unix的域udp socket而已,所以在initwebs中呼叫過程: web_client_init()。
在乙個合適的地方，定義乙個 int web_client_send(char* buf, int len, char* recvbuf, int* maxlen)， 用它來把web前端的資料**給主應用，同時接收主應用的回應。
在goahead裡接收web前端過來的ajax 請求json資料，做如下的動作：
設定乙個url請求的處理過程：
websurlhandlerdefine(t("/ajax/json_data"),null, 0, ajax_json_data, 0);
這果 url 為 http://***x/ajax/json_data 這樣的url過來的資料，都傳給ajax_json_data處理了。如我的如下的處理,
#definerecv_buf_len 2048
static
charrecv_buf[recv_buf_len];
int
ajax_json_data(webs_t wp, char_t *urlprefix, char_t *webdir,intarg,
char_t *url, char_t *path, char_t *query);
intrecvlen = recv_buf_len;
recv_buf[0]= 0;
ret= web_client_send(data, len, recv_buf, &recvlen);
if(ret == 0)
"));
}else
}else"));
}websdone(wp,200);
return1;
一般json的請求資料都不大太，注意空間的分配，上面的過程就是呼叫 web_client_send 把資料發給主應用，主應用處理完後，同樣返回的是json格式的應答，獲取主應用的應答後通過webswrite寫回給web前端，注意 websgetvar 獲取資料的方式，找的是名為」data」的，這個是在web網頁中js裡定義的，原因是我們的js**是這樣寫的:
functionajaxactionwrap(actiondata, callback)
$.post(url_ajax_action,
data: actiondata,
function(data, status)webajaxaction;
actionname是對應處理方法的標識，如web前端傳乙個這樣的json資料過來：
}那麼 wifi_status 就是對應actionname.
記錄註冊每乙個json裡的action呼叫過程,如:
staticwebajaxactionwebajaxactionlist = ,,,
,,像wifi_status,wifi_scan… 這些都是呼叫方法的標識，這個要與web前端協商好，保持一致。
actionproc 引數就是對應的呼叫方法了。
上面的過程，也就是如 web 傳乙個json資料過來，它裡面有對應的actionname，通過actionname找到對應的業務方法，json裡也會有一些引數，把json裡的資料解析出來，呼叫對應的業務方法就行了，同時把處理的過後的資料通過web服務端返回的web前端。
從上面的過程，來說，呼叫recvfrom接收到資料報後，呼叫乙個過程，從webajaxactionlist 裡找到對應的處理方法，呼叫處理方法，處理方法完成後，把要返回的資料通過sendto 再回到web服務端，再返回的web前端。整個過程就完事了。
完成上面的東西，web前端就可認方便的呼叫了，當html顯示載入完成後，再通過ajax的方式，用json的格式來呼叫資料。
如我的獲取乙個wifi的連線狀態，當然，互動的json資料需要web前端與主應用後端要協商好，用什麼樣的格式，比如我的是：
表示呼叫的方法是 wifi_status
/*獲取wifi連線狀態*/
functiongetwifistatus()
var data ='';
ajaxactionwrap(data,getwifistatuscallback);
functionajaxactionwrap(actiondata, callback)
$.post(url_ajax_action,
data: actiondata,
function(data, status)elseelse{
$("#wificurstatus").html("未連線");
在後端，它會找到wifi_status的對應處理方法，處理後返回定義好的json資料格式，web前端再顯示出來。
通過上面的處理方式，對於主應用來說，把業務相關的都隔離開了，在對應的處理方法中，web服務端只負責傳輸資料，web前端通過ajax的方式傳輸json資料和接收，通過js指令碼控制。
在新增新的業務時，也只要修改web前端的js指令碼，主後端註冊一下處理的方法就行。
注：對web應用只懂一點點，對上面的實現提一點注意的地方：
1：js指令碼裡最好不要用eval轉換資料生成對像，不安全，可以用jquery裡的對應工具。
2：ajax的請求認證，一定要記得新增，像上面的應用的話，比較好的方式可以加在web服務端的ajax_json_data 裡,在請求後端應用時，驗證一下，見很多產品，ajax請求盡然沒有驗證許可權。
乙個嵌入式的成長
記得那是 2006 年的第一場雪，比 2005 年來的稍晚了些。在 2006 年初，我們公司開始涉及嵌入式領域，其實就是開始涉及基於 arm的嵌入式式開發。原來一直搞微控制器開發，上大學時幫助老師調點 pic的微控制器程式這樣的經歷使我積累了點關於硬體的經驗。當時國內的嵌入式式開發還幹幹起步，基本上...
嵌入式應用中的工程web技術
web瀏覽器事實上已經成為各種應用的標準使用者介面。它們可以執行在任何平台上 從pcs和工作站到pdas，手機，傳真機 並且允許終端使用者從任何地方訪問web使能 web enabled 的應用。應用到嵌入式系統，web技術提供介面友好的 低廉的 交叉平台的圖形使用者介面，並且是隨時可以上網的。系統...
開乙個嵌入式學習的坑
2.3版本的stm32f10x dfp與5.15版本的mdk並不相容，開始新建專案會有message函式沒辦法正常讀取的問題。有前輩說將keil.stm32f1xx dfp.pdsc中的message函式注釋掉會解決，親測無效，有可能是別的原因。在解除安裝舊版本的mdk時，原本的韌體包不會被解除安裝...