| |
Seeing as how there's been little traffic here recently,
I thought I'd post about something I found that's cleared
up a little mystery (for me at least).
It concerns the RCX register that is used to control
the motors. This register lives at 0xf000. In fact,
on one of Kekoa Proudfoot's pages he states that any
write in the range 0xf000-0xfb7f will affect the
motors. This is true, I tested it.
Well, the thing that confused me was that people
were using some of this same address space as
external RAM.
For example, in the 0328 firmware, after it gets
downloaded it moves some of its code up into the
RAM starting at 0xf100. It subsequently makes
calls to the functions located in this upper RAM
region and apparently everything works fine.
Another example is brickOS. It adds the range
0xf010-0xfb7f to the memory manager's free
memory pool. And this works, too.
So, I wrote a little test program that wrote a unique
pattern to all memory in the range 0xf000-0xfb7f.
I then inspected the memory, and sure enough the
entire pattern was intact. It turns out that the entire
range is RAM, even the address 0xf000!
The only way to reconcile this is to assert that any
write to 0xf000-0xfb7f writes to BOTH the motor
control register and external RAM. Any read in
this range reads from RAM.
What this means for brickOS users is that any
memory returned by malloc() in this range that
is written to will also affect the motors. If you
do only sporadic writes to this memory then you
may not notice anything because the motor
control register gets refreshed every 1ms by
brickOS. However, if you are doing some heavy
writing to this memory, then the waveform going
to the motors can be significantly altered (basicly
affecting the power given to the motor).
This is not a problem for the 0328 firmware
because once it uploads its code to 0xf100, it
only ever reads from this memory (when the
code that lives there is executing).
Perhaps brickOS can adopt the same approach
and move some of its code to this memory
region, freeing up space in lower RAM that
won't have an adverse affect on motor output.
It's fairly straightforward to do this kind of thing
using the GNU assembler and linker.
BTW, a side effect of this is that 0xf000 is its
own shadow register!
Anyways, sorry for the length... thanks for reading,
Mark
|
|
Message has 5 Replies:
16 Messages in This Thread:
   
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
