who's going to use eprom

[Edourdo]

respond back to me if you are and explain why

[JBotAlan]

(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

[kaszeta]

Originally Posted by Edourdo

respond back to me if you are and explain why

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.

[EHaskins]

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?

[Eric Finn]

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

[dpick1055]

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

[Kingofl337]

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.

[Shinigami2057]

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

[DonRotolo]

Originally Posted by Shinigami2057

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

[Donut]

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?

[kaszeta]

Originally Posted by Donut

For those of you using EEPROM; what's the advantage in storing values in there rather than in ROM data?

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

[Donut]

Originally Posted by kaszeta

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.

[Astronouth7303]

Originally Posted by Donut

For those of you using EEPROM; what's the advantage in storing values in there rather than in ROM data?

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.

[Shinigami2057]

Originally Posted by Astronouth7303

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.

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.

[steveg]

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.