respond back to me if you are and explain why 
(Raises hand and waves it around like a little kid) I know, but Iâm not tellingâŚ
Just kidding. Itâs for auton, so I donât have to wait for the entire HEX file to download. Over and over.
I might post my code after this year, but itâs my pride and joy at the moment and I donât want it to be a dump-in solution for anyoneâŚnot yetâŚ
JBot
One of our guys wrote some code that
(a) read key autonomous values from eeprom
(b) Provided a serial interface for resetting said values.
The idea was to not have to reload the RC just to adjust how far the robot was driving during autonomous mode.
Iâm working on something like JBotAlanâs, but it isnât finished.
Iâm running a modified version of Kevinâs code so weâre using it for camera/tracking config.
I might have some other uses, but Iâm moving those to a DOSonChip module. 
Why do you want to know about other peopleâs eeprom use?
Weâre using EEPROM for drive calibration and storing arm positions.
Could someone please explain to me what eeprom is and what the advantages of using it are? Iâm just a little confused. Thanks.
Processor has a small amount of eprom space you can store values in that will remain in the RC even after it is powered down.
Just remember that EPROM and EEPROM are two different things - the first is Erasable, although only through strong UV light, while EEPROM is Electronically Erasable. The PIC18F has the latter, which is lucky for us 
To clarify further - the above is 100% correct - to erase an EPROM you need to expose it to Ultraviolet (UV) light for some minutes - not practical on a robot. To erase an EEPROM, you send an electrical signal to it - very practical on a robot.
To program either, you send it electrical signals.
Looking at it another way: Both are non-volatile ROM, but an EEPROM is more like RAM.
Don
Weâve considered it before, but we feel itâs just as easy to store all of the values for autonomous and other controls in ROM data and then just use a selector switch on the field.
For those of you using EEPROM; whatâs the advantage in storing values in there rather than in ROM data?
I wonder if itâs possible to erase an EEPROM by exposing it to UV⌠You would think that it would generate enough photocarriers to screw up its state.
Weâve always found that our autonomous modes needed adjustment in timing, distance, or speed settings once we got to competition (different carpet, etc.). Itâs nice to be able to change those instantly without having to download new code. (If youâve ever had to tinker with code on the sideline between finals round matches, you know how frustrating it can be to watch that progress bar move across the screen as the refâs keep telling you âyou need to be on the field nowââŚ)
I thought that was the fun part of the playoffs? 
Weâve never had much of a problem downloading code in time though, so I guess that wouldnât do us much good then.
there is a differance in eprom and eeprom, eprom is erased using âUVâ but eeprom is erased using an electronic signal.
We are going to use it to store PID constants while we are tweaking them. Waiting 2 minutes every time we want to change one of the constants does not sound fun.
EEPROM is perfect for control loop constants. You can hook up a controller to the OI to update a constant (say with a joystick wheel), and then press a button to âsaveâ the data.
Functionally, you can think of EEPROM as a âhard driveâ for your robot. Whatever you put in there stays even after you power off. But, like a hard drive, you are limited in space (though honestly thereâs plenty for most uses), and reading and writing is a bit slower than to working memory.
EDIT:Ignore this, and read page 15 of the MCC18 userâs guide instead. (Foot, meet mouthâŚ)
IIRC, when you declare a variable as âromâ, it is still stored in EEPROM, but the location is allocated by the linker. When you use Kevinâs library, you choose the location itself. Data is never stored in the program memory (flash). Also, âromâ variables are reset to default values when the program is downloaded.
Meaning you probably shouldnât be mixing the âromâ keyword and Kevinâs code.
If youâre really interested in the details, experiment. Look at the list file after playing with a rom variable. And yes, you can store to a rom variable.
This is not correct; the rom qualifier specifies that the variable be referenced in program (i.e. flash) memory, while the ram qualifier forces it into static RAM (where the near and far qualifiers also apply, but thatâs for using GSRs and SPRs in special ways, which not many people here would need). You should use the rom qualifier if youâre storing large arrays (i.e. lookup tables) in program memory. The qualifier is necessary so the compiler can generate the necessary table reads and writes to flash. EEPROM reads and write are done independently through the EECON, etc registers.