To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 20018
20017  |  20019
Subject: 
Re: I2C device for the RCX
Newsgroups: 
lugnet.robotics
Date: 
Sat, 11 Jan 2003 18:50:53 GMT
Viewed: 
647 times
  
"Bastiaan v.Kesteren" <b.van.kesteren53@zonnet.nl> wrote:

But the biggest problem is that the START set-up, SCL low time and SCL • high
time can't go lower than 2ms. When I do make them lower that 2ms, the • frames
get messed up. Could it be that the pulses, generated by the RCX, are not • very
precise? I don't have the tools to figure this out myself, so I hoped • anyone
else knows this.
Also I've heard that this could be a problem whit BrickOS, that it is the
software which makes the pulses, and that this isn't done very precisely. • I
don't know much about the BrickOS internals, so I hope anyone whit some • BrickOS
knowledge knows a bit more about this.

In the current release of BrickOS, the motors only
get updated by the timer ISR every 2ms, so that
probably explains why trying to twiddle the bits any
faster than that causes problems.  (Joseph Woolley
has modified the kernel to update the motors once
every millisecond, but I don't think this patch has
made it into distribution yet.)

Also, BrickOS currently doesn't allow the motor outputs to be
driven full ON for any length of time.  When the motors are
set to full speed (i.e. 255), every 512ms the output
drops low for 2 ms.  This is a byproduct of using
the Bressenham algorithm for motor control with a modulo
of 256 and limiting max speed to 255.  Since the speed and
sum variables are bytes, you can't simply change
the speed to 256 to get around the problem.

One way to improve things is to reduce the modulo
to 128 and allow speed values of 0 through 128.  This
necessitates a change in the motor control algorithm, however.

Here's a section of code you can copy into dmotor.c to
implement this change (replaces existing motor summing
code):

  ; motor A

  mov.w   @_dm_a,r0
  add.b   r0h,r0l                 ; add delta to sum
  bpl     dm0                     ; sum overflow?
  and     #0x7f,r0l
  mov.b   @_dm_a+2,r6h            ; -> output drive pattern
  xor.b   r6h,r6l
dm0:
  mov.b   r0l,@_dm_a+1            ; save sum

  ; motor B

  mov.w   @_dm_b,r0
  add.b   r0h,r0l                 ; add delta to sum
  bpl     dm1                     ; sum overflow?
  and     #0x7f,r0l
  mov.b   @_dm_b+2,r6h            ; -> output drive pattern
  xor.b   r6h,r6l
dm1:
  mov.b   r0l,@_dm_b+1            ; save sum

  ; motor C

  mov.w   @_dm_c,r0
  add.b   r0h,r0l                 ; add delta to sum
  bpl     dm2                     ; sum overflow?
  and     #0x7f,r0l
  mov.b   @_dm_c+2,r6h            ; -> output drive pattern
  xor.b   r6h,r6l
dm2:
  mov.b   r0l,@_dm_c+1            ; save sum

Also, dmotor.h needs this define changed:

#define  MAX_SPEED 128    //!< maximum motor speed

The only problem would be for BrickOS programs that
hard code speed function calls like this:

  motor_a_speed(255);
  motor_a_speed(128);

instead of:

  motor_a_speed(MAX_SPEED);
  motor_a_speed(MAX_SPEED/2);

For most applications being able to control the motor
to 1ms (or 2ms) granularity is fine, but sometimes it's nice
to be able get in there and twiddle the bits quickly.  It
would be easy to modify the motor ISR to only update
certain outputs while leaving the others under direct control
of the user application using a masking mechanism.  I've
implemented this scheme for a library I've been working on
(not in BrickOS yet), so if there's interest, I could port
it.

Mark



Message has 1 Reply:
  Re: I2C device for the RCX
 
Hum. i think my first post was not very clear( and whit some stupid mistakes) I think you now how I2C works: there are to lines, SCL and SDA. so whit this device, I got to sensor ports, one for SCL and one for SDA. making high and low signals on the (...) (22 years ago, 12-Jan-03, to lugnet.robotics)

Message is in Reply To:
  I2C device for the RCX
 
Hello, A while ago, there whas a short thread about the I2C device for the RCX from Elector Electronics magazine No. 309, APRIL 2002. The conclusion was: way to slow, 3 commands per second was the maximum possible. I’ve build it anyway, just for fun (...) (22 years ago, 11-Jan-03, to lugnet.robotics)

24 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