在嵌入式產(chǎn)品的開(kāi)發(fā)中少不了各種外圍設(shè)備的搭配使用。嵌入式開(kāi)發(fā)中需要做到將加入系統(tǒng)的外設(shè)連接起來(lái)，并能夠完成所需要的功能開(kāi)發(fā)。

在眾多的設(shè)備中，MCU與外設(shè)進(jìn)行通信都是按照一定的協(xié)議進(jìn)行的，都涉及到時(shí)序，只有按照約定好的協(xié)議才能進(jìn)行通信。

比如，常見(jiàn)的 1-Write單總線、IIC總線、SMBus總線、SPI總線等等的協(xié)議，都是需要在約定的通信協(xié)議下才能完成通信。而通信協(xié)議的實(shí)現(xiàn)反饋到MCU的時(shí)候，就只是一種IO口電平的變化輸出，以及外設(shè)傳送數(shù)據(jù)到MCU也是一種電平的變化或者是電平的時(shí)間寬度變化。

筆者在項(xiàng)目開(kāi)發(fā)中就遇到過(guò)和外設(shè)通信中需要測(cè)量波形的變化確認(rèn)數(shù)據(jù)狀態(tài)的情況，遇到過(guò)一些小問(wèn)題，隨即記錄下來(lái)分享一下調(diào)試心得，也做一個(gè)備忘。

情況是這樣，項(xiàng)目開(kāi)發(fā)中，有一個(gè)外設(shè)需要加入到系統(tǒng)中，這個(gè)外設(shè)是由生產(chǎn)廠商規(guī)定好了通信協(xié)議的，收發(fā)數(shù)據(jù)都要按照協(xié)議的規(guī)定進(jìn)行，MCU接收數(shù)據(jù)的規(guī)定如下：

在通信總線上的低電平期間，有20mA的電流變化時(shí)外設(shè)回復(fù)數(shù)據(jù)“1”，沒(méi)有電流變化為數(shù)據(jù)“0”。

電流的變化通過(guò)硬件電路轉(zhuǎn)換成電壓的變化，MCU通過(guò)AD檢測(cè)進(jìn)行判斷，從而得知數(shù)據(jù)的變化狀態(tài)。按照我們思路，MUC在低電平期間檢測(cè)到電流的變化啟動(dòng)AD檢測(cè)，根據(jù)AD值確認(rèn)數(shù)據(jù)狀態(tài)。如下圖示：

偽代碼示意如下：

while( !GPIO_Check_Pin ) // 通過(guò)電平變化確定電流變化

{

uint_32 adValue = 0;

if( GPIO_Check_Pin )

{

adValue = getAdValue(); // 讀取AD值

if(adValue > x)

xxx;

}

}

一般到這里認(rèn)為應(yīng)該也就算是完成了，可是在實(shí)際測(cè)試中發(fā)現(xiàn)，獲取得到的AD值跟電路上實(shí)際的電壓是有很多的出入的，測(cè)量總是不準(zhǔn)確。

苦思冥想，多次測(cè)量之后發(fā)現(xiàn)，原來(lái)跟時(shí)序的變化有關(guān)。原因到底什么呢？

原來(lái)，正常的想法都是波形變化之后進(jìn)行測(cè)量，而沒(méi)有考慮過(guò)波形的變化在不同的處理器上差異，以及硬件本身的延遲，往往不會(huì)立即就能發(fā)生翻轉(zhuǎn)的，有一個(gè)變化的過(guò)程的。

比如，理想的時(shí)序波形變化是這樣的：

然而，實(shí)際的時(shí)序波形變化是這樣的：

所以，在波形發(fā)生變化的時(shí)候就進(jìn)行測(cè)量，很多時(shí)候往往得不到正確的結(jié)果，可以測(cè)量的電位點(diǎn)都不對(duì)，測(cè)量發(fā)生在了電平變化的期間。

所以，要準(zhǔn)確測(cè)量，合適的方法是等待一段時(shí)間，電平變化穩(wěn)定之后再進(jìn)行測(cè)量，結(jié)果就更加證實(shí)準(zhǔn)確。如下：

所以，偽代碼示意如下：

while( !GPIO_Check_Pin )  // 通過(guò)電平變化確定電流變化
{
    uint_32 adValue = 0;
    if( GPIO_Check_Pin )
    {
        delay();
        adValue = getAdValue();  // 讀取AD值
        if(adValue > x)
            xxx;
    }
}

很多的嵌入式系統(tǒng)中，考慮到成本、工藝、實(shí)用性等的因素，很多的處理器都不會(huì)實(shí)用很強(qiáng)大的MCU，主頻可能都比較低，性能有限，很多的外設(shè)反應(yīng)速度可能也不及MCU，所以延時(shí)等待在很多時(shí)候都很有必要。