 | | Motor Control Register (0xf000)
|
|
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. (...) (22 years ago, 13-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
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 (...) (22 years ago, 13-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
Joe, [some reordering of comments for clarity] (...) The idea is to pick a certain number of functions that will fit in the upper RAM space (~2900 bytes) and put these functions in a seperate linker section (other than the default ".text" section). (...) (22 years ago, 13-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
(...) Interesting, I never looked at that version. I think the one disassembled by Kekoa is 0309. Current versions of leJOS also use this upper memory to store part of its firmware (almost 3K). Jürgen (22 years ago, 13-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
(...) This is interesting. It makes sense that the memory backing these locations still works, but I never would have thought to try to use it. I will make a note of this on my pages. -Kekoa (22 years ago, 13-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
It also turns out that there are 8 bytes of external RAM that peek through at addresses 0xff80-0xff87. Writes to these locations also affect the motor control register. I suppose there's a small advantage in using these registers to control the (...) (22 years ago, 14-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
(...) In that case, why didn't the RCX designers use an 8 input NAND to decode their addresses, to leave more of the RAM usable? Maybe there werent aware of this possibility? Jürgen (22 years ago, 14-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
(...) While you are at it you could also make a remark near the explanation of the f000 motor control register, and make it clear that this is a hardware function. When I started to use this extra memory in leJOS I missed the remark at the very end (...) (22 years ago, 14-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
<snip> (...) Ok, thank you for the explaination! I am thinking that the Memory Manager would need some rework to support this, since the start of memory is currently established at compile time. I will have to take a look at this (time allowing). (...) (22 years ago, 14-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | 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)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
(...) As it is, it seems[1] that two of the three NAND gates in the 74HC10 are being used as a driver for speaker output (it's odd that it's two, not one though). So, this leaves one three input NAND gate to do the decoding. Now that I think about (...) (22 years ago, 14-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
(...) Thanks for the suggestion... I think the change I made a few days ago included a note here also, but we might be talking about different spots. Let me know if not... kekoa@stanford.edu. -Kekoa (22 years ago, 20-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
(...) Yeah, I missed that, I'll add that to the notes. (...) Too bad they didn't document the hole well enough to make it obvious to the people at Lego, who apparently had no idea. They use "mov.w rx,@0xf000:16" all over the place instead of the (...) (22 years ago, 20-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
(...) It's the one I meant, thanks. Jürgen (22 years ago, 21-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000)
|
|
The lugnet registration takes forever :) After reading this post a light went on in my head. A few weeks ago I wrote a multi-threaded program for the RCX (about 7 threads, each running an endless loop). When I added one more thread, the robot (...) (22 years ago, 27-Nov-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
| |
| | Re: Motor Control Register (0xf000) and Memory Space 0xFDB0-0xFD7F
|
|
This note is of interest to people who build their own RCX firmware. It provides some additiional insight to the recent post concerning dual use of upper memory range and the motor control register. There's a trade-off between real time performance (...) (22 years ago, 1-Dec-02, to lugnet.robotics.rcx, lugnet.robotics.rcx.legos)
|
