類似AT24C0x這類使用I2C讀寫的EEPROM，相信很多人都使用過。但后臺還是有很多相關的問題，今天寫點相關內(nèi)容給大家。

1I2C讀寫EEPROM基礎原理

市面上大部分使用I2C通信的EEPROM，控制時序和讀寫流程都相同，或類似。我們最常見的就是AT24C0x這類EEPROM。

I2C通信原理，這個問題關注我較早的朋友看過我分享的內(nèi)容，應該很多使用MCU進行底層開發(fā)，或者學習底層的朋友都知道I2C通信原理。

如果還有不明白I2C通信基礎的朋友，可以回看一下我之前分享的文章：

1.STM32F10x_模擬I2C讀寫EEPROM

2.STM32F10x_硬件I2C讀寫EEPROM

以前寫文章沒怎么注重排版，閱讀體驗不是很好，但內(nèi)容應該還是寫到位了。

還有，文中的參考代碼在我“底部菜單”下載區(qū)可以找到。

2

EEPROM底層驅(qū)動

真正實際做過項目的人都知道，好的底層驅(qū)動，會給上層應用開發(fā)帶來很大便利，節(jié)省開發(fā)時間，以及減少bug發(fā)生率。

而大部分初學者，或者應屆畢業(yè)生從事相關開發(fā)，一般很少考慮代碼的移植性，復用性，或者說容錯處理等問題。

下面，我簡單列兩點我在項目中，對EEPROM常用的幾項操作。

1.寫，再讀，驗證寫入成功

這種方法很好理解：寫入之后，再次讀去這部分數(shù)據(jù)，進行一一匹配，驗證是否與寫入數(shù)據(jù)一致。

一般我是會重復操作3次，也就是說：寫入，再讀取，如果超過3次都還失敗，那么我則放棄寫入，認為寫入失敗，或芯片異常。

這個方法可以簡單解決因異常導致寫入失敗的問題。

2.添加校驗信息

在上面一層讀驗證基礎上，對保存一些參數(shù)，我一般還會：在參數(shù)末尾添加類似“和校驗”，或“CRC校驗”。

假如你連續(xù)存儲一個有10字節(jié)的參數(shù)（數(shù)據(jù)結(jié)構），如果因異常修改了中間某一個字節(jié)參數(shù)，你讀出來進行校驗，發(fā)現(xiàn)不對，則認為這個參數(shù)無效。

添加這個校驗的目的相信從上面我舉例已經(jīng)明白，就是解決多字節(jié)參數(shù)中某個字節(jié)被惡意修改，導致這個參數(shù)無效的問題。

3.EEPROM在多任務中添加互斥鎖

使用過操作系統(tǒng)的朋友都知道，多線程訪問一個資源，一般都存在互斥的關系。簡單的說：一個資源，在同一時刻，只能被一個線程操作。

那EEPROM舉例：線程A在網(wǎng)EEPROM寫10字節(jié)數(shù)據(jù)，剛6個字節(jié)時，線程B想要搶占，往EEPROM寫入數(shù)據(jù)。你覺得線程A應不應該放棄I2C總線，讓線程B寫入呢？

答案肯定是不允許的，所以，就有了互斥鎖這么一說。也就是等先占用I2C總線的線程操作完，才釋放總線，讓其他線程進行操作。

這三點應該是我比較常用了，網(wǎng)上還有其他一些相關的容錯處理機制，感興趣的不妨搜索一下。

我這里就不貼代碼了，因芯片型號不同，應用不同，代碼就存在差異。但我們目的：在保證滿足應用的同時，需考慮代碼的移植、復用、以及容錯。

3

硬件、軟件I2C

我們代碼應該使用硬件I2C？ 還是軟件模擬I2C？

這個問題有許多朋友都在問，說句實話，遇到這類有爭議的問題，我一般還是保持中立。

我遇到這類問題，一般會根據(jù)實際情況而定。比如：你的I2C產(chǎn)品要提供給一些不同平臺用戶，進行二次開發(fā)，我覺得軟件IO模擬比較好，方便用戶嘛。

假如你們公司開發(fā)的產(chǎn)品都使用STM32這家公司芯片開發(fā)I2C產(chǎn)品，我覺得，你代碼可以使用硬件I2C。

4

STM32硬件I2C問題

相信很多朋友都知道這個問題，在官網(wǎng)也能找到相關說明，這里再描述一下吧。

問題描述

如果沒有在傳輸當前字節(jié)之前處理EV7、 EV7_1、 EV6_1、 EV2、 EV8和EV3事件，有可能產(chǎn)生問題，如收到一個額外的字節(jié)、兩次讀到相同的數(shù)據(jù)或丟失數(shù)據(jù)。

暫時解決辦法

當不能在傳輸當前字節(jié)之前和當改變ACK控制位送出相應脈沖之前，處理EV7、EV7_1、EV6_1、EV2、EV8和EV3事件時，建議如下操作：

1.使用I2C的DMA模式，除非作為主設備時只接收一個字節(jié)。

2.使用I2C的中斷并把它的優(yōu)先級設為最高級別，使得它不能被中斷。