read/write EEPROM on 18F8520

[WizardOfAz]

Anybody that knows how to do it want to summarize how to read and write the EEPROM on the 18F8520?

There are some functions in the C18 libraries for EE access, but looks like they use I2C and I don't thinks that's needed for the on-chip EEPROM. The compiler also has provision for declaring variables in EEPROM (the rom storage qualifier) and says it generates the TBLWT instruction to write to it, but warns that there may be more code than that requires. Indeed, the 18F8520 data sheet gives all the details, using special regs EECON1, EECON1, TABLAT and TBLPTR. So do we drop into assembly to use EEPROM or is there some library support for it? Anybody want to provide the functions?

EDIT: it's actually EECON1, EECON2, EEDATA, EEADRH, EEADR that are used for EEPROM access. The regs noted above are for accessing program flash memory.

Also - the data sheet says we have 1024 bytes of EEPROM. Why does IFI say we only have 255 bytes? Is the rest of it reserved for their use or is it a typo or what?

Thanks for any help.

Bill Bennett

[Random Dude]

[Edit] As to why they claim you only have 255 bytes? I don't know. There appears to be nothing in there at all. And I can write to bytes >0xFF so not really sure
[/edit]

This should suit you needs:

unsigned char readEE(unsigned char addrH,unsigned char addrL)  {
  	EEADRH = addrH;
 	EEADR =addrL;

    	  
  	EECON1bits.EEPGD =0;
  	EECON1bits.CFGS =0;
  	EECON1bits.RD =1;


    	return EEDATA;
}

void writeEE(unsigned char addrH,unsigned char addrL,unsigned char data)
{
  	EEADRH = addrH;
  	EEADR =addrL;
  	EEDATA = data;

  	  	//following as per spec. sheet
  	EECON1bits.EEPGD =0;
  	EECON1bits.CFGS =0;
  	EECON1bits.WREN =1; 
 	INTCONbits.GIE = 0;
  	EECON2 = 0x55;
  	EECON2 = 0xAA; 
 	EECON1bits.WR = 1;
  	INTCONbits.GIE = 1;
  	EECON1bits.WREN = 0;
}

[WizardOfAz]

Thanks for the code.

I suppose the reason you don't have to block interrupts throughout both functions is that interrupt state save process saves and restores the registers, but you have to make sure the write process itself is not interrupted, which could corrupt the slow write if the address or data was changed before it completed.

Thanks again.

[IrisLab]

Couple of questions...

1. Can you explain addrH, addrL, and data a little more? For readEE, are these the locations of the high and low byte in the EEPROM where you want to write? What are typical values for these addresses, if so? For writeEE same thing?

2. I read in another thread that you (or someone) is developing a copyCat (?) where you'd record user input into the EEPROM. How big (bytes) is the EEPROM? Do you have sample code for the CopyCat?

I'm new to the forum...so I hope I'm asking the right questions in the right place.

Thanks!

Originally Posted by Random Dude

[Edit] As to why they claim you only have 255 bytes? I don't know. There appears to be nothing in there at all. And I can write to bytes >0xFF so not really sure
[/edit]

This should suit you needs:

unsigned char readEE(unsigned char addrH,unsigned char addrL)  {
  	EEADRH = addrH;
 	EEADR =addrL;

    	  
  	EECON1bits.EEPGD =0;
  	EECON1bits.CFGS =0;
  	EECON1bits.RD =1;


    	return EEDATA;
}

void writeEE(unsigned char addrH,unsigned char addrL,unsigned char data)
{
  	EEADRH = addrH;
  	EEADR =addrL;
  	EEDATA = data;

  	  	//following as per spec. sheet
  	EECON1bits.EEPGD =0;
  	EECON1bits.CFGS =0;
  	EECON1bits.WREN =1; 
 	INTCONbits.GIE = 0;
  	EECON2 = 0x55;
  	EECON2 = 0xAA; 
 	EECON1bits.WR = 1;
  	INTCONbits.GIE = 1;
  	EECON1bits.WREN = 0;
}

[Random Dude]

Originally Posted by IrisLab

Couple of questions...

1. Can you explain addrH, addrL, and data a little more? For readEE, are these the locations of the high and low byte in the EEPROM where you want to write? What are typical values for these addresses, if so? For writeEE same thing?

Here is a slightly improved version of the read/write function. I've combined addrH and addrL into address. Valid values for address should be 0-1024 (since the size of the EEPROM is 1KB). (IFI originally said that it was only 256 but they have since corrected their mistake)

data can be any char value (0:255 for unsigned; -128:127 for signed)

This is applicable to both readEE() and writeEE()

 
char readEE(unsigned short address) {

// Load address into address register
EEADRH = ((address>>8)&0x03);   //Bits 2-7 are masked off since EEPROM is only 1KB
EEADR =(address&0xFF);

//Configuration as per manual
EECON1bits.EEPGD =0;
EECON1bits.CFGS =0;
EECON1bits.RD =1;


return EEDATA;
}

void writeEE(unsigned short address, char data)
{
EEADRH = ((address>>8)&0x03);
EEADR =(address&0xFF);
EEDATA = data;

//Configuration as per manual
EECON1bits.EEPGD =0;
EECON1bits.CFGS =0;
EECON1bits.WREN =1; 
INTCONbits.GIE = 0;
EECON2 = 0x55;
EECON2 = 0xAA; 
EECON1bits.WR = 1;
INTCONbits.GIE = 1;
EECON1bits.WREN = 0;
}

Originally Posted by IrisLab

2. I read in another thread that you (or someone) is developing a copyCat (?) where you'd record user input into the EEPROM. How big (bytes) is the EEPROM? Do you have sample code for the CopyCat?

