|
本帖最后由 ltbytyn 于 2013-12-27 14:22 编辑
本文中将使用MB85RC64来代指MB85RC64PNF_G_JNERE1。 前段时间申请到了富士通的MB85RC64（FRAM，铁电随机存取存储器）。看资料MB85RC64与传统的24C64（E2PROM）完全兼容（存储空间、封装以及管脚完全一样）。与E2PROM相比，FRAM具有更快的写入、更高耐久力和更低功耗等优势。 除此之外，相比较24C64，MB85RC64还有1个大的改进。论坛上面看了前面不少人写的关于FRAM的使用体会，大家似乎都没有注意到这一块。容我卖个关子，在讲MB85RC64这个特点之前，先说说24C64。 说到24C64，我印象比较深刻，4年前的一个项目中用到过，当时做这一块时下了一番功夫。在这里我可以把当初的体会分享一下。 24C64支持字节写和页写两种方式。 字节写：一次写一个字节数据。 页写：一次最多只能写32个字节。 事实上，我们通常用到字节写的几率比较低（因为通常保存的数据多数大于1个字节，比如故障信息、系统参数等，多大于1个字节。只有少数特殊情况保存1个字节。当然也可以用字节写的方式保存超过1个字节的数据，只不过把通过1次页写就能完成的任务拆分成多次字节写，效率明显比较差。除一些特殊应用外，一般不推荐那么做。），主要使用集中在页写方式。就以页写作为重点介绍。 我们举个简单例子说说页写。 1、将数组a[32] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32}写入24c64,起始地址0x00000,通过页写方式连续写入32个数据，结果如下图。 2、将数组a[32] = {1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32}写入24c64,起始地址0x00005,我们期望得到的结果如图2所示，事实上通过页写方式连续写入32个数据，结果如图3所示。 造成这种结果的原因是：24C64通过页写的时候，低5位地址随写入数据自动加1，高位地址在页写过程中不变。当低5位地址为0b11111(31)时，在写入1个字节数据，低5位地址从0开始重新计数，在此过程中，高位地址不变，先前写入的数据将被覆盖。所以页写的时候需特别注意不能过写，造成前面数据的覆盖，引起数据丢失。 因此要达到预期的结果，需要执行2次页写。 第一次页写，将起始地址设为0x0005,将a[0]~a[26]共27个字节通过页写写入24C64。 第二次页写，将起始地址设为0x0020,将a[27]~a[31]共5个字节通过页写写入24C64。
我以前的做过低压配电集中器，通过485与多个终端采集器终端相连。负责收集各个终端实时数据，并记录各个终端的故障信息。当时用到24C64，主要用于记录设备参数及故障信息，便于以后查找问题。 1条故障信息由12个字节组成，故障信息格式如下： 将0x200~0x4FF区间划为故障信息存储区，64条*12字节 = 768字节。当超过64条时，重新从0x200开始记录，将最早的第1条故障记录覆盖掉。 首先在24C64中划分1块区域专门存放故障信息（设定最多记录64条故障信息）。 ........ 通过上表，我们可以看到第1、2、4、5、7、8条故障信息可以通过1次页写就可以保存。但第3、6条故障信息都需要拆分故障信息，并且通过2次页写才能完成故障信息保存。我们也可以观察到第3、6条故障信息数据两次拆分不一致。第3条故障信息拆为8+4，两次页写。第6条故障信息拆为4+8，两次页写。两次拆分虽不一样，多少还有点规律。如果不凑巧，1条故障信息总长为奇数，规律性就更差。故障信息写24C64的函数就更复杂。
struct ERR //故障记录信息索引表 { uchar num; //当前故障记录总数量 uchar op; //当前故障记录存储位置 uchar DIS_op; //当前故障显示指针位置 uchar YE_num; //当前故障显示页码 }; 每次记录新故障信息时，都需要计算当前故障信息是否需要拆分页写，如何拆分页写，很是麻烦。所以24C64页写的32字节限制在连续写入长数据时让人很受伤。24Cxx系列页写在不同型号中各不相同。
MB85RC64能给我们带来什么？ 比较了一下MB85RC64和CAT24WC64的datasheet，它们的特点基本上一致。MB85RC64的亮点就是擦写次数是CAT24WC64的1000000倍，更适合频繁擦写数据。
看到页写功能时，我看到了与24C64(或者说24Cxx系列)的不同。 If additional 8bits are sent after the same command as Byte Write, a page write is performed. If more bytes are sent than will fit up to the end of the address, the address rolls over to 0000H. Therefore, if more than 8KBytes are sent, the data is overwritten in order starting from the start of the FRAM memory address that was written first. Because FRAM performs write operations at bus speed, the data will be written to FRAM after the ACK response finishes immediately. 官方说明没有提到页写长度限制。只是提到：当页写地址超出存储器的末位地址，访问地址将跳转0000H，从开始地址写数据，以前写数据会被覆盖。 我对这次测试充满了期待。如果没有了页写限制，和24C64(EEPROM)相比，所有故障的记录将不再考虑拆分和多次页写，只需通过一次页写就可以完成，大大提高效率和程序可读性。
测试硬件：TMS320F28027（TI官方：C2000 LaunchPad） + MB85RC64 测试硬件说明：使用TMS320F28027自带I2C模块 硬件接口：GPIO33/SCLA <---> MB85RC64_SCL GPIO32/SDAA <---> MB85RC64_SDA GND <---> MB85RC64_WP （MB85RC64写保护功能与24C64相同，故不做测试） GND <---> MB85RC64_A0/A1/A2 (读操作器件地址为0xA0/写操作器件地址为0xA1) GND <---> MB85RC64_GND +3.3v <---> MB85RC64_VCC
照片上能隐约能看到芯片表面RC64标识。 测试目的：测试MB85RC64页写功能有无最大32个字节数量限制？ 测试步骤： #define I2C_SLAVE_ADDR 0x50 //TMS320F28027 I2C模块中，设置器件地址寄存器不含读写位。故右移1位。即（0xA0>>1） #define I2C_NUMBYTES 800 #define I2C_EEPROM_HIGH_ADDR 0x00 #define I2C_EEPROM_LOW_ADDR 0x00 Uint8 TxdData[I2C_NUMBYTES]={0x00}; Uint8 RxdData[I2C_NUMBYTES]={0x00}; 1、通过页写连续向MB85RC64写入800个字节(TxdData[I2C_NUMBYTES])数据，远大于页写32字节限制。 初始化后的数据，见下图。 写MB85RC64。 2、连续从MB85RC64读出800个字节(RxdData[I2C_NUMBYTES])数据，观察读出数据是否与写入的相同。
查看接收缓冲区数据。 接收数据和发送的数据相比较，完全一致。故说明：与24C64（24Cxx系列）相比较，MB85RC64(FRAM)不存在页写最大32字节限制。在记录故障信息时，一次页写即可完成故障记录。大大提高效率和程序可读性、同时降低了程序复杂性,为开发人员提供了极大的便利。这是我试用富士通FRAM的最大发现。
| 
提升卡
变色卡
千斤顶
1/7 
京公网安备 11010802033920号
Copyright © 2005-2025 EEWORLD.com.cn, Inc. All rights reserved
