|
|
|
![]() |
|
|||||||
|
||||||||
|
|
Thread Tools | Rate Thread | Display Modes |
|
#22
|
||||||
|
||||||
|
EEPROMs
A million cycles is a probably on the low end of actual times you can program an EEPROM, but even so, we have found ways around this problem in the past.
Even writing to the same address every time you can still run for over 400 minutes without hitting a million writes, large but not large enough, perhaps. We used a few tricks. #1, read the contents first, only write to them if there is a changed state. #2 move to another EEPROM address as you wear out the "real" EEPROM address. Basically keep track of how many addresses you've worn out -- increment the index after you find a write didn't take. To see if you have "worn out" an EEPROM address, check the contents after the write command. #3 Devote a programming slot to essentially nothing but this purpose. I have never run out of code space entirely. So, I always have a slot to burn (pardon the pun). Basically use a RUN 7 command to run to your EEPROM burning code and then at the bottom of the EEPROM burning code do a RUN X to get back to your regular code. If you have to burn up EEPROM addresses, better that they all be from the same programming slot -- once you've worn out an EEPROM address, it cannot be used for program space either -- this could be a problem if you burned up all the EEPROM space in slot 0 for example -- this would leave you with no way to even download code to jump to another slot -- an extreme example, perhaps, but not impossible. Something like this should work fine: ADDR_INDEX data 0 ADDR_STATUS data 0 (256) 'reserves 256 locations for your burning needs 'omit the zeroes above if you do not wish to overwrite the prior 'stored values when downloading new code temp1 var byte temp2 var byte status var byte do 'start of loop code read ADDR_STATUS, temp1 read ADDR_INDEX, temp2 if temp1 <> status then write ADDR_STATUS + temp2, status read ADDR_STATUS, temp1 if temp1 <> status then write ADDR_INDEX, temp2+1 if temp1 <> status and temp2 = 255 then gosub _EEPROM_Error 'rest of loop code loop While there are a lot of reasons not to write every time through the loop (it takes too much time being the biggest one in my opinion) a scheme like the above can effectively make your EEPROMs last forever (in FIRST time, at least). Joe J. P.S. the above code is right from my brain, I did not get our old code out or even check syntax on it. I believe it is sound, but make no promises. JJ Last edited by Joe Johnson : 19-03-2003 at 23:01. |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| How much planning goes into your robot? | Jnadke | General Forum | 41 | 29-01-2006 21:29 |
| RC resets itself when robot tries to move | cheesinglee | Electrical | 28 | 04-07-2003 21:59 |
| Controlling a FIRST robot with a Lego RCX Controller? | archiver | 2001 | 5 | 24-06-2002 04:19 |
| WASH Palm scouting at the Championship | Mike Soukup | Scouting | 2 | 19-04-2002 15:14 |
| about how Drive Train push the robot... shouldn't the force accelerate the robot? | Ken Leung | Technical Discussion | 12 | 26-11-2001 09:39 |