Subject:
|
I2C device for the RCX
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sat, 11 Jan 2003 16:36:46 GMT
|
Viewed:
|
777 times
|
| |
|
|
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 and I want to take a look at this
speed problem myself. Now I’ve made a BrickOS driver for this device, and that
gives me a maximum speed of about 15 commands per second, that’s already 5
times faster that the original (NQC) driver. But I think the RCX can do more
that that!
Whit this BrickOS driver, I had to build in the delay times between the pulses
as described in each I2C datasheet. This is a short table whit all the used
delay times:
1.bus free time,min 4.7us =0.47ms,in BrickOS program 1 ms
2.START condition set-up time,min 4.7us =0.47ms,in BrickOS program 2 ms
3.START condition hold time,min 4.0us =0.40ms,in BrickOS program 1 ms
4.STOP condition set-up time,min 4.0us =0.40ms,in BrickOS program 1 ms
5.SCL low time,min 4.7us =0.47ms,in BrickOS program 2 ms
6.SCL high time,min 4.0us =0.47ms,in BrickOS program 2 ms
7.data set-up time,min 250ns =2.5ms,in BrickOS program 2 ms
As far as I know, the minimal dalay time in BrickOS is 1ms, so I cant go any
lower.(please correct me here if I’m wrong; I would be happy to know that it IS
possible.)
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.
Hope someone can help me,
Bas.
BTW, this was my first ‘BrickOS project’ and I enjoyed working whit it, this is
really a good OS for the RCX!. But I have one problem: when running a program,
sometimes the LCD gets loaded whit crap, or just isn’t updated anymore. The
rest of the RCX seems to work normal, downloading an running programs works. Is
this a problem whit my own programs(they do write a lot of stuff to the lcd,
and kind a fast too) or is this a known BrickOS bug? (I use BrickOS 0.2.6.09)
|
|
Message has 3 Replies:
 | | Re: I2C device for the RCX
|
| (...) Erm...no...you have some trouble with your numbers! 1000us == 1ms so: 4.7us == 0.0047ms !! (...) Yikes! Nooo...ooo! 250ns == 0.25us == 0.00025ms Remember: ms is a millisecond which is 1/1000th second. us is a microsecond which is 1/1000000th (...) (22 years ago, 11-Jan-03, to lugnet.robotics)
| | | Re: I2C device for the RCX
|
| (...) high (...) frames (...) very (...) anyone (...) I (...) BrickOS (...) 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 (...) (22 years ago, 11-Jan-03, to lugnet.robotics)
| | | Re: I2C device for the RCX
|
| (...) This actually seems to be some sort of 'combined' problem which results from the brickOS-kernel doing task scheduling plus some ROM-internal functions eating up some CPU-time. I did some research on it and came up with a rather evil solution. (...) (22 years ago, 12-Jan-03, to lugnet.robotics)
|
24 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
