I2C不是AUTOSAR中標(biāo)準(zhǔn)的MCAL模塊，所以I2C在車載電控件中基本不用（一般都使用SPI），但是因?yàn)镮2C一主多從只需要兩個(gè)Pin腳就能控制多個(gè)外設(shè)的特性，在一些帶SOC的控制器中會(huì)使用到，且Vector的SIP包中也有I2C模塊，所有有必要學(xué)下以下，本文就概要的介紹下TC3xx芯片的I2C模塊。
AUTOSAR BSW: Vector Davinci
MCAL: EB Infineon
HW Platform: TC3xx
Lin模塊由fI2C提供時(shí)鐘，fI2C時(shí)鐘由fPLL2分頻得到，比如fPLL2為200M，I2CDIV配置為0x3，則fI2C=200M/3 = 66.66MHz.
至于fPLL2如何的來，可以參考《AUTOSAR架構(gòu)下TC3xx平臺(tái)的MCAL時(shí)鐘系統(tǒng)配置實(shí)踐》一文。
如下圖所示，每個(gè)I2C Unit能產(chǎn)生如下三個(gè)中斷請(qǐng)求信號(hào)，SRC_I2CxDTR, SRC_I2CxERR, SRC_I2CxP.
顧名思義，SRC_I2CxDTR是I2C在收發(fā)數(shù)據(jù)的時(shí)候產(chǎn)生, SRC_I2CxERR是I2C產(chǎn)生錯(cuò)誤的時(shí)候產(chǎn)生, SRC_I2CxP是I2C協(xié)議處理時(shí)產(chǎn)生。具體見下文。
每個(gè)中斷服務(wù)請(qǐng)求可以由多個(gè)硬件事件觸發(fā)，具體見下圖所示。
這里主要介紹I2C代碼具體實(shí)現(xiàn)中會(huì)使用到的硬件事件，在介紹之前先簡(jiǎn)要介紹下I2C FIFO的功能。
I2C硬件由一個(gè)8*(4bytes, 1 word) 的硬件FIFO, 軟件通過RXD寄存器往FIFO中寫入要發(fā)送的數(shù)據(jù)，I2C Kernel會(huì)將FIFO中的數(shù)據(jù)發(fā)送到I2C Bus上去。同樣，I2C Kernel把I2C Bus上Slave發(fā)過來的數(shù)據(jù)存放到FIFO中，軟件可以通過RXD寄存器讀取I2C數(shù)據(jù)。
從I2C FIFO中一次讀數(shù)據(jù)的大小叫做RX Burst Size, 往I2C FIFO中一次寫的數(shù)據(jù)大小叫做TX Burst Size, 這兩個(gè)參數(shù)可以通過FIFOCFG.RXBS和FIFOCFG.TXBS配置。
比如，我們配置都FIFOCFG.RXBS和FIFOCFG.TXBS為01b也就是2 words, 那么我在讀寫RXD/TXD寄存器讀寫數(shù)據(jù)的時(shí)候（一般是在I2CxDTR中斷中）可以讀寫兩次。
解釋了TX/RX Burst Data Size后， 我們就來解釋幾個(gè)重要的硬件事件是怎么產(chǎn)生的。
DTR_INT對(duì)應(yīng)的硬件事件
在上文我們知道TXBS和RXBS是可以配置的且最小為1 word(4 bytes)最大為4 bytes(16 bytes)，那么這里就會(huì)有一個(gè)問題，如果我們總的I2C讀寫的數(shù)據(jù)不是TXBS/RXBS整數(shù)倍時(shí)該怎么辦？ -- I2C kernel會(huì)把最后小于TXBS/RXBS按照Single Data Size來處理（1 byte），這樣就會(huì)產(chǎn)生后面介紹的SREQ的硬件事件。
BREQ_srq: 我們要發(fā)送的總的數(shù)據(jù)會(huì)先寫到TPSCTRL.TPS寄存器位域中，寫TPSCTRL.TPS寄存器位域后就會(huì)立刻產(chǎn)生一個(gè)BREQ硬件事件。假設(shè)我們總的發(fā)送數(shù)據(jù)比FIFOCFG. TXBS要大（比如總的發(fā)送數(shù)據(jù)TPS為19 bytes，TXBS為2 words也就是8bytes）則：
第1步：I2C Kernel首先從FIFO中取TXBS數(shù)據(jù)（2 words, 8 bytes）發(fā)送到I2C bus, 產(chǎn)生一個(gè)BREQ硬件事件。還剩19 – 8 = 11 bytes數(shù)數(shù)據(jù)。
第2步：I2C Kernel從FIFO中取TXBS數(shù)據(jù)（2 words, 8 bytes）發(fā)送到I2C bus, 產(chǎn)生一個(gè)BREQ硬件事件。還剩11 – 8 = 3 bytes數(shù)數(shù)據(jù)。
第3步：還剩3 bytes數(shù)據(jù)，不夠一次TXBS數(shù)據(jù)發(fā)送，I2C kernel就會(huì)按Single Data發(fā)送數(shù)據(jù)，每次發(fā)送一個(gè)byte數(shù)據(jù)產(chǎn)生一個(gè)SREQ硬件事件，最后還剩一個(gè)byte數(shù)據(jù)時(shí)會(huì)產(chǎn)生LSREQ硬件事件。
所以當(dāng)TPSCTRL.TPS=19，TPSCTRL.TXBS = 2 words,產(chǎn)生的硬件事件如下：
BREQ -> BREQ -> BREQ -> SREQ -> SREQ ->LSREQ.
如果TPSCTRL.TPS=16，TPSCTRL.TXBS = 2 words,產(chǎn)生的硬件事件如下：
BREQ -> BREQ -> LBREQ.
Master節(jié)點(diǎn)通過I2C總線接收數(shù)據(jù)的時(shí)候，首先還是要先發(fā)送Slave節(jié)點(diǎn)的Address出去，所以也一定有一個(gè)寫TPSCTRL.TPS寄存器的操作，所以一定也會(huì)先產(chǎn)生一個(gè)BREQ的硬件事件。需要從I2C Bus上讀的總的數(shù)據(jù)通過MRPSCTRL寄存器配置。
所以當(dāng)TPSCTRL.TPS=1，TPSCTRL.TXBS = 2 words, MRPSCTRL = 19產(chǎn)生的硬件事件如下：
BREQ -> BREQ -> BREQ -> SREQ -> SREQ ->LSREQ.
ERR_INT和P_INT對(duì)應(yīng)的硬件事件在下圖中介紹的比較清楚，比較好理解，這里不再贅述。
I2C的數(shù)據(jù)收發(fā)是一個(gè)軟硬件配合的過程，在I2C數(shù)據(jù)收發(fā)前首先需要完成模塊的初始化（時(shí)鐘，波特率等）。其他的前置條件為：
FIFOCFG.TXFIC配置為1b, TX FIFO as flow controller.
FIFOCFG.CRBC配置為0b, Data request is cleared by software.
至于什么是flow controller, 我也不理解，只是手冊(cè)中推薦配置成flow controller進(jìn)行I2C數(shù)據(jù)的收發(fā)：
在以上前置條件下我們來詳細(xì)介紹I2C數(shù)據(jù)發(fā)送的軟硬件配合過程:
1）軟件清除所有pengding的中斷且Enable需要使用的中斷事件。
2）軟件往TPSCTRL.TPS寄存器中寫入要發(fā)送的數(shù)據(jù)大小，產(chǎn)生BREQ硬件事件。
3）硬件產(chǎn)生DTR_INT中斷請(qǐng)求，CPU調(diào)用DTR_INT中斷處理程序I2c_PerMgr_IrqDataTransHandler.
1.如果是BREQ或者LBREQ硬件事件觸發(fā)的中斷則調(diào)用I2c_PerMgr_TransmitData傳入的burst參數(shù)為TRUE.
2. 如果是BREQ或者LBREQ硬件事件觸發(fā)的中斷則清除調(diào)用BREQ和LBREQ硬件事件。
3.如果是SREQ或者LSREQ硬件事件觸發(fā)的中斷則調(diào)用I2c_PerMgr_TransmitData傳入的burst參數(shù)為FALSE.
4. 如果是SREQ或者LSREQ硬件事件觸發(fā)的中斷則清除調(diào)用SREQ和LSREQ硬件事件。
I2c_PerMgr_TransmitData根據(jù)burst的值是寫一次TXD寄存器還是兩次TXD寄存器（Vector的代碼配置TXBS為2 words）。
這樣就完成了一次中斷數(shù)據(jù)的發(fā)送，之后中斷周而復(fù)始產(chǎn)生，I2C數(shù)據(jù)也周而復(fù)始的通過TXD寄存器發(fā)發(fā)送出去，直到產(chǎn)生TX_END硬件事件。
4）硬件產(chǎn)生P_INT中斷請(qǐng)求，CPU調(diào)用P_INT中斷處理程序I2c_PerMgr_IrqHandler.
I2c_PerMgr_IrqHandler-> I2c_PerMgr_StopTrans沒有特殊的操作，僅將一個(gè)軟件邏輯狀態(tài)置為TRUE.
以上就完成了一次I2C數(shù)據(jù)的完整發(fā)送。
對(duì)應(yīng)I2C狀態(tài)機(jī)中的M1 -> M4(可能多次M4) -> M16狀態(tài)遷移。
I2C的數(shù)據(jù)接收過程和數(shù)據(jù)發(fā)送過程的軟硬件配合差不多，需要注意的有以下兩點(diǎn)：
1.數(shù)據(jù)的接收首先要發(fā)Slave設(shè)備的地址，所以接收過程首先是一個(gè)發(fā)送從設(shè)備地址的發(fā)送過程，也就是說需要配置TPSCRTL.TPS寄存器。所以，同樣也是這個(gè)操作觸發(fā)接收過程的第一個(gè)BREQ硬件事件，才有后面一系列的過程。
2.數(shù)據(jù)發(fā)送需要通過MRPSCTRL寄存器配置數(shù)據(jù)接收大小。
對(duì)應(yīng)I2C狀態(tài)機(jī)中的M1 -> M4(可能多次M4) -> M2 -> M12狀態(tài)遷移。
我們已經(jīng)介紹了很多芯片的硬件模塊，雖然每個(gè)硬件模塊的具體實(shí)現(xiàn)機(jī)制不一樣，但是宏觀上的學(xué)習(xí)方法都類似的，一般搞清楚以下幾個(gè)內(nèi)容基本就能初步理解這個(gè)硬件模塊的基本工作原理：
1.該硬件模塊的時(shí)鐘由哪個(gè)基本時(shí)鐘分頻（倍頻）出來，時(shí)鐘范圍大概多少？
2.該硬件模塊能產(chǎn)生哪些硬件中斷，觸發(fā)中斷的硬件事件有哪些，實(shí)際項(xiàng)目中一般配置哪些硬件事件觸發(fā)中斷？
3.該模塊如何進(jìn)行數(shù)據(jù)的發(fā)送？
4.該模塊如何進(jìn)行數(shù)據(jù)的接收？
End
「汽車電子嵌入式在CSDN上同步推出AUTOSAR精進(jìn)之路專欄，本專欄每個(gè)模塊完全按實(shí)際項(xiàng)目中開發(fā)及維護(hù)過程來詳細(xì)介紹。模塊核心概念介紹、實(shí)際需求描述、實(shí)際工程配置、特殊需求介紹及背后原理、實(shí)際工程使用經(jīng)驗(yàn)總結(jié)。 目的是讓讀者看完每一個(gè)章節(jié)后能理解原理后根據(jù)需求完成一個(gè)模塊的配置或者解決一個(gè)問題?！?/span>
點(diǎn)擊文章最后左下角的閱讀原文可以獲取更多信息
或者復(fù)制如下鏈接到瀏覽器獲取更多信息
https://blog.csdn.net/qq_36056498/article/details/132125693
文末福利
2.為便于技術(shù)交流，創(chuàng)建了汽車電子嵌入式技術(shù)交流群，可盡情探討AP，CP，DDS，SOME/IP等前沿?zé)狳c(diǎn)話題，后臺(tái)回復(fù)“加群”即可加入；
注：本文引用了一些第三方工具和文檔，若有侵權(quán)，請(qǐng)聯(lián)系作者刪除!
推薦閱讀
汽車電子嵌入式精彩文章匯總第一期：20210530-20230703
汽車電子嵌入式精彩文章匯總第2期
汽車電子嵌入式精彩文章匯總第3期
【OS】AUTOSAR OS Event實(shí)現(xiàn)原理
【OS】AUTOSAR OS Spinlock實(shí)現(xiàn)原理（下篇）
【OS】AUTOSAR OS Spinlock實(shí)現(xiàn)原理（上篇）
CanNm處于PBS狀態(tài)下接收到一幀診斷報(bào)文DCM會(huì)響應(yīng)嗎
TC3xx芯片CAN模塊詳解
AUTOSAR OS Alarm實(shí)現(xiàn)原理
AUTOSAR OsTask切換原理
TC3xx 芯片SPI模塊詳解
AUTSOAR ComStack如何實(shí)現(xiàn)PDU只收不發(fā)的
AUTOSAR OsStack監(jiān)控原理
AUTOSAR架構(gòu)下ICU喚醒詳解
CanNm報(bào)文的觸發(fā)發(fā)送詳解
Can報(bào)文能發(fā)不能收問題分析
TC3xx芯片PFlash的ECC校驗(yàn)問題補(bǔ)充
AUTOSAR架構(gòu)下喚醒源檢測(cè)函數(shù)EcuM_CheckWakeup詳解
什么是Copy Table及如何使用Copy Table
AUTOSAR架構(gòu)下EcuM_StartupTwo函數(shù)功能詳解
符合AUTOSAR標(biāo)準(zhǔn)的RTAOS-Schedule Tables詳解（上篇）
AUTOSAR OS Schedule Table實(shí)現(xiàn)原理
符合AUTOSAR標(biāo)準(zhǔn)的RTAOS-Schedule Tables詳解（下篇）
TJA1145收發(fā)器重要功能介紹
AUTOSAR架構(gòu)下基于TJA1145收發(fā)器通信丟失問題分析
AUTOSAR架構(gòu)下LIN報(bào)文發(fā)送失敗問題分析
AUTOSAR項(xiàng)目實(shí)戰(zhàn)(1)-數(shù)據(jù)地址訪問對(duì)齊問題分析
AUTOSAR項(xiàng)目實(shí)戰(zhàn)(2)-內(nèi)存訪問異常問題分析
AUTOSAR項(xiàng)目實(shí)戰(zhàn)(4)-系統(tǒng)總線及外設(shè)錯(cuò)誤問題分析
AUTOSAR項(xiàng)目實(shí)戰(zhàn)(3)-OsCounter訪問權(quán)限問題分析
AUTOSAR項(xiàng)目實(shí)戰(zhàn)(4)-MCU模塊配置實(shí)踐
AUTOSAR架構(gòu)下的Interrupt詳解（上篇）
AUTOSAR架構(gòu)下的Interrupt詳解（下篇）
AUTOSAR項(xiàng)目實(shí)戰(zhàn)(6)-Port及Dio模塊配置實(shí)踐
TJA1145異常設(shè)置喚醒源導(dǎo)致ECU休眠失敗問題分析
Tasking編譯器下如何在鏈接文件中定義標(biāo)定段
什么Tasking編譯器中的farrom及nearrom?
AUTOSAR架構(gòu)下NvMBlock無效問題分析
AUTOSAR架構(gòu)下基于SPI通信的驅(qū)動(dòng)模塊詳解-以TJA1145為例
AUTOSAR架構(gòu)下XCP從0到1開發(fā)配置實(shí)踐
AUTOSAR架構(gòu)下XCP DAQ功能配置實(shí)現(xiàn)
AUTOSAR項(xiàng)目實(shí)戰(zhàn)(7)-程序的啟動(dòng)地址分析
AUTOSAR項(xiàng)目實(shí)戰(zhàn)(8)-Load Bus Error異常問題分析
AUTOSAR架構(gòu)下ECU休眠后連續(xù)發(fā)送NM報(bào)文3S后ECU網(wǎng)絡(luò)才被喚醒問題分析
Autosar架構(gòu)下如何測(cè)量Fee的切頁(yè)時(shí)間
ComM模塊中的PNState和ChannelState間的關(guān)系
AUTOSAR架構(gòu)下TC3xx芯片是如何將一幀CAN報(bào)文發(fā)送出去的
Can_Write返回Busy后報(bào)文會(huì)被丟棄嗎
實(shí)現(xiàn)TC3xx芯片F(xiàn)lashDriver的關(guān)鍵內(nèi)容
AUTOSAR架構(gòu)下SPI數(shù)據(jù)異步DMA收發(fā)具體實(shí)現(xiàn)
AUTOSAR架構(gòu)下SPI數(shù)據(jù)同步收發(fā)具體實(shí)現(xiàn)
基于Tricore芯片ADC模塊關(guān)鍵概念詳解
AUTOSAR架構(gòu)下Lin報(bào)文能正常收發(fā)的必要條件
AUTOSAR架構(gòu)下WDG模塊軟硬件功能詳解
AUTOSAR架構(gòu)下TC3xx芯片Lin報(bào)文收發(fā)詳解
AUTOSAR架構(gòu)下TC3xx芯片是如何將一幀CAN報(bào)文接收上來的
SMU Bring up關(guān)鍵步驟及注意事項(xiàng)
End
歡迎點(diǎn)贊，關(guān)注，轉(zhuǎn)發(fā)，在看，您的每一次鼓勵(lì)，都是我最大的動(dòng)力！
汽車電子嵌入式
微信掃描二維碼，關(guān)注我的公眾號(hào)
