Saving Data to EEPROM

[Phil Roth]

I need to write about 2KB of data in the EEPROM. The PBASIC IDE seems to locate the program at 7FFh and it builds downward. The PIC in the robot controller has 8KB x 2 banks. Does anyone know how to access this additional memory???. And Oh by the way...Is this legal???..

Is there a restriction to having multiple SERIN and SEROUT commands within a single program??. Our code need hi-performance during autonomous mode and it would be better to run in a tight loop with seperate SERIN and SEROUT commands rather than settings flags all over the place to determine what part of the code we're in.

[rbayer]

First, you can only access the bank you are currently running in. Normally this is slot0, but you can change that with the RUN command.

As for multiple serin/serouts, it's perfectly legal. However, if you write your code well, you don't need more than one of each. Truly, you don't.

You are correct that the program starts from the bottom and builds up. If you want to put data into the top portion, there are a couple of ways to do it:
1. use the DATA command. This will load data into EEPROM when you first send the program to the RC. Useful for tables, etc.
2. use the WRITE command. This will let you change an EEPROM location at run-time.
Be warned, however, that the life cycle of an EEPROM location is only ~100k writes. At 40 loops/sec, this gives approx. 41 minutes of runtime before you can no longer use that particular location. If you have less than 64 bytes of data to store, use scratchpad RAM instead as it has unlimited reads and writes. The PUT and GET command let you access this.

[Phil Roth]

Thanks for the speedy reply. Assuming the program starts at 7FFH, I should be able to set a pointer up @ 800H and then use WRITEs to access the memory. Hopefully the PBASIC compiler won't mirror these addresses and overwrite the program. By the way I tried using RobotEMU and could not get the PWMs to update from the X-Axis controls...What's up with that???. I just downloaded the source code to check it out.

[rbayer]

Remember that the program starts at the bottom and builds up. 7FF is the last location, so you can't set anything above that. You should therefore start your EEPROM access at location 0. That way, there is little to no chance of overwriting your program area.

If you could send me an email describing your RoboEmu problem along with the code you were trying to run, I'd appreciate it.

[Dave Flowerday]

Originally posted by rbayer
However, if you write your code well, you don't need more than one of each. Truly, you don't.

It seems to me that it would be advantageous and more efficient to have 2 different loops - one for autonomous and one for normal driver control. My reasoning is that these two situations will have two very different sets of input - in fact, in autonomous mode, the only reason you'd be doing a SERIN at all is 1) to prevent the RC from resetting the BASIC Stamp and 2) to check the autonomous mode bit. Beyond that, the code should be reacting to sensors and/or time if using dead reckoning. The other loop obviously would be primarily reacting to the driver input with possible assistance from sensors.

Any thoughts?

[rbayer]

If you need sensors, you're going to need to get them via Serin. Also, at 62500 baud, taking in one byte is not much faster than taking in the full set as each byte takes only .0001 seconds per byte. On the other hand, I suppose it could shave a ms or two off your loop time...

Anyway, does anybody know if doing another shiftout will let you choose new variables to serin? If it doesn't, you're going to be stuck bringing in the same variables in both places anyways. I really have no idea whether this works or not and am too busy with RoboEmu and school stuff to check right now. If nobody has an answer by tomorrow night, I'll hook up an RC and give it a try.

--Rob

[Dave Flowerday]

Originally posted by rbayer
If you need sensors, you're going to need to get them via Serin.

Good point. However, once you have that information you'll want to do two very different things with it. Are you thinking of doing the serin command, then branching to one section or another depending on the value of the autonomous mode bit? I guess that would be fine, but I don't see how that is necessarily better.

Anyway, does anybody know if doing another shiftout will let you choose new variables to serin?

I don't know off hand, but assuming it does then it would only make more sense to have two separate serin commands depending on which mode you're in...

[Joe Ross]

Originally posted by rbayer
Anyway, does anybody know if doing another shiftout will let you choose new variables to serin?

