View Single Post
  #9   Spotlight this post!  
Unread 12-03-2002, 13:37
Greg Ross's Avatar
Greg Ross Greg Ross is offline
Grammar Curmudgeon
AKA: gwross
FRC #0330 (Beach 'Bots)
Team Role: Mentor
 
Join Date: Jun 2001
Rookie Year: 1998
Location: Hermosa Beach, CA
Posts: 2,245
Greg Ross has a reputation beyond reputeGreg Ross has a reputation beyond reputeGreg Ross has a reputation beyond reputeGreg Ross has a reputation beyond reputeGreg Ross has a reputation beyond reputeGreg Ross has a reputation beyond reputeGreg Ross has a reputation beyond reputeGreg Ross has a reputation beyond reputeGreg Ross has a reputation beyond reputeGreg Ross has a reputation beyond reputeGreg Ross has a reputation beyond repute
Send a message via AIM to Greg Ross Send a message via Yahoo to Greg Ross
Quote:
Originally posted by ChrisA
...id post a piece of code to show you that its fine but i dont have the code at my home computer....
I'd still like to take a peek at the code when you get a chance. If you could extract a small piece of code that shows the failure, that would be ideal.


Quote:
Originally posted by gwross

I vaguely remember seeing something on the Parallax BASIC Stamp discussion list about someone having problems with some bad memory locations in either the scratchpad RAM or in EEPROM. If I remember right, it was related to a particular rev mod of the BASIC Stamp2.
I checked the BASIC Stamps mailing list archives to refresh my memory, and I see it is a problem with the BASIC Stamp 2P. (We have the BASIC Stamp 2SX.)

On the 2P, they have 126 bytes of scratchpad RAM, and the capability of accessing any of the EEPROM slots from a program running in any other slot. The 2P STORE command determines which EEPROM slot the READ and WRITE commands access.

The problem on the 2P is with the STORE command. It corrupts scratchpad locations 110 and 111 whenever it executes. The reporter stated that the STORE command always sets location 110 to 59 and 111 to 0.

So that's not your problem.


Quote:
Originally posted by ChrisA
an example, we were setting all of our drive wheels to the same value in the code...
(we changed it to look something like this for debuggin purposes)
PUT s_lf_wheel, 127
PUT s_rf_wheel, 127
PUT s_lb_wheel, 127
PUT s_rb_wheel, 127
upon reseting, after having downloading the new code to the rc, we found that the value for one of the wheels was running 0,3,2,1... while all the others (which had the same values) were stopped (at 127 as they should have been)
So are you saying that you can execute a PUT to one of these bad locations, immediately do a GET, and the value has changed? Or do you have to go through the control loop before it gets changed?

How are s_lf_wheel, s_rf_wheel, s_lb_wheel and s_rb_wheel defined? They should be constants. If they are variables, could they be being corrupted?
__________________
Greg Ross (The Grammar Curmudgeon formerly known as gwross)
S/W Engineer, Team 330, the Beach 'Bots
<--The Grammar Curmudgeon loves this cartoon.
“Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!" Hunter S. Thompson
"Playing a practical joke means doing something mean and calling it funny." Me