EEPROM Code

[Kevin Watson]

I've just posted software that can be used to read and write the Electrically Erasable Programmable Read-Only Memory (EEPROM) found in IFI's robot controllers. The code can be found here: http://kevin.org/frc. As always, if you find a bug in the code or a problem with the documentation, please let me know.

-Kevin


Here's the readme file:

The source code in eeprom.c/.h contains software to read from
and write to the Electrically Erasable Programmable Read-only 
Memory (EEPROM) contained within your robot controller's 
processor. Storing information in EEPROM has the advantage of 
being permanent, unlike Random Access Memory (RAM), which
gets reinitialized each time you reset or restart your robot
controller.
 
See the code in Process_Data_From_Master_uP() for an example
application of this software.
 
This source code will work with the Robovation (A/K/A EDU-RC) 
robot controller and the FIRST Robotics robot controller.
 
The included project files were built with MPLAB version 7.20.
If your version of MPLAB complains about the project version, 
the best thing to do is just create a new project with MPLAB's 
project wizard. Include every file except: FRC_alltimers.lib 
and ifi_alltimers.lib and you should be able to build the code.
****************************************************************
Three things must be done before this software will work 
correctly with your robot controller:
 
1) You need to add eeprom.c and eeprom.h to your project.
Do this by copying the two files to your project directory
and then right clicking on "Source Files" in the project
tree, selecting "Add Files...", if necessary, navigate to
the project directory and then double click on eeprom.c.
Repeat the above procedure for eeprom.h under "Header Files".
 
2) A #include statement for the eeprom.h header file must be 
included at the beginning of each source file that calls the 
functions in eeprom.c. The statement should look like this: 
#include "eeprom.h".
 
3) The function EEPROM_Write_Handler() function must be called
from Process_Data_From_Master_uP() each time it executes.
****************************************************************
Here's a description of the functions in eeprom.c:
 
EEPROM_Read()
Reads data from EEPROM.
 
EEPROM_Write()
Places new write data on the EEPROM write queue. This function
returns a value of one if there was an available slot on the
queue, zero if there wasn't. EEPROM_Queue_Free_Space() should
be called to determine if enough free space is available on
the queue before calling EEPROM_Write(). By default, there
are sixteen slots available. The number of usable slots is
defined in eeprom.h.
 
EEPROM_Write_Handler()
If buffered EEPROM write data is present (i.e., EEPROM_Write()
has been called), this function will write one byte to EEPROM 
each time it is called. A call to this function should be placed
in and called each time Process_Data_From_Master_uP() is called.
If, on average, you need to write more than one byte of data to
EEPROM each time Process_Data_From_Master_uP() is called, you can 
call it multiple times each loop. If you start experiencing wacky
behavior when your 'bot runs or get the red-light-of-death, you
might be attempting to write too much data too quickly. Because
it takes 2 milliseconds to write each byte of data to EEPROM and
all interrupts are disabled during this period, don't write data
to EEPROM when you need to service interrupts.
 
EEPROM_Queue_Free_Space()
Returns the number of free slots available on the EEPROM write
queue. This function should be called to determine if enough 
free space is available on the write queue before calling 
EEPROM_Write().

[CJO]

THANK YOU!!!!!!!!!

