| |
In lugnet.robotics.rcx.legos, Rob Stehlik wrote:
> I was writing some simple programs to test out BrickOS last night, and had some
> really strange behavior. I hooked up a motor to port B and a rotation sensor to
> port 2. My programs were just testing out various motor speeds and positioning
> accuracy. The problem was, the motor made some awful grinding noises. It was
> almost as if it was toggling between forward and reverse rapidly. I haven't
> experimented with low speeds in BrickOS before, so I thought maybe it was
> normal. But once I stopped the program, the motor kept going. Kind of freaky.
> Then I shut of the RCX, turned it on again, and the motor started grinding
> again. Really freaky. The I hooked up the motor to the other ports to see if
> anything was wrong with them. Port A seemed fine, while port C was powered as
> well. Instead of a low grinding noise, it produced a high pitched whine. But the
> motor still ran even after the RCX was turned off and then on again. So... I
> erased the firmware by removing the batteries, and then reloaded BrickOS
> 0.2.6.10. Without even downloading a program to the RCX, motor ports B and C
> behaved the same as before. To make sure the problem was not a hrdware issue, I
> erased the firmware again, and loaded the standard Lego frimware, and the motor
> ports behaved themselves.
As we discussed in email, it appears to be the firmware downloader causing
the problem. I just tried downloading BrickOS 0.2.6.10 with both NQC 2.5 a1 and
BricxCC 3.3.6.2 and experienced growling motors. I then downloaded BrickOS
using firmdl3 and had no problems.
This is the same issue that caused problems with other firmware downloads (such
as LDCC and LeJOS). For an explanation as to what the problem is, see this
message:
http://news.lugnet.com/robotics/rcx/java/?n=260
For the morbidly curious, there is a two byte memory gap preceeding the motor
driver routine (which happens to be the last thing in the memory image), and
this gap causes the driver to load two bytes lower in memory. Well, the first
instruction of the motor routine ends up being skipped. This instruction
happens to zero a register (r6l) that gets written to the motor port, but since
the instruction isn't being executed, this register inherits whatever
semi-random value happens to be in r6l at the time.
Mark
|
|
Message has 1 Reply:
Message is in Reply To:
 | | BrickOS motor port horrors
|
| I was writing some simple programs to test out BrickOS last night, and had some really strange behavior. I hooked up a motor to port B and a rotation sensor to port 2. My programs were just testing out various motor speeds and positioning accuracy. (...) (21 years ago, 25-Oct-03, to lugnet.robotics.rcx.legos)
|
8 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
