serious problem found - robot controller resets when jarred!

EEPROMS have a limited number of write cycles, something like a million?

I dont think you want to be writing to the EEPROM on every SW loop. When something is running at hundreds or thousands of loops per second, it doesnt take long to get to a million.

in fact, how could you program this? if your bot did not finish auton mode the last time you ran it, or got hung up for some reason - how would you reinitialize it the next time you WANT to power the bot up?

wouldnt it try to go back and start from where it left off last time?

how does the RC know if the reset was a glitch or a deliberate power on / power off cycle?

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

Ive been thinking about this EEPROM idea over lunch - its a cool idea

but taking two steps back, if your robot was reset during auton mode, then something drastic has happened to it:

  • it got lost and smacked a wall

  • it got nailed by a superiour being (a faster bot)

  • you have a loose wire somewhere…

so given that you dont know what is going to cause the robot to reset during auton mode, you cant possible know what to do when your RC resets, except maybe shutdown and do nothing?

Error detection is one of those weird problems in engineering. Its usually very easy to detect than some sort of error has happened (like an unexpected reset) - and its almost always impossible to decide what to do next - except log an error message and shut down.

If you could anticipate the error condition, then you can program / design the system to expect it, and handle it the way you want - thats not an error condition anymore, its another variable in your more robust system’s normal operation :c)

FYI, the BASIC Stamp Manual gives 100,000 as the number of writes per location for a BS2SX. (BS2e and BS2p are also given as 100,000. BS1 and BS2 are 10,000,000.)