To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.robotics.rcxOpen lugnet.robotics.rcx in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / RCX / 1841
1840  |  1842
Subject: 
Re: Motor Control Register (0xf000)
Newsgroups: 
lugnet.robotics.rcx, lugnet.robotics.rcx.legos
Date: 
Wed, 13 Nov 2002 21:09:21 GMT
Viewed: 
3731 times
  
Joe,

[some reordering of comments for clarity]

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.

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).  Using the
linker script, the functions in this new section would
be compiled to run at 0xf002, but initially stored
at the tail end of the normal brickOS code.  When
brickOS gets downloaded and executed, one
of the first things it would do is move these functions
to upper RAM.  The space previously occupied
by the functions can now be added to malloc's
memory pool.

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?

The motor control register is actually implemented in
hardware external to the H8.  The RCX designers ran
out of I/O pins and used a 74HC377 octal flip-flop
to get 8 extra output pins.  These pins are changed
whenever you write to memory in the 0xf000-0xfb7f
range.  There's an additional chip on the board, a
74HC10, which is a triple three-input NAND gate.
I believe this chip is being used to decode the address
lines on the H8 so that any writes to the external
address space with address lines A12 to A15 all
high will cause the '377 to latch the data being
written.

The reason so much address space is used to
control this one register is cost.  To decode
the H8 address lines so this register only occupied
one byte of address space would require that
external logic look at all 16 address lines.  This
means a chip (or chips) with 16 inputs would
be needed to get the specificity you're talking about.
This costs more money, complicates the board
layout and really isn't necessary (in most cases).

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?

Six of the 8 bits are used to control the motors.  Two
are presumably unused.  Kekoa's RCX internals
pages describe the function of the various bits.

Cheers,

Mark



Message has 1 Reply:
  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)

Message is in Reply To:
  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)

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
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR