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.
</sarcasm>
EDIT: I have no idea if wi-fi is faster than the radio modems.

Selecting multiple programs
 

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

-phil

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.

--Rob

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.

Rob:
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..
Phil

Phil,

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

To quote Top Gun, "That's pretty arrogant considering the company you're in."

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

--Rob

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

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.

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.

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

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

Yep. Don't have to save and restore the P-counter. Just a bank switch.

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.