View Full Version : Saving Data to EEPROM

Phil Roth
01-12-2003, 07:26 PM
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.

01-12-2003, 07:33 PM
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
01-12-2003, 07:41 PM
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.

01-12-2003, 07:44 PM
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
01-12-2003, 11:23 PM
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?

01-12-2003, 11:33 PM
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.


Dave Flowerday
01-12-2003, 11:51 PM
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
01-13-2003, 08:34 AM
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
01-13-2003, 10:33 AM
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

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.

01-13-2003, 10:46 AM
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.


Phil Roth
01-13-2003, 12:13 PM
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.

01-13-2003, 12:35 PM
I know you told me not to reply and to "chill," but you're not going to get off that easily! :D

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


Serin COMA\COMB, INBAUD, [PB_mode]


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

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
01-13-2003, 12:52 PM
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
01-13-2003, 01:22 PM
Hey Rob... Some people have to learn the hard way...

01-13-2003, 01:27 PM
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... :cool:

01-13-2003, 01:59 PM
What is clearly needed is a small 'upgrade' of the PBASIC stamp. Something on the order of an older Celeron. Small upgrade for the radio modems, too. Perhaps a cheap wi-fi setup would work. And if you're really clean, the judges might not even know the difference. That is, until you're robot starts surfing the internet.
EDIT: I have no idea if wi-fi is faster than the radio modems.

Phil Roth
01-13-2003, 02:15 PM
OK...I'm on another hunt for non volatile memory. From what I understand there is a USER and DEFAULT program jumper on the controller, meaning there is extra memory in there somewhere..

Is there a way to select, from a PBASIC instruction, which program to execute, USER or DEFAULT. Or is there a way to hold multiple programs is seperate 2k banks and then have the ability to select a bank via a PBASIC instruction or a external event??

The intent is to use 1K bytes of EEPROM for WRITES during autonomous play and the rest of the bank for actual code and then switch to another 2K bank having the normal drive program.

I guess the DEFAULT/USER jumper could be controlled by a controller output allowing each seperate program to select the other one. I probably would need another controller output line to activate RESET to re-start... Sounds like a hack.

Anybody got any ideas....Be nice will you guys, I'm an old fart


01-13-2003, 02:29 PM
First, I guarantee there is a way to do it without 1k of EEPROM, but if you really want, here's how you change programs: the RUN command.

Run 0 will run the program in slot 0, etc.

You have eight slots (0-7) that you can use in any way you feel like. Note, however, that there is no way to "return" from a RUN so make sure not to think of it as a glorified gosub.

On another note: if you would feel more comfortable talking one-on-one via email instead of anouncing your intentions to the whole world, that's fine. Know, however, that in the spirit of gracious professionalism, nobody is going to use what you post against you. It may help them get ideas, but chances are they would come up with them eventually anyway.


P.S. I'm sorry if I come off as being hostile--it's just that I just know that a loop of less than 26ms is impossible without causing a BASIC RUN error.

Phil Roth
01-13-2003, 03:20 PM
Thanks for explaining the RUN command. Does the PBASIC program allow loading multiple programs?. I'm here at work and don't have it loaded.

I'll make you a deal. You tell me your autonomous strategy and I'll tell you mine.. Believe me, no one has thought of my idea..

Mike Betts
01-13-2003, 03:29 PM

There is a complete example of multiple programs at the Innovation First web site. Look for "Multi Bank Code", download and unzip. Then look at what they have given you...

You might be surprised at how easy it is...

Dave Flowerday
01-13-2003, 03:59 PM
Originally posted by Phil Roth
Believe me, no one has thought of my idea..
To quote Top Gun, "That's pretty arrogant considering the company you're in."

01-14-2003, 03:13 PM
You don't have to reveal your strategy to get some help, just what you are trying to do with 1600 bytes of dynamicaly created data. I'll bet that if you post the purpose of the 1600 bytes, somebody will think of another way to accomplish the same thing, thus solving your problem.

Anyway, I would tell you our autonomous strategy, but we don't have one yet! :D


01-14-2003, 06:13 PM
Originally posted by rbayer

You have eight slots (0-7) that you can use in any way you feel like. Note, however, that there is no way to "return" from a RUN so make sure not to think of it as a glorified gosub.

Interestingly enough, there is a way to turn a program in another slot into a glorified gosub... Basically it would look like : (and I'm not promising correct syntax here, this is just to give the general idea)

--program 0 start--

get 0, getControlFlag 'Checking control flag
if getControlFlag = 1 then getControl:

'--main loop--
serin etc. etc. etc.


goto PassControl1


goto loopstart:
'--end loop--

'--misc. program bits outside of main loop--

put 0, 0 'clear controlFlag
get 1, SomeVariableWasPassed
get 1, SomeOtherVariableWasPassed

goto backToMain

put 0, 1 'set control flag
put 1, SomeVariableToPass
put 2, SomeOtherVariable to pass

run 1

This would pass some values to program 1 (which would have also have the getControl function) and it could then return to your main program with its own PassControl0 function. Our team is doing something similar to this with our program for the autonomous mode.

(Just so any new programmers were wondering, GET and PUT access the scratchpad RAM and uses that to pass the variables between the programs)

Phil Roth
01-14-2003, 08:16 PM
Excellent idea.. The code can be even cleaner when 2.5 gets here. Is there any performance penalty for switching banks. It should only take a few usecs, but you never know.

01-14-2003, 08:31 PM
I have been unable to find any performance penalty for switching banks. We did some playing with the Robot Controller last year after comp, and I didn't notice any delay when the switch occured. (Of course, I wasn't paying that close attention, it is possible that some delay happened and I skipped over it)

I'm sure that it's not as fast as gosub or goto, but for something like switching to autonomous mode, I think it is a great help. Our team is using something similar to this code to switch between our driver interface and auton mode.

Greg Ross
01-15-2003, 12:18 AM
I asked the tech who taught the BOE 'Bot course I took. He said switching banks was nearly as fast as a goto, and faster than a gosub (or something to that effect.)

01-15-2003, 12:25 AM
really? faster thana gosub? wow... that is impressive. u sure on that? I suppose it could be... none of that mucking around with returns or anything.... though my way makes it take longer because you have to assign data to scratchpad ram first, and when you arrive you have to read in the data... Basically, the only thing I'd use this method for is something like autonomous mode, where putting it in a sub makes everything ugly and you run out of variable space. Otherwise I would certainly prefer a gosub or even a goto!

(Also, with a gosub or a goto theres no chance that you'll read from the wrong scratchpad ram slot and mix up the data... hehe.. oops... watch that very carefully, if thats the program error that can be hard to find, because it will still be a legal command.)

Greg Ross
01-15-2003, 01:26 AM
Originally posted by Noah
really? faster thana gosub? wow... that is impressive. u sure on that?
Yep. Don't have to save and restore the P-counter. Just a bank switch.

03-27-2003, 09:29 PM
Here's an idea- use all the memory in one slot, then move to the next. This would work if you were recording human actions.

If you were using it for something else, and needed random access to any of it, you could do like programs do on ram, and use slot 0 as your "RAM". Slots 1-7 could be like your hard drive. Just recall the needed info and slap it on slot zero.

This might be slow, hard to implement and such, it could even be impossible, but it would be awesome, indeed.