EEPROM size is 1024 bytes (1KB)

I am not the person working on the CopyCat program. Post in this thread for any questions on CopyCat.

Originally Posted by IrisLab

I'm new to the forum...so I hope I'm asking the right questions in the right place.

Thanks!

Welcome! And, yes you are in the right location.

[mightywombat]

I am still learning and acquainting myself with all these crazy ideas about EEPROM and ROM and RAM and memory locations and all that stuff. I know how to program in C and have written some code for the eduBOts but its nothing too advanced. I want to load a table/list of sin values (0:90 degrees, to maybe 3 or 4 place accuracy) into ROM so that I can access it from my main program loop. When and how do I read it in? I understand that you use the above read and write functions but WHERE and WHEN do you use them?

[WizardOfAz]

Although you might want to finish understanding how to manage the ram, program memory, and eeprom, eeprom is probably not the best choice for your sine table. The C compiler allows putting read-only data in program memory. The loader will automatically put your table in program rom, and the compiler will automatically generate the appropriate code to access it there. This would be the easiest way to do your sin table. You wouldn't have to read it in or anything special. Just declare it to be in rom, like this:

unsigned char /* or whatever you want */ rom sinTable[256] = {0, 5, 10, 15, ... more table values...};

The rom keyword will cause this table to be stored in rom rather than ram, the latter being the much more limited resource. Declared this way, you can access it in C just like any other array. Just don't try to store to it.

Now, if you really want to put it in EEPROM, the simplest way would be to declare the table as above, run a for loop to copy the table to EEPROM using writeEE provided by Random Dude in the prior post. Download the program and run it, just once, and the EEPROM will be saved until changed by some other program. After that download a program that accesses the table using readEE.

A more typical use for the EEPROM would be, for example, calibration of a resistive sensor. If for some reason the sensor calibration changes often, you could have code that is always loaded that can run a calibration sequence and store the resulting data in EEPROM, and the normal runtime could access the current calibration from that table.

Have fun.

Bill

[mightywombat]

AH-HA. I had misunderstood what the EEPROM was. As I understand it now it is 1KB of space where you put code that is run every time the bot is powered on?? No. That doesn't seem quite right. I'm not sure. I guess I thought that EEPROM was just the ROM, but its something different. Is there any threads out there or webpages that I can read that deal with RAM ROM EEPROM and memory storage to clarify my young mind?
thanks. you rock.
Bill

[WizardOfAz]

You can't put code in the EEPROM, there's no provision for executing it there. It's 1K of space where you can put "stuff" that you want to be there even after the power is turned off and back on. In that sense, it's not very different than program rom. The main distinction is that it's a little harder to read than data stored in program memory, but easier for your program to write.

To elaborate a bit on the sensor calibration, as an example of what the EEPROM is good for: We are building a prototype that has steering sensors on the wheels. The mechanical alignment of the sensors is hard to predict accurately, and likewise the proportional relationship between the sensor readout and the angular position is hard to know in advance. So we have a calibration routine that can be run at any time by a switch at the OI. During this calibration routine, the operator can put the wheels at several specific positions and "click" the joystick trigger to store the sensor reading at those positions in EEPROM. These readings are later used to interpolate the angle to a reasonable accuracy during regular operation of the 'bot.

A reasonable rule of thumb for the ram, program rom, and eeprom is:
- program rom for code, and for data known at compile time
- ram for read/write variables at run time
- eeprom for data that is determined at run time and needs to be stored permanently so it is known at next run of the 'bot

Hope this helps clarify.

Bill

[mightywombat]

Those last three lines made it soooo clear. Thanks so much for your help and assistance. One last question. If I read something into ROM will it still be there the next time I turn on the bot?

[WizardOfAz]

Program rom and EEPROM are both non-volatile memory - they will be there, even through a power off/on sequence, until re-written with new data. Variables in ram go away of course.

Bill

[mightywombat]

Alrighty. With any luck this will be my final question. We have 1800 bytes of variable space. Is there any set space for RAM and ROM? Or can you declare any amount of RAM and ROM as long as it isn't more that 1800 bytes?

[WizardOfAz]

Program rom is 32k. This is all the all the program you write, plus any data you declare as rom, plus any library code you link in (in the default code, this is clib.lib and 18f8520user.lib). The default framework takes about 8k, so if you don't change that, you've got about 24k for your program and rom data.

The program rom usage can be examined in the .map file produced after you do a build. It's not real nice to read, but look for the lines after "program memory usage" for a simple summary of how much you're using.

Your non-rom variables go in the 1800 bytes of ram. I don't see any nice summary of total usage for this, but look at the lines for "DATA". I also haven't figured out why the number is 1800, the chip has 2048 bytes. Maybe what they're saying is library code needs 200 bytes, and there's 1800 bytes left. Not sure.

The EEPROM is 1024 bytes, and usage won't show up in the link map, since the addresses are all generated at run time. The linker doesn't know anything about this. Your program has to determined what is stored at 0, what at 1, and so on.

Bill

[WizardOfAz]

A little more info about writing the EEPROM - it takes time. To write one byte takes about 4 ms. Since the loop time is 26 ms (or 17 on the EDU-RC), if you try to write a few bytes at once, you use up more than all of the time. Even worse, if you don't wait for the write to finish, only the first write will work.

I am working on some code to keep a small queue of bytes to write that will wait for each to write before writing the next. Will post when I think it's working. Anybody else have thoughts on how best to manage this issue?

Bill

[Larry Barello]

Section 7.2 of the data sheet mentions an EEwrite complete interrupt.