| |
Mark,
This is very interesting. I have experienced strange motor behavior with
programs on BrickOS before; I now wonder if this may have been the
situation.
I do not currently know enough about GCC to make the changes that you
mentioned, but I am hoping that one of the other developers does. Also, I
am wondering what code can be put there to take up that space.
I am confused about this though: I could understand a few bytes or a couple
words at that location effecting the motor output, but ... Why is so much
memory allocated for this purpose? Are there specific locations that effect
specific aspects of the pulse width modulation? Are they just spread out
within this region? Also, is there a register that can be set indicating
that you want to write to the motor registers, then cleared to effect only
memory?
I wonder if there is anything in the H8 manual that might shed some light on
the subject...
// Joe
"Mark Riley" <markril@hotmail.com> wrote in message
news:H5IyvB.79C@lugnet.com...
> 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 2 Replies:
 | | Re: Motor Control Register (0xf000)
|
| (...) I have implemented what Mark Riley has suggested. I submitted a patch to the patches section at the sourceforge project page. The changes are quite small but require some tricky tweaks to the build process. I have only minimally tested it and (...) (22 years ago, 14-Nov-02, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
16 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
|
|
|
|
