Subject:
|
RE: Ooops! NXT Software Comparison correction / I2C Messaging Speed
|
Newsgroups:
|
lugnet.robotics.nxt
|
Date:
|
Wed, 5 Sep 2007 04:05:59 GMT
|
Reply-To:
|
<dickswan@&Spamcake&sbcglobal.net>
|
Viewed:
|
22342 times
|
| |
|
|
> John Hansen wrote on September 02, 2007 2:22 PM
>
> <<snip>>
> You can't reliably read a value from that device faster than about
> once every 15 milliseconds at the very fastest. If you try to read
> from it faster than that then you will get back bad data.
I wasn't aware of this firmware limitation. I could not duplicate it
when using the ROBOTC firmware.
I've done three different test runs of 500K messages each with perfect
results each time. Each test run used a different sensor. The delay
between end of message reply and start of next message was only 2
milliseconds.
I define "perfect" to mean that if the first value read was 22 cm then
all subsequent values are in range 21 to 23 cm and there were no I2C
bus errors. When I removed the 2 msec delay, then errors occurred.
> The total time required to complete a valid I2C transaction with the
> LEGO US sensor using the standard LEGO firmware is closer to 30 ms
> when you include the required ~15ms delay.
With ROBOTC firmware this is 10 and not 30 msec. This is composed of
the 2 msec delay mentioned above and 8 msec to perform the actual I2C
transaction/poll.
Eight msec for the poll duration is expected -- a transfer of 4 bytes
of data taking 18 clock cycles each at 10K Hz clock (7.2 msec) plus a
few extra clock cycles at start and end of message.
If anyone is interested in a copy of ROBOTC source code for the
measurement program, send me an email.
NOTES:
1. The LEGO I2C message firmware always retries I2C messages twice on
failures. The number of retries is user programmable in ROBOTC. I
set it to "no retries" before running the tests to ensure that I
captured all bus errors.
2. ROBOTC does not use the LEGO written I2C software. It uses its own
re-designed and performance optimized version. This may partially
explain the measurement differences -- i.e. 8 vs. 15 msec to
perform a read operation.
3. ROBOTC also has a optional "fast" I2C messaging mode that operates
at five times the above rate. It works (AFAIK) with all third party
sensors which have integrated I2C support. It does not work with
the Ultrasonic sensor which has a bit-banged I2C implementation
that cannot keep up with the faster mode clock.
The 5X mode is particularly useful for the more complex sensors
like a triple axis accelerometer where you want to read 6 bytes of
data vs the single byte for the ultrasonic sensor.
4. My first three tests were all on sensor port #4. It has slightly
different electrical properties than ports #1 to #3 because of the
high speed RS-485 that only port #4 has. So I ran one shorter test
of 100K samples on port @2 as well. It too was "perfect".
|
|
Message has 2 Replies:
Message is in Reply To:
 | | Re: Ooops! NXT Software Comparison correction
|
| (...) Nearly all of the speed test numbers on Steve's page are wrong. That's because Steve's loop boils down to "how fast can you reliably read the LEGO Ultrasonic Sensor". You can't reliably read a value from that device faster than about once (...) (17 years ago, 2-Sep-07, to lugnet.robotics.nxt)
|
13 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
|
|
|
|
Active threads in NXT programmable brick
|
|
|
|
|
|
