Subject:
|
Re: I2C device for the RCX
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Sat, 11 Jan 2003 17:15:18 GMT
|
Original-From:
|
Steve Baker <[sjbaker1@airmail]spamless[.net]>
|
Viewed:
|
763 times
|
| |
|
|
Bastiaan v.Kesteren wrote:
> 1.bus free time,min 4.7us =0.47ms,in BrickOS program 1 ms
Erm...no...you have some trouble with your numbers!
1000us == 1ms
so:
4.7us == 0.0047ms !!
> 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
Yikes! Nooooooooo!
250ns == 0.25us == 0.00025ms
Remember:
ms is a millisecond which is 1/1000th second.
us is a microsecond which is 1/1000000th (one millionth) of a second.
ns is a nanosecond which is 1/1000000000th (one billionth) of a second.
...a beam of light travels about one foot in one nanosecond. 250 nanoseconds
is a VERY short amount of time! 2ms is 2 MILLION nanoseconds!
So - no wonder the program drives the I2C bus so slowly.
> 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.)
For times as short as microseconds, I'd use a timing *loop* - just a short
'for' loop. Time loops of different lengths until you get one that's got
just the right characteristics.
In general, timing loops are considered bad practice (eg in PC programming)
because they run at different speeds on different CPU's - so your program
won't necessarily work on anyone else's PC. However, since all RCX's are
identical - and if Lego ever made a faster one, they'd probably change a
bunch of other stuff too - this is not a valid criticism.
Don't use timing loops for longer times (in the millisecond range) because it'll
stop other processes from working - but for short delays, it's exactly the right
thing to do and will DRASTICALLY improve your commands-per-second rate!
I would write program containing a 'for' loop that (say) adds two numbers
together - run it for a hundred million loops - and then beep. Measure
how long this takes using a stopwatch - then you'll know how long one loop
takes. Adjusting the 'for' loop limit will let you create timing loops
of any length you desire.
If you are a very *careful* person - you could also tell GCC to generate
a machine code listing for your 'for' loop test. Then look up the manual for
the RCX's microprocessor and find out how many clock cycles it takes to
execute each of the instructions in the loop - add those up and divide by
the clock frequency of the RCX (I'm sure that's on one of the AFOL's web sites).
Then you can know *precisely* how long your timing loop will take.
Note though that there is always a chance that in interrupt from one of
the peripherals could cause BrickOS to take control of the CPU for a short
time - so delays may *sometimes* be a little longer than that. So timing
loops can only ensure that we've waited AT LEAST THE MINIMUM amount of time
and not that the time is exactly right. That's another reason not to use
them for longer delays when BrickOS's timers would work.
> 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?
Hmmm - it does sound like some kind of BrickOS problem.
> I don't have the tools to figure this out myself, so I hoped anyone
> else knows this.
Can you write a little program that does (say) 100,000 one millisecond
delays - and then beeps? You could time it with a stopwatch and see
if it takes under 100 seconds to run...something that simple would then
show for sure whether the bug was in BrickOS. Since the BrickOS
developers read this list, you'll probably get a fix in short order
if you can show there is a bug using such a simple program.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjbaker1@airmail.net> WorkEmail: <sjbaker@link.com>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
|
|
Message has 3 Replies:
 | | Re: I2C device for the RCX
|
| Steve, Very good suggestions! (...) Bastiaan v.Kesteren, I second Steve's recommendation, using loops for timing between command segments. You will not get very far using BrickOS msleep because of the 1ms minimum timing. Also, you may find the (...) (22 years ago, 11-Jan-03, to lugnet.robotics)
| | | Re: I2C device for the RCX
|
| (...) OK, stupid of me! (...) even more stupid..... Maybe I should go back to primary-school for a while to learn those things again (-: anyway, thanks for the suggestions. (22 years ago, 12-Jan-03, to lugnet.robotics)
| | | Hi, I'm new
|
| Hi, I'm Tjandra at Surabaya, Indonesia. Last year, I bought RIS 2.0. But until now I cannot make a robot biped with two leg. Would you please to help me, to give some building instruction & the program to make it, only uses RIS 2.0 components. Thank (...) (22 years ago, 13-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
|
|
|
|
