|
|
在對(duì)GPS接收到的衛(wèi)星信息進(jìn)行處理時(shí)，碰到較為麻煩的問題是在對(duì)接收到的時(shí)間信息進(jìn)行轉(zhuǎn)換上。直接從衛(wèi)星接收到的時(shí)間是UTC時(shí)間，北京時(shí)間應(yīng)在UTC時(shí)間上加上8小時(shí)才是準(zhǔn)確的北京時(shí)，在超出24小時(shí)時(shí)應(yīng)作減24小時(shí)處理。
剛開始將對(duì)時(shí)間轉(zhuǎn)換的算法放在主函數(shù)中處理，程序如下：
if(g_Ptr == 2) //接收到正確的數(shù)據(jù)幀
{
i = g_DisTime[0]-'0' ;//提取時(shí)間的小時(shí)位高位并轉(zhuǎn)換碼型
j = g_DisTime[1]-'0';//提取時(shí)間的小時(shí)位低位并轉(zhuǎn)換碼型
j = i*10 + j+ 8; //在UTC時(shí)間上加上8個(gè)小時(shí)
if (j >= 24) //判斷得到的時(shí)間是否超過24小時(shí)，超出變作減24處理
{
j - = 24;
}
g_DisTime[0] = j/10+'0'; //將北京時(shí)間高一位作碼型變換并賦予高一位顯示
g_DisTime[1] = j%10 +'0';//將北京時(shí)間高二位作碼型變換并賦予高二位顯示
}
在調(diào)試中出現(xiàn)一個(gè)問題，在做了以上的處理后，時(shí)間的小時(shí)位數(shù)據(jù)并不完全正確，高位顯示的與北京時(shí)間相同，但低位卻與UTC時(shí)間相同。在做了各種嘗試（如在UTC時(shí)間上做加9處理、直接給六位時(shí)間g_DisTime[5]賦值等）后總結(jié)出這樣一個(gè)問題，以上的算法處理只對(duì)六位數(shù)據(jù)位的高一位處理有效，低五位的顯示始終都是正確UTC時(shí)間。經(jīng)過分析，初步認(rèn)定上面的程序并沒有被完全的執(zhí)行。因GPS接收模塊源源不斷的傳送數(shù)據(jù)給單片機(jī)處理，在運(yùn)行過程中定位信息大約每秒鐘更新一次，在主函數(shù)中對(duì)收到的時(shí)間進(jìn)行處理時(shí)有可能會(huì)出現(xiàn)還沒來得及處理完畢時(shí)便接收到下一幀數(shù)據(jù)，故時(shí)間的處理就可能會(huì)有只對(duì)高一位處理完成而沒完成處理好低五位時(shí)又進(jìn)入了串行口中斷，那么液晶顯示的結(jié)果就是經(jīng)過處理的高一位(北京時(shí)間)和未經(jīng)處理的低五位(UTC時(shí)間)。考慮到以上原因，將原放在主函數(shù)的時(shí)間轉(zhuǎn)換處理程序放置在到中斷時(shí)一收到UTC時(shí)間就對(duì)其進(jìn)行轉(zhuǎn)換處理。經(jīng)過了調(diào)試，終于在液晶上顯示出來正確的北京時(shí)間，證明了以上的分析、推斷的正確性。
經(jīng)過測(cè)試，液晶顯示的結(jié)果如下圖5-1：
|
|
QQ好友和群
QQ空間
騰訊微博
騰訊朋友
收藏
淘帖
頂
踩
