chipKIT® Development Platform

Inspired by Arduino™

EEPROM Lib

Created Fri, 15 Jul 2011 08:34:00 +0000 by ECO'Nergy

ECO'Nergy

Fri, 15 Jul 2011 08:34:00 +0000

I've tried to test the EEPROM library ,-with the examples on the lib directory- and it seems that doesn't work .. Any value I put on EEPROM memory return always 0 (ZERO). I use the last MPIDE and a UNO32.

Is someone have the same problem? Have I fogotten do to something? Or the Lib doesn't work on UNO32?

thanx..

sierrasmith71

Fri, 15 Jul 2011 14:44:07 +0000

I've tried to test the EEPROM library ,-with the examples on the lib directory- and it seems that doesn't work .. Any value I put on EEPROM memory return always 0 (ZERO). I use the last MPIDE and a UNO32. Is someone have the same problem? Have I fogotten do to something? Or the Lib doesn't work on UNO32? thanx..

I seem to remember that the UNO32 does not contain any EEPROM memory?.......

David G :o

sierrasmith71

Fri, 15 Jul 2011 15:40:59 +0000

I tried the EEPROM library and it did not work for me either...only zeros returned when read.

I had read somewhere in this forum that a flash 'workaround' was written, not sure how it is invoked..One would suppose that if the EEPROM library was included that its function would be available?

I did notice that the compiled code for the example -EEPROM Read- (which is very small) is huge ..30.8K!

David G

Revilones

Fri, 15 Jul 2011 16:47:37 +0000

It could be the code your using here is an example project that might work for you. If should load the alphabet into EEPROM then it will spit it back out to you on the serial monitor

/*
 * EEPROM Read
 *
 * Reads the value of each byte of the EEPROM and prints it 
 * to the computer.
 * This example code is in the public domain.
 */

#include <EEPROM.h>

// start reading from the first byte (address 0) of the EEPROM
int address = 0;
byte value;
char * myAlpha = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";

void setup()
{
  Serial.begin(9600);

  //Step through the alphabet and write them into eeprom
  for(int i=0; i < 26; i++)
  {
    EEPROM.write(i, *myAlpha++);
  }
}

void loop()
{
  // read a byte from the current address of the EEPROM
  value = EEPROM.read(address);
  
  Serial.print(address);
  Serial.print("\t");
  Serial.print(value);
  Serial.println();
  
  // advance to the next address of the EEPROM
  address = address + 1;
  
  // there are only 512 bytes of EEPROM, from 0 to 511, so if we're
  // on address 512, wrap around to address 0
  if (address == 26)
    address = 0;
    
  delay(500);
}

Best of Luck

-Revilones

sierrasmith71

Fri, 15 Jul 2011 18:56:57 +0000

Revilones:

I loaded and ran your code and it indeed appears to work.

The serial monitor shows the contents of the EEPROM memory locations just to be what was written in the setup portion of your code. What was different from what I did was that I first wrote the EEPROM and the loaded a read program ....

I tried doing that with your code by commenting out the write code in setup and loading that (after first running the complete code ) and the result was the same as my attempt....all zeros..I put in the " ,DEC" in the Serial.print(value,DEC); because without it I was just getting the address printed , I added the , DEC to see if there were any non printing ASCII characters there...yup 0! My thinking is that if indeed the data had been indeed written into Flash (mock EEPROM) that it would still be there after another program had been loaded..but perhaps this is not so, or it appears not to be so. Does the bootloader clear all the Flash?

/*
 * EEPROM Read
 *
 * Reads the value of each byte of the EEPROM and prints it 
* to the computer.
 * This example code is in the public domain.
 */

#include <EEPROM.h>

// start reading from the first byte (address 0) of the EEPROM
int address = 0;
byte value;
char * myAlpha = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";

void setup()
{
  Serial.begin(9600);

  //Step through the alphabet and write them into eeprom
  //for(int i=0; i < 26; i++)
  //{
  // EEPROM.write(i, *myAlpha++);
  //}
}

void loop()
{
  // read a byte from the current address of the EEPROM
  value = EEPROM.read(address);
  
  Serial.print(address);
  Serial.print("\t");
  Serial.print(value,DEC);
  Serial.println();
  
  // advance to the next address of the EEPROM
  address = address + 1;
  
  // there are only 512 bytes of EEPROM, from 0 to 511, so if we're
  // on address 512, wrap around to address 0
  if (address == 26)
    address = 0;
    
  delay(500);
}

What is it that I am missing here or doing wrong?

David G.

sierrasmith71

Sat, 16 Jul 2011 16:59:57 +0000

The 30.8K example EEprom Write sketch is explained ! see: [url]http://chipkit.org/forum/viewtopic.php?f=17&t=188&p=830&hilit=eeprom#p830[/url]

"by GeneApperson » Fri Jun 24, 2011 1:54 pm

The PIC32 parts don't have internal EEPROM. In both the Uno32 and the Max32, the last 4K of the program flash is reserved for use to simulate EEPROM. However, due to wearout limits of the flash (it's only rated for 1000 erase cycles) the flash can't be direct mapped to eeprom. The library treats the 4K as content addressable memory and stores both the eeprom address and the value in a 32 bit word. The result is 1Kbyte of simulated EEPROM and a page erase doesn't have to occur until 1K writes have occured. GeneApperson Posts: 21Joined: Wed Jun 01, 2011 4:53 pmLocation: Pullman WA"

So be prepared to use a lot of program Flash space when invoking eeprom.h on a PIC based board.