(Bows and kisses Kevin's feet)

The possibilities are so good.

P.S. Do you know if this will work on the VEXtroller?

P.P.S: Did I say thak you?


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(Rather than Double Post)

How does data need to be formatted when you pass it to the EEPROM_Write() function? Can you send variables by name?

Could you call this function using your printf/serial driver. For instance, type "Field Side: Left," and then have this set a variable (such as "rss" - robot start side") equal to 1 (for instance). And then have the handler write to the EEPROM so that when the robot is turned on again, it knows what side it is on without a switch.

Also, I am assuming that the read time is negligable compared to the write time (I.E. one does not need to woory about avoiding interrupts when reading?)

[Greg Marra]

Sweet.

We were considering using the EEPROM when we ran out of code space last year, and this ought to make it a lot easier to do.

Thanks!

[Kevin Watson]

Originally Posted by Greg Marra

Sweet.

We were considering using the EEPROM when we ran out of code space last year, and this ought to make it a lot easier to do.

Thanks!

Yes, EEPROM is a great place to locate, for example, trigonometric lookup table(s). A little piece of of code like this:

#include <math.h>
#include "eeprom.h"
 
unsigned int i;
unsigned char data;
 
//create a zero to ninety degree lookup table
for(i=0; i<=90; i++)
{
// wait, if necessary, for a free slot on the circular queue
while(EEPROM_Queue_Free_Space() == 0);
 
// normalize the output to the maximum value a byte variable can hold
data = (unsigned char)(255.0 * sin((float)i * 3.14159 / 180.0));
 
EEPROM_Write(i, data);
}

will generate one quadrant of a sine lookup table in EEPROM. Execute the code and you'll have a semi-permanent table in EEPROM that will allow you to very quickly solve sin(x) and cos(x).

-Kevin

[CJO]

Very cool, thanks.

[kc8nod]

Hi Kevin,

Thanks for all the effort, it looks great and we'll definately be using it. I'd like to make one suggestion though.
With so many novice progammers using your code, it's likely that someone will use the EEPROM_Write() function too much, even when the data doesn't need to be updated. A small change to EEPROM_Write() might avoid problems for these folks.

unsigned char EEPROM_Write(unsigned int address, unsigned char data)
{
     unsigned char return_value;

     // determine if this is really new data
     if(data == EEPROM_Read(address))
     {
          return_value = 1;
     }	
     else if(eeprom_queue_full == FALSE) // return error flag if the queue is full
     {
          // put the byte and its address on their respective circular queues
          eeprom_queue_data[eeprom_queue_write_index] = data;
          eeprom_queue_address[eeprom_queue_write_index] = address;

If the new data being written, is the same as the old data that's already there, then we never add it to the queue.

Thanks again for all the hard work.

[Kevin Watson]

Originally Posted by kc8nod

Hi Kevin,

Thanks for all the effort, it looks great and we'll definately be using it. I'd like to make one suggestion though.
With so many novice progammers using your code, it's likely that someone will use the EEPROM_Write() function too much, even when the data doesn't need to be updated. A small change to EEPROM_Write() might avoid problems for these folks.

unsigned char EEPROM_Write(unsigned int address, unsigned char data)
{
unsigned char return_value;
 
// determine if this is really new data
if(data == EEPROM_Read(address))
{
return_value = 1;
}	
else if(eeprom_queue_full == FALSE) // return error flag if the queue is full
{
// put the byte and its address on their respective circular queues
eeprom_queue_data[eeprom_queue_write_index] = data;
eeprom_queue_address[eeprom_queue_write_index] = address;

If the new data being written, is the same as the old data that's already there, then we never add it to the queue.

Thanks again for all the hard work.

Thanks, it's a good idea and I considered it, but I'd also have to search the queue for writes to the same address as well, which would make the code a bit more complex. If I had to consider all of the wacky things that people do with my code and try to save them from themself, the code would be even more complex and bloated <grin>.

-Kevin

[CJO]

So, to write "127" to the first data block would be

EEPROM_Write(1, 127)

and to get that value would be:

EEPROM_Read(1)

which would return 127?

[Kevin Watson]

Yes, that will work.


-Kevin

[Rickertsen2]

hrmm. I love the simplicity of this. Last year, i wrote overly complex EEPROM routines to allow data of arbitrary length to be stored with dynamic allocation and FAT table. It turns out, not a whole lot of that functionality was ever needed. A scheme like yours would have workded just fine. It makes me want to smack myself in the face and say "duh".

[Tom Bottiglieri]

How much variable is space is available in the onboard EEPROM?

[Kevin Watson]

Originally Posted by Kevin Watson

Yes, EEPROM is a great place to locate, for example, trigonometric lookup table(s). A little piece of of code like this:

#include <math.h>
#include "eeprom.h"
 
unsigned int i;
unsigned char data;
 
//create a zero to ninety degree lookup table
for(i=0; i<=90; i++)
{
// wait, if necessary, for a free slot on the circular queue
while(EEPROM_Queue_Free_Space() == 0);
 
// normalize the output to the maximum value a byte variable can hold
data = (unsigned char)(255.0 * sin((float)i * 3.14159 / 180.0));
 
EEPROM_Write(i, data);
}

will generate one quadrant of a sine lookup table in EEPROM. Execute the code and you'll have a semi-permanent table in EEPROM that will allow you to very quickly solve sin(x) and cos(x).

-Kevin

Ugh, I just realized this code will cause the red-light-of-death. Anyone care to venture a guess as to why it won't work? I'll post corrected code tomorrow-ish.

-Kevin

[CJO]

It will write only when there is no free space in the write que?

[Matt Krass]

It risks getting caught in an infinite loop waiting for the queue and breaks the comm sync on the controller?

[CJO]

Originally Posted by Matt Krass

It risks getting caught in an infinite loop waiting for the queue and breaks the comm sync on the controller?

Which is the ultimate result of what I mentioned (put more nicely).