本發(fā)明涉及嵌入式設(shè)備，特別涉及一種嵌入式設(shè)備控制器的實時日志記錄方法。

背景技術(shù)：

實時日志記錄了軟件真實的運行過程，一般用來調(diào)試軟件或者定位軟件運行過程中出現(xiàn)故障的位置。目前市場上的諸如麻醉機呼吸控制單元板的嵌入式設(shè)備控制器具備有效數(shù)據(jù)上傳的功能，但不具備實時日志輸出的功能，當出現(xiàn)了故障，一般靠技術(shù)人員等待故障復(fù)現(xiàn)時進行分析，不能第一時間對現(xiàn)場故障進行分析處理。

技術(shù)實現(xiàn)要素：

本發(fā)明的目的在于克服已有的嵌入式設(shè)備控制器無法及時實時輸出日志信息，導(dǎo)致技術(shù)人員無法及時對現(xiàn)場故障加以處理的缺陷，從而提供一種實時日志記錄方法。

為了實現(xiàn)上述目的，本發(fā)明提供了一種嵌入式設(shè)備控制器的實時日志記錄方法，包括：

步驟1)、判斷嵌入式設(shè)備控制器是否存在文件系統(tǒng)，若存在文件系統(tǒng)，執(zhí)行下一步，否則執(zhí)行步驟3)；

步驟2)、將日志消息以文件方式存儲，然后判斷是否需要將日志消息實時輸出，若需要，執(zhí)行下一步，否則，結(jié)束操作；

步驟3)、判斷通訊口緩存中的空閑字節(jié)數(shù)是否大于所要發(fā)送的日志消息的長度，若大于或等于，執(zhí)行下一步，否則，執(zhí)行步驟6)；其中，所述通訊口包括串口、網(wǎng)口、無線端口中的一種；

步驟4)、判斷通訊口是否處于忙狀態(tài)，若通訊口處于不忙的狀態(tài)，則執(zhí)行下一步，若通訊口處于忙狀態(tài)，則將日志消息的數(shù)據(jù)幀拷貝到通訊口緩存區(qū)的下一個位置，并將數(shù)據(jù)幀地址及長度寫入待發(fā)送隊列，待通訊口處于不忙狀態(tài)后，再執(zhí)行下一步；

步驟5)、將日志消息的數(shù)據(jù)拷貝到通訊口的發(fā)送緩存中，重置dma的內(nèi)存地址及發(fā)送長度，使能dma發(fā)送，然后執(zhí)行步驟7)；

步驟6)、通訊口緩存空閑字節(jié)數(shù)小于要發(fā)送的數(shù)據(jù)長度，等待通訊口緩存空閑 字節(jié)被釋放，待通訊口緩存空閑字節(jié)數(shù)增加使得通訊口緩存空閑字節(jié)數(shù)大于或等于所要發(fā)送的數(shù)據(jù)的長度后，再執(zhí)行步驟4)；

步驟7)、dma發(fā)送日志消息數(shù)據(jù)，在發(fā)送過程中置位忙狀態(tài)；

步驟8)、在dma發(fā)送完成的中斷中，執(zhí)行以下操作：

步驟8-1)、復(fù)位忙狀態(tài)，即將通訊口的忙狀態(tài)轉(zhuǎn)變?yōu)椴幻顟B(tài)；

步驟8-2)、檢查待發(fā)送隊列中有無數(shù)據(jù)，若還有待發(fā)送的數(shù)據(jù)，則將這些數(shù)據(jù)移出待發(fā)送隊列，然后執(zhí)行步驟3)，若不存在待發(fā)送數(shù)據(jù)，執(zhí)行步驟8-3)；

步驟8-3)、檢查等待隊列，如果等待隊列中包括有日志消息的數(shù)據(jù)，就轉(zhuǎn)而執(zhí)行步驟3)，如果沒有，結(jié)束操作。

本發(fā)明的優(yōu)點在于：

本發(fā)明的方法能夠?qū)崟r傳輸并記錄日志消息，保證日志信息的完整性。使得在出現(xiàn)故障時，技術(shù)人員可以查看日志，迅速定位故障點。

附圖說明

圖1是日志發(fā)送流程的原理示意圖；

圖2是本發(fā)明的嵌入式設(shè)備控制器的實時日志記錄方法的流程圖。

具體實施方式

現(xiàn)結(jié)合附圖對本發(fā)明作進一步的描述。

日志發(fā)送流程原理如圖1，將要發(fā)送的日志數(shù)據(jù)拷貝至發(fā)送緩存，將發(fā)送地址和長度寫入消息隊列，發(fā)送任務(wù)在判斷dma(directmemoryaccess，存儲器直接訪問)空閑后，接收消息隊列數(shù)據(jù)，并重置dma的內(nèi)存地址及長度，使能dma發(fā)送，發(fā)送過程不需要cpu干預(yù)，極大地減輕了cpu負擔，也在一定程度上提高了實時性。從日志發(fā)送流程也可發(fā)現(xiàn)數(shù)據(jù)發(fā)送時間、數(shù)據(jù)量和數(shù)據(jù)緩存的關(guān)系：數(shù)據(jù)緩存是空間換時間，復(fù)用是時間換空間。