Also don't use the Arduino EEprom examples and expect them to work (except within one sketch), and, apparently, there is no need to put a delay between EEprom writes when using a UNO32 or MAX32 as it is neccessary when doing EEprom writes in an Arduino AVR based board (EEproms are really slow in writing speed).

More details need to be posted on the ChipKit Wiki to alert users on what to expect with the ChipKit EEprom routines!

David G.

GeneApperson

Sat, 16 Jul 2011 18:21:35 +0000

So be prepared to use a lot of program Flash space when invoking eeprom.h on a PIC based board. David G.

David,

There won't be any more flash space being used by the inclusion of eeprom.h. The last 4K of flash is always reserved by the boot loader and the linker script. The linker knows not to load any code in that memory. The content of the simulated eeprom should be preserved between different sketches, as the boot loader doesn't erase the entire chip when loading a new sketch. It only erases the pages that are being programmed by the new code image.

If it is the case that the simulated eeprom contents isn't being preserved, that would probably indicate a bug in the boot loader, but I don't believe that is happening.

One area of Mega compatibility that currently isn't being preserved by the Max32 is the amount of simulated eeprom. Right now, only 1K of simulated eeprom is supported. The ATmega2560 on the Mega has 4K of eeprom. The amount of simulated eeprom supported by the system can be modified by small changes to the eeprom library, boot loader, and linker script. A knowledgeable user could adjust the amount of simulated eeprom up to any amount desired (although going in blocks of the PIC32 flash page size would be a good idea)

Gene Apperson Digilent

sierrasmith71

Sat, 16 Jul 2011 19:42:55 +0000

David, There won't be any more flash space being used by the inclusion of eeprom.h. The last 4K of flash is always reserved by the boot loader and the linker script. The linker knows not to load any code in that memory. The content of the simulated eeprom should be preserved between different sketches, as the boot loader doesn't erase the entire chip when loading a new sketch. It only erases the pages that are being programmed by the new code image. If it is the case that the simulated eeprom contents isn't being preserved, that would probably indicate a bug in the boot loader, but I don't believe that is happening. One area of Mega compatibility that currently isn't being preserved by the Max32 is the amount of simulated eeprom. Right now, only 1K of simulated eeprom is supported. The ATmega2560 on the Mega has 4K of eeprom. The amount of simulated eeprom supported by the system can be modified by small changes to the eeprom library, boot loader, and linker script. A knowledgeable user could adjust the amount of simulated eeprom up to any amount desired (although going in blocks of the PIC32 flash page size would be a good idea) Gene Apperson Digilent

Gene: What I meant by "be prepared to use a lot of program Flash space " was that the sketch size grew so much . The EEPROM example posted by Revilones complies to 2.2K for the Arduino UNO and 30.8K for the UNO32!

I am hard put to come up with a requirement for preserving the simluated or otherwise EEprom between sketches* , so it is no big deal as the simulated EEprom function works between resets and power up/down which is really what one wants. However it does confuse folks (me included) when they run the included EEprom examples (write, read, erase),in seperate sketches, which were written for "real EEproms" on the Arduino and subsequent reads, of previously written data, in a new sketch does not work.

Perhaps someone can present a sketch that shows writing to EEprom in one sketch ..loading a new sketch and reading back what was written.....

  • actually there is a requirement ; when one needs to modify an existing sketch that uses the simulated EEprom and there has been data written to EEprom that was collected by that sketch (calibration data, setpoints, indexes, whatever) ......that might end up being a real bother

Best regards

David G.

Revilones

Mon, 25 Jul 2011 16:37:52 +0000

Hello All,

I just wanted to say that the EEPROM Library is being worked on and it will hopefully be fixed and fully functional by the end of next week.

-Revilones

GeneApperson

Mon, 25 Jul 2011 17:48:53 +0000

Gene: What I meant by "be prepared to use a lot of program Flash space " was that the sketch size grew so much . The EEPROM example posted by Revilones complies to 2.2K for the Arduino UNO and 30.8K for the UNO32!

David,

Oops... my mistake. I'm not sure why the library is taking up so much space. There is a problem here that is being investigated.

You're right that there are reasons why the eeprom contents needs to be preserved between sketches. There is a bug that is probably an error in the linker script that is causing the simulated eeprom to not be placed in the memory reserved for it. This appears to be why the simulated eeprom is being erased between sketchs. It is being worked on.

Gene Apperson Digilent

jasonk

Wed, 03 Aug 2011 00:50:00 +0000

Tracking issues: https://github.com/chipKIT32/chipKIT32-MAX/issues/65 https://github.com/chipKIT32/chipKIT32-MAX/issues/25

sierrasmith71

Wed, 31 Aug 2011 03:03:34 +0000

I downloaded the latest release---20110822\mpide and tried to write to the "eeprom" in one sketch and then read it from another sketch..still no luck,,,,,only 0's .It still works within a sketch; write and then read back.

David Garrison :(

GeneApperson

Wed, 31 Aug 2011 17:13:55 +0000

David,

I'm sorry about this. I'll investigate and find out what is happening here.

Gene Apperson Digilent

sierrasmith71

Thu, 01 Sep 2011 19:22:17 +0000

David, I'm sorry about this. I'll investigate and find out what is happening here. Gene Apperson Digilent

Gene:

I thought that I should let you know that I am using an orignal UNO32 purchased in May of this year. I seem to remember some discussion that perhaps the bootloader was erasing all of the flash and that what was causing the eeprom to lose data between sketches.......

David G.