Yes! He explained it better than I did. One thing that I would add is if you are really strained for RAM is that you could keep the counter a byte and if you need numbers bigger than the byte will supply, just add steps until you get the length you need.

The 8 will shift it left by 8 bits, leaving enough space for the byte (8-bits) to fill in the newly created free space.

Here's an example:

Assume loopCntHigh is 3 (0011 in binary), meaning we've looped through 256 values of loopCnt 3 times.
Assume loopCnt is 199 (11000111).

Then: loopCntHigh<<8=001100000000
Add loopCnt: 001111000111, which is 967. This makes sense as 256*3+199=967.

Does that make any sense? Bit shifting operations are always messy, but sometimes they are the easiest solution to problems like this (a single number spanning multiple variables).

Rob: Is there a place online that documents the mathematical limits of PBasic?

I ask because I like your bytevariable<<8+nibblevariable trick :)

Depends on what limits you are talking about. The Stamp manual from Parallax contains all the math operators, etc that the Stamp supports, but it doesn't give many good examples of how you would use most of it.

For me, I've picked most of it up doing a LOT of C/C++ stuff, much of which includes bit-operations such as this. Randall Hyde's assembly language tutorial (http://webster.cs.ucr.edu/Page_asm/A..._ArtofAsm.html) has some really good info on binary math and logic, but it isn't exactly and easy read. Like always, I'm available to answer any questions anybody comes up with, so feel free to drop me a PM or email.

--Rob

I'm trying to use the original timer code from the first thread in a simple dead reckoning pattern. My code has the time calculator directly after the SERIN, has 2 lines of code changing the wheel numbers for the SEROUT, then the SEROUT. It loops this until realtime = whatever time I want. It goes forward, turns right, forward, right, forward, right, then forward. The problem is that after the first forward (Which works perfectly), it just turns right until I turn off the robot. Any ideas why? The variables are the same as the default, delta_t is declared and set to 1 in intilization. The forums aren't being nice and the SERINs are all on one line in the actual code.

Don't forget to reset realtime to 0 between your sections. Or, you could change the "loop until realtime=1" to "loop until realtime=3". From quickly looking over your code, I'd guess that this is the problem.

--Rob

Why make it so hard on yourselves
 

why are all of you making it so hard on yourselves?
just put the time counting loop at the beginning of your autonomous mode, then use if/then statements relating realtime and time. Why repeat it 7 times throughout your code along with serin again and again? plus, why worry about counting for 1 min 45 sec? unless i am extremely mistaken, the auton mode is only 15 seconds long, and i doubt you want to run your robot autonomously after that because no matter how godly of a programmer you are, human senses, adaptability, and recognization will always outdo straight computer logic.

-Anthony

redundance
 

Mike, what is up with all the identical code, don't you think you could go with the flow of the main loop and just do something like this:
Questions/comments, pm me

A problem is your mixing syntaxes. The goto in the beginning is 2.0, but select case is 2.5

There is no problem with his code. You can mix 2.0 syntax into the 2.5 without any problems. It would be better from a style perspective to have said:

if auton_mode=1 then
'auto code goes here
else
'normal here
endif

but it isn't wrong to do it the other way.

You don't need to worry abou the timing, just take your "cue" for the fifteen seconds from when auton_mode changes to zero and comp_mode (or something like that) changes to 1.

But if you're doing dead-reckoning, you need to know how many seconds have passed so far so that you know what you should be doing.

Ahhhh, now I understand. Thanks for the insight. We are going to follow the line so I didn't think of that.

There are many ways to skin the cat, but some ways are better than others :D

Not necessarily the number of seconds, but rather the amount of time(program cycles work here) your program has been running...and it's easy enough to have a program you can "train"...i'm going to be putting together a white paper sometime later in the season about the autonomous training system I came up with for a team that I got asked to help...