who's going to use eprom
 

:D respond back to me if you are and explain why :)

Re: who's going to use eprom
 

(Raises hand and waves it around like a little kid) I know, but I'm not telling...:D

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

Re: who's going to use eprom
 

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.

Re: who's going to use eprom
 

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?

Re: who's going to use eprom
 

We're using EEPROM for drive calibration and storing arm positions.

Re: who's going to use eprom
 

Could someone please explain to me what eeprom is and what the advantages of using it are? I'm just a little confused. Thanks.

Re: who's going to use eprom
 

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.

Re: who's going to use eprom
 

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 :p

Re: who's going to use eprom
 

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

Re: who's going to use eprom
 

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?

Re: who's going to use eprom
 

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.

Re: who's going to use eprom
 

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"....)

Re: who's going to use eprom
 

I thought that was the fun part of the playoffs? :p We've never had much of a problem downloading code in time though, so I guess that wouldn't do us much good then.

Re: who's going to use eprom
 

there is a differance in eprom and eeprom, eprom is erased using "UV" but eeprom is erased using an electronic signal.

Re: who's going to use eprom
 

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.

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.