We have also thought of this, but have not tried it, yet. If they really mean initialize the master uP, then it probably wouldn't work in competition, becasue I would guess that you would lose radio communication.

Back to the original question, make sure you use write sparingly. EEPROMs only have a limited number of write cycles. The highest I've seen for consumer level EEPROMS is 1 million (and it's most often less). If you write during each program loop, you will wear out the EEPROM after 200 2 minute matches. While this may seem like a lot, when you consider debugging, and demos, you will definelty wear it out by the end.

[Phil Roth]

Our application only writes to EEPROM during a setup/calibration procedure for autonomous mode, so we won't come close to the 10,000 cycle limit. Has anyone simply tried to set a WORD ptr to the second bank, I.E. 800H and then use that area. for example to write 0 - FFh at locations 800h - 8FFh.

EE_pointer VAR word
EE_pointer = 2048

for( x = 0 to 255 )
WRITE EE_pointer, x
EE_pointer = EE_pointer + 1
x=x+1
next

I'm aware of the 10MS delays that may be needed between writes. I think the controller has flash anyway and should be able to take hi speed loads.

During autonomous operation we need loop execution time < 15 MS to keep up with sensor feedback and filtering. The only way to do this is with a completely seperate loop aside from main. This is easier for us instead of having a common entry/exit point and using flags to get to the autonomous code. It's just another way of doing it.

[rbayer]

You're not going to get a 15ms loop. Ever. At 9600 baud, the radios have to transmit ~26 bytes each loop between OI and RC. This takes around 21ms alone! Add on an ms or two for your serins from the master uP and you're looking at a minimum loop time of around 25ms.

Second, you've got a number of problems with the code you posted. Too many to mention, in fact. For starters, your FOR syntax is wrong.

Moving on: no, you cannot access the other banks simply by making the pointer point past the end of your current slot. Directly from the Parallax documentation: "WRITE only works with current program slot on BS2e and BS2sx." We have a 2sx. A 2p, on the other hand, could write to other program slots, but that's another story altogether.

--Rob

[Phil Roth]

Sorry, I think my point was mis-interpreted. The FOR loop was only a quick example of accessing memory and this is not the actual code. Please excuse the syntax errors, I guess my years of 'C' coding have polluted my recollection of BASIC.

As for the timing, there will be only 1 WRITE and 1 SERIN for each loop, along with some other stuff. We also don't need any SEROUTs during calibration, only the SERIN with 2 or 4 arguments, and modifying the shift macros reduces the number of arguments passed. We are presently executing loops @ 12.7MS.

In closing, the 9600 baudrate is easily changed to 38400. I'm not looking for a debate here...just some advise...Chill man...No need to reply.

Thank's for the "moving on:" answer, I'll have to find a way to get memory some other way.

[rbayer]

I know you told me not to reply and to "chill," but you're not going to get off that easily!

You are definately going to have to explain your alleged 13ms loop as the lowest I can get is almost exactly 26. Here's the relevant code:

all CONs at 0 except PB_MODE

MainLoop:

Serin COMA\COMB, INBAUD, [PB_mode]

test=test+1

if test<1000 then no_done
debug "Done", cr
no_done


Serout USERCPU, OUTBAUD, [255,255,127]

Goto MainLoop:


Guess what? After exactly 26 seconds (that's 26ms *1000 loops), "done" pops up. Send me some code that's smaller and faster than that and you have my congrats. Especially if it can actually do something.

[Phil Roth]

Sorry to be so vague, I may have said too much already and need the biggest competitive edge as possible. Maybe we can get together in Houston during the competition to talk about it. If I can't find 1600 bytes of non-volitile memory, it's a moot point anyway about the speed.

[Mike Betts]

Hey Rob... Some people have to learn the hard way...

[rbayer]

Originally posted by Mike Betts
Hey Rob... Some people have to learn the hard way...

lol. I guess I should just give up on this thread. Oh well... At least I've got a 2.5 editor to keep me occupied for awhile...