91欧美超碰AV自拍|国产成年人性爱视频免费看|亚洲 日韩 欧美一厂二区入|人人看人人爽人人操aV|丝袜美腿视频一区二区在线看|人人操人人爽人人爱|婷婷五月天超碰|97色色欧美亚州A√|另类A√无码精品一级av|欧美特级日韩特级

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

淺談I2C兼容接口讀取多字節(jié)數(shù)據(jù)時數(shù)據(jù)傳輸方法

電子設(shè)計 ? 來源:eeweb ? 作者:Maxim ? 2021-04-21 13:46 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

本應用筆記討論了通過I2C兼容接口讀取多字節(jié)數(shù)據(jù)時的注意事項。討論了一次讀取一個字節(jié)的陷阱,并給出了一些具體示例。本文還介紹了處理此類數(shù)據(jù)傳輸?shù)恼_方法。**

I2C嵌入式系統(tǒng)中使用的串行數(shù)據(jù)傳輸協(xié)議之一。它用于將低速外圍設(shè)備連接到嵌入式微處理器。它還用于中低數(shù)據(jù)速率通信。EPROM實時時鐘系統(tǒng)存儲設(shè)備,遠程溫度傳感器和I / O端口擴展器是慢速外圍設(shè)備的一些示例。

兼容I2C的兩線式接口是一種強大的機制,可用于將微控制器或微處理器與低速外圍設(shè)備接口,例如具有集成模數(shù)轉(zhuǎn)換器ADC)的外圍設(shè)備。通過該總線進行通信的最基本形式(即一次向/從從寄存器寫入/讀取單個字節(jié))非常簡單。但是,為簡單起見,將自己限制在這種方法上存在一些陷阱。

通過1字節(jié)通道傳輸2字節(jié)數(shù)據(jù)

與其他任何與外圍設(shè)備(尤其是傳感器)的數(shù)字接口一樣,我們需要從設(shè)備的內(nèi)部寄存器中讀取正確的數(shù)據(jù)。當寄存器的數(shù)據(jù)在讀取過程中發(fā)生變化時,這一點尤其重要。如果在數(shù)據(jù)傳輸時ADC運行其轉(zhuǎn)換或更新寄存器,則數(shù)據(jù)可能會發(fā)生變化。許多設(shè)備具有內(nèi)部緩沖區(qū)(通常不能從外部訪問),該緩沖區(qū)包含轉(zhuǎn)換的最新結(jié)果。當沒有I2C活動時,設(shè)備使用新數(shù)據(jù)更新所謂的“客戶可訪問”寄存器。

I2C協(xié)議一次傳輸1個字節(jié)的數(shù)據(jù)。因此,如果感興趣的總量數(shù)據(jù)長于8位并且傳輸處理不正確,則可能會出現(xiàn)問題。例如,MAX44000的環(huán)境光傳感器(ALS)數(shù)據(jù)寄存器最多可包含14位數(shù)據(jù)(加上1位表示溢出,這意味著應增加計數(shù)/照度設(shè)置)。

我們無法直接通過I2C讀取所有ALSDATA [13:0],因此我們必須首先讀取寄存器0x04的內(nèi)容,然后讀取寄存器0x05的內(nèi)容,并將數(shù)據(jù)連接到至少一個16位寄存器中。但是,我們必須注意如何讀取此數(shù)據(jù)。可以簡單地執(zhí)行兩個以STOP(P)條件終止的單次讀取,如圖1所示。

pIYBAGB_u9aAex7SAAAdMdS59uw910.png

這種方法有一個致命的缺陷。具體來說,發(fā)送STOP條件會向器件發(fā)出信號,要求其返回以更新“客戶可見”寄存器。因此,從寄存器0x04獲取數(shù)據(jù)后,實際上14位數(shù)據(jù)可以在讀取寄存器0x05之前進行更新。在某些情況下,此缺陷可能會造成災難性的后果。

一個例子是,如果光照水平在一定水平,MAX44000環(huán)境光傳感器處于10位,12位或14位模式。假設(shè)電平徘徊在某個區(qū)域內(nèi),則寄存器0x04和0x05中的14位計數(shù)總計為255或256,這可能是由于光線緩慢增加或少量噪聲引起的??紤]圖2所示表中的三種情況。

o4YBAGB_u-KAberfAABWLVjuLOg334.png

單字節(jié)讀取。

