Re: who's going to use eprom
 

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.

Re: who's going to use eprom
 

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.

Re: who's going to use eprom
 

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.