本發(fā)明中所涉及的日志的內(nèi)容可根據(jù)各個任務(wù)的特點定義，可包括統(tǒng)計日志、傳感器日志、通訊口交互指令日志、各模塊工作狀態(tài)日志等。日志的協(xié)議可定義不同的數(shù)據(jù)幀頭、指令、長度、校驗等實現(xiàn)。

參考圖2，本發(fā)明的嵌入式設(shè)備控制器的實時日志記錄方法包括：

步驟1)、判斷嵌入式設(shè)備控制器是否存在文件系統(tǒng)，若存在文件系統(tǒng)，執(zhí)行下一步，否則執(zhí)行步驟3)；

步驟2)、將日志消息以文件方式存儲，然后判斷是否需要將日志消息實時輸出，若需要，執(zhí)行下一步，否則，結(jié)束操作；

步驟3)、判斷通訊口緩存中的空閑字節(jié)數(shù)是否大于所要發(fā)送的日志消息的長度，若大于或等于，執(zhí)行下一步，否則，執(zhí)行步驟6)；其中，所述通訊口包括串口、網(wǎng)口、無線端口中的一種；

步驟4)、判斷通訊口是否處于忙狀態(tài)，若通訊口處于不忙的狀態(tài)，則執(zhí)行下一步，若通訊口處于忙狀態(tài)，則將日志消息的數(shù)據(jù)幀拷貝到通訊口緩存區(qū)的下一個位置，并將數(shù)據(jù)幀地址及長度寫入待發(fā)送隊列，待通訊口處于不忙狀態(tài)后，再執(zhí)行下一步；

步驟5)、將日志消息的數(shù)據(jù)拷貝到通訊口的發(fā)送緩存中，重置dma的內(nèi)存地址及發(fā)送長度，使能dma發(fā)送，然后執(zhí)行步驟7)；

步驟6)、通訊口緩存空閑字節(jié)數(shù)小于要發(fā)送的數(shù)據(jù)長度，等待通訊口緩存空閑字節(jié)被釋放，待通訊口緩存空閑字節(jié)數(shù)增加使得通訊口緩存空閑字節(jié)數(shù)大于或等于所要發(fā)送的數(shù)據(jù)的長度后，再執(zhí)行步驟4)；

步驟7)、dma發(fā)送日志消息數(shù)據(jù)，在發(fā)送過程中置位忙狀態(tài)；

步驟8)、在dma發(fā)送完成的中斷中，執(zhí)行以下操作：

步驟8-1)、復(fù)位忙狀態(tài)，即將通訊口的忙狀態(tài)轉(zhuǎn)變?yōu)椴幻顟B(tài)；

步驟8-2)、檢查待發(fā)送隊列中有無數(shù)據(jù)，若還有待發(fā)送的數(shù)據(jù)，則將這些數(shù)據(jù)移出待發(fā)送隊列，然后執(zhí)行步驟3)，若不存在待發(fā)送數(shù)據(jù)，執(zhí)行步驟8-3)；

步驟8-3)、檢查等待隊列，如果等待隊列中包括有日志消息的數(shù)據(jù)，就轉(zhuǎn)而執(zhí)行步驟3)，如果沒有，結(jié)束操作。

在本發(fā)明的方法中，每個任務(wù)的日志內(nèi)容完整地復(fù)制到一個數(shù)據(jù)緩沖區(qū)內(nèi)，若是數(shù)據(jù)緩沖區(qū)空間不夠，需要等到有空閑空間再復(fù)制。這就保證了日志傳輸?shù)耐暾浴?/p>

最后所應(yīng)說明的是，以上實施例僅用以說明本發(fā)明的技術(shù)方案而非限制。盡管參照實施例對本發(fā)明進行了詳細說明，本領(lǐng)域的普通技術(shù)人員應(yīng)當理解，對本發(fā)明的技術(shù)方案進行修改或者等同替換，都不脫離本發(fā)明技術(shù)方案的精神和范圍，其均 應(yīng)涵蓋在本發(fā)明的權(quán)利要求范圍當中。

技術(shù)特征：

技術(shù)總結(jié)
本發(fā)明涉及一種嵌入式設(shè)備控制器的實時日志記錄方法，包括：判斷嵌入式設(shè)備控制器是否存在文件系統(tǒng)，若存在文件系統(tǒng)，將日志消息以文件方式存儲，若不存在，則判斷通訊口緩存中的空閑字節(jié)數(shù)是否大于所要發(fā)送的日志消息的長度，若大于或等于，則在通訊口處于不忙的狀態(tài)時，將日志消息的數(shù)據(jù)拷貝到通訊口的發(fā)送緩存中，重置DMA的內(nèi)存地址及發(fā)送長度，使能DMA發(fā)送。

技術(shù)研發(fā)人員：宋恒利
受保護的技術(shù)使用者：北京誼安醫(yī)療系統(tǒng)股份有限公司
技術(shù)研發(fā)日：2015.12.24
技術(shù)公布日：2017.07.04