在最后兩種情況下,我們讀取0或511,而不是讀取255或256。這是一個很大的問題。發(fā)生這種情況的原因是在發(fā)送STOP條件之后,在第一次讀取和第二次讀取之間更新了寄存器0x04和0x05中的數(shù)據(jù)。在第一種有問題的情況下,正確讀取了第一個字節(jié)。但是到讀取第二個字節(jié)時,數(shù)據(jù)讀取的總數(shù)為256,其中最低字節(jié)為零。因此,我們從該設(shè)備獲得零讀數(shù)。在第二個有問題的情況下,數(shù)據(jù)也總計為256個計數(shù)。由于在發(fā)送STOP條件之后但在讀取第二個字節(jié)之前數(shù)據(jù)減少了一個計數(shù),因此該計數(shù)似乎變?yōu)?11個計數(shù)。有關(guān)在多次讀取中發(fā)生這種情況的次數(shù)的示例,請參見圖3。

pIYBAGB_u_GAfbomAAAe7_MfcV4018.png

單字節(jié)的實際讀數(shù)可讀取許多樣本。

如圖4所示,通過一次讀取2個字節(jié)可以輕松避免此問題,這是通過在讀取第一個數(shù)據(jù)字節(jié)之后發(fā)送REPEATED START而不是STOP條件來完成的,并且非常容易實現(xiàn)。通過讀取2個字節(jié),即使我們在兩個器件之間總體上發(fā)送了相同數(shù)量的位,也阻止了該部分執(zhí)行更多的I2C寄存器更新。

o4YBAGB_u_6AbDSJAAAUjZ-GVh8882.png

2字節(jié)讀取的插圖。

上面的例子適用于MAX44000和MAX44009,它們在進行多次讀取時不會自動遞增寄存器指針。您的設(shè)備的行為可能有所不同,但是原理始終相同。這很容易擴展為讀取N個字節(jié)。

編輯:hfy

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 微控制器
    +關(guān)注

    關(guān)注

    48

    文章

    8394

    瀏覽量

    164701
  • 寄存器
    +關(guān)注

    關(guān)注

    31

    文章

    5609

    瀏覽量

    130039
  • 模數(shù)轉(zhuǎn)換器

    關(guān)注

    26

    文章

    4020

    瀏覽量

    130130
  • 時鐘系統(tǒng)
    +關(guān)注

    關(guān)注

    1

    文章

    129

    瀏覽量

    12938
