Do you have to have the delta_t variable? Right now I am really crunched for variable space and need all the space I can get. I commented it out during emmulation and it works fine but I haven’t tried it in the robot. What does it do?
Also, how to you use the read/write commands? I have looked on sites like the codex.net, etc, but I still don’t get it. Do you have to initialize the read/write variables at the beginning of the program too?
I’m confused, thanks.
If you are not using it right now, you don’t need to have it (getting rid of it will not hurt your program as it is written right now).
delta_t is the only (bult-in) way of knowing how much time has passed between loops. Basically, it will tell you how many loops (each 26ms long) you have “missed” since your last SERIN. If you aren’t using it now, you can safely get rid of it.
READ/WRITE has nothing to do with variables. Instead, they are commands used to read and write data from the 2048k per bank of EEPROM that the Stamp normally uses to store the actual program in. So far, the best use of it that I’ve seen is in those programs that allow you to “teach” the robot autonomous mode. Do a quick search and you’ll see what I’m talking about. Here’s a quick rundown on the syntax:
READ Location, Variable
WRITE Location, DataItem
Location: a number between 0 and 2047 indicating the place in EEPROM you want to read or write from.
Variable: the variable you want to use to get the data. This variable will have its value set to the value of EEPROM at Location.
DataItem: the value you want to write to EEPROM
Examples:
READ 42, tempVar
WRITE 42, 64
The first will load the value of the EEPROM at location 42 into the variable tempVar. The second will store the value 64 at location 42.
In theory, RoboEmu properly supports these commands so feel free to give them a try there.
–Rob
Thanks, RoboEmu is awesome too! It has saved me an unbelievable amount of time.
Umm… see, theres this nice little thing called scratch-pad memory… and umm, well nobody around here likes talking about it… but umm… yeah, it gives ya an extra 63 varibles to work with.
The way scratch-pad memory works: You can load/save a varible into a spot in the scratch pad, but you have to address it by number, and you cant do anything with it when its in the scratch-pad memory.
So, to get around this what we do is we reserve 4 bytes for swap memory and load stuff in and out of the scratch-pad memory… lots of extra room! Hint hint on this: Use aliases! makes for very much more readable code!!
get 10, tempvar1
That retrieves the value of scratch-pad location #10, and sticks the contents into tempvar1. You can address any location from 0-62? (63 was reserved for something… i think)
put 10, tempvar1
That takes whatever is in tempvar1, and sticks it in the scratch pad location (#10 in this case).
Our implementation (kinda):
tempvar1 VAR byte
tempvar2 VAR byte
tempvar3 VAR byte
tempvar4 VAR byte
some_var VAR tempvar1
another_weird_var VAR tempvar4
…
get 13, some_var
…
get 14, another_weird_var
…
put 13, some_var
put 14, another_weird_var
Are ya getting the point yet? I hope so… lol
Other advantage of this is the scratch-pad varibles are constant from program slot to program slot… so you can use the same varibles in each program slot… very good stuff!
Gotcha, this is GREAT. btw, can you use word variables in the scratchpad memory? Just wondering.
Thanks to everybody, there is hope now! lol
*Originally posted by Morgoth *
Gotcha, this is GREAT. btw, can you use word variables in the scratchpad memory?
Yes, but you have to load and store them one byte at a time:
get 0, wordVar.lowbyte
get 1, wordVar.highbyte
Thanks, randomperson.
Sorry about that.
I’m a fool.
Umm… no.
That refers to reading/writing EEPROM memory… not scratch pad. Notice the use of “read” and “write” instead of “get” and “put” 
[edit]
Ok, now this comment seems so out of context given you erased the previous message… ok, everyone ignore that then… ill just continue to reaffirm the fact that you can only get/put scratch pad memory one byte at a time:)
[/edit]