收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關(guān)推薦
    熱點推薦

    天碩(TOPSSD)技術(shù)深解:TBW(總寫入字節(jié)數(shù))的工程實現(xiàn)

    在評估工業(yè)嵌入式存儲設(shè)備能否勝任長達數(shù)年的持續(xù)運行任務時,TBW(總寫入字節(jié)數(shù))是比接口速度更為關(guān)鍵的量化指標。它直接回答了“這塊硬盤在退役前,總共能安全寫入多少數(shù)據(jù)?”這一根本問題。對于軌道交通日志記錄、工業(yè)視頻流存儲等高寫入
    的頭像 發(fā)表于 02-10 14:49 ?176次閱讀
    天碩(TOPSSD)技術(shù)深解:TBW(總寫入<b class='flag-5'>字節(jié)數(shù)</b>)的工程實現(xiàn)

    I2C的總線協(xié)議

    決定數(shù)據(jù)通信的發(fā)端和收端,發(fā)端每發(fā)送 1 個字節(jié)數(shù)據(jù),收端必須回應 1 個 ACK 應答信號。數(shù)據(jù)傳輸完成后,主機發(fā)送 STOP 信號結(jié)束本次通信。
    發(fā)表于 12-15 08:07

    CW32單片機I2C接口來讀寫EEPROM芯片

    。此后根據(jù)主機發(fā)送的第 1 字 節(jié)的 W/R 位來決定數(shù)據(jù)通信的發(fā)端和收端,發(fā)端每發(fā)送 1個字節(jié)數(shù)據(jù),收端必須回應 1個ACK 應答信號。數(shù)據(jù)傳輸完成后,主機發(fā)送 STOP 信號結(jié)束本次通信。 2.
    發(fā)表于 12-09 07:43

    多通道數(shù)據(jù)傳輸終端 LoRa/LTE雙模通信終端

    數(shù)據(jù)傳輸
    穩(wěn)控自動化
    發(fā)布于 :2025年10月24日 13:57:21

    使用fal api 來讀寫1024 字節(jié)數(shù)據(jù),需要需要考慮被高優(yōu)先級線程打斷嗎?

    使用fal api 來讀寫1024 字節(jié)數(shù)據(jù),需要需要考慮被高優(yōu)先級線程打斷嗎?
    發(fā)表于 10-10 07:16

    為什么rt_device_read()只能讀取到兩個字節(jié)數(shù)據(jù)

    已經(jīng)確定了設(shè)備每次會發(fā)送9字節(jié)數(shù)據(jù),但是每次都只能讀取到兩字節(jié)數(shù)據(jù),而且串口的配置都沒問題 /* 接收數(shù)據(jù)回調(diào)函數(shù) */ static rt_err_t uart_rx_ind
    發(fā)表于 09-17 06:24

    嵌入式接口通識知識之I2C接口

    時候SDA數(shù)據(jù)線才允許高電平或者低電平變化。每傳送一個數(shù)據(jù)位產(chǎn)生一個時鐘。在數(shù)據(jù)傳輸時,SDA線上面的每個字節(jié)數(shù)據(jù)長度必須是8位。每次傳輸
    發(fā)表于 08-14 14:46

    基于FPGA的USB數(shù)據(jù)傳輸

    你也許會有疑問,明明有這么多通信方式和數(shù)據(jù)傳輸(SPI、I2C、UART、以太網(wǎng))為什么偏偏使用USB呢?
    的頭像 發(fā)表于 08-06 14:47 ?4889次閱讀
    基于FPGA的USB<b class='flag-5'>數(shù)據(jù)傳輸</b>

    數(shù)據(jù)傳輸卡頓?工控一體機接口兼容性問題與線纜選型聚徽全解析

    在工業(yè)自動化領(lǐng)域,工控一體機承擔著數(shù)據(jù)采集、處理與傳輸的重要任務,其數(shù)據(jù)傳輸的流暢性直接關(guān)系到生產(chǎn)系統(tǒng)的穩(wěn)定性與效率。然而,數(shù)據(jù)傳輸卡頓的現(xiàn)象卻時常出現(xiàn),這背后,
    的頭像 發(fā)表于 07-02 10:30 ?950次閱讀

    Android14在BLE中,當MTU超過 517時,如何處理數(shù)據(jù)傳輸

    /behavior-changes-all#mtu-set-to-517 我們在應用更改后進行了測試,但遇到了無法傳輸超過 512 字節(jié)數(shù)據(jù)的問題。 由于客戶的工作數(shù)據(jù)通常超過 512
    發(fā)表于 07-01 06:56

    像這樣一款體積小巧的DTU數(shù)據(jù)傳輸終端你見過嗎?

    數(shù)據(jù)傳輸
    才茂通信
    發(fā)布于 :2025年06月04日 14:33:29

    SPI數(shù)據(jù)傳輸緩慢問題求解

    我遇到了 SPI 數(shù)據(jù)傳輸速率問題。 盡管將 SPI 時鐘頻率設(shè)置為 20 MHz,但我只獲得了 2 Kbps 的數(shù)據(jù)傳輸速率。 我正在以 115200 的波特率通過 UART 監(jiān)控數(shù)據(jù)。 我正在 cyfxusbspidmamo
    發(fā)表于 05-15 08:29

    使用CyU3PDmaChannelCommitBuffer提交超過1024字節(jié)數(shù)據(jù)時usb包異常大怎么解決?

    你好,我正在嘗試使用fx3實現(xiàn)USB3Vision設(shè)備,但是當我使用CyU3PDmaChannelCommitBuffer函數(shù)提交超過1024字節(jié)數(shù)據(jù)時,主機獲取到的USB數(shù)據(jù)包變得非常大
    發(fā)表于 05-13 06:11

    LCR測試儀數(shù)據(jù)傳輸接口類型選型指南

    將深入探討LCR測試儀的主流數(shù)據(jù)傳輸接口類型,并提供詳細的選型指南和實際應用案例。 一、數(shù)據(jù)傳輸接口的核心作用 LCR測試儀通過測量元件的電感(L)、電容(
    的頭像 發(fā)表于 04-01 15:16 ?946次閱讀
    LCR測試儀<b class='flag-5'>數(shù)據(jù)傳輸</b><b class='flag-5'>接口</b>類型選型指南

    FreeRTOS進階使用之流緩沖區(qū):高效處理字節(jié)流的秘密武器

    xStreamBufferReceive 從緩沖區(qū)讀取數(shù)據(jù) 緩沖區(qū)句柄、接收緩沖區(qū)、長度 實際讀取字節(jié)數(shù) vStreamBufferReset 清空緩沖區(qū)數(shù)據(jù) 無 無 示例代碼(任務
    發(fā)表于 03-24 11:37