Subject:
|
RE: Ooops! NXT Software Comparison correction / I2C Messaging Speed
|
Newsgroups:
|
lugnet.robotics.nxt
|
Date:
|
Thu, 6 Sep 2007 05:54:14 GMT
|
Reply-To:
|
<DICKSWAN@SBCGLOBAL.stopspammersNET>
|
Viewed:
|
22568 times
|
| |
|
|
> John Hansen on September 05, 2007 3:40 PM
>
> Are you admitting to having cheated in Steve's timing test results?
> . . .
Nobody cheated or is dishonest. Everyone who writes firmware for the
NXT is well-intentioned "good" people.
Let's not mislabel good modern programming practice -- i.e. hardware
device drivers integrated into the low-level firmware -- as something
that is "dishonest" or "cheating".
Steve's objective was to benchmark the raw execution of the various
programming solutions. The results posted on his web page are a
successful measure of his objective.
One challenge for NBC and NXC is that they are dependent on the
capabilities of the NXT-G firmware. This firmware has an integrated
device driver for analog sensors but not for the I2C digital sensors.
The analog device driver's job is to frequently poll the sensor values
as a routine task so that the last polled value is immediately
available to application programs.
Unfortunately NXT-G firmware requires a slow inline I2C read to access
the Ultrasonic sensor value.
ROBOTC, Robolab and pbLUA are not bound by the limitations of the
NXT-G firmware. These systems have extended the NXT-G firmware
functions to include a native device driver for the Ultrasonic Sensor.
It wasn't done to cheat on Steve's test. It was done as part of their
core developments because it was a logical smart thing to do.
Naturally, retrieving a stored RAM variable is far faster than a 30
msec activity.
In writing the program for Steve's test, I naturally used the
pre-existing Ultrasonic driver. pbLUA did the same. As did Robolab.
Using an ultrasonic driver is no different than the use in NBC program
of analog device driver in the NXT-G firmware.
And yes, these solutions are so fast, that they loop faster than the
ultrasonic sensor is polled.
In fact, they even run faster than the 20K samples per minute polling
rate of the analog sensors. Since test results up to 73K loops are
reported for NBC, without any fine print about the 20K sample limit,
has NBC now sinned and transgressed into the ranks of "cheaters" and
"dishonest" test results? Or, as I believe, is this simply a silly
assertion?
> . . .If you take the US sensor read transaction out of the loop
> then you are doing something completely different than Steve's
> pseudo-code required - at least, that is, if you are really
> interested in valid comparisons between different development
> platforms.
IMHO it is actually the most recent NBC code that is most different
from Steve's pseudo-code.
Anyone comparing the source code for ROBOTC, pbLUA and NXC posted on
Steve's website will find they have a faithful one-for-one mapping to
his pseudo-code. It's pretty hard to screw up. They all have a single
task with a 60-second timing loop and about 10 lines of code within
the loop.
All three solutions call the analog sensor device driver built into
their respective firmware to read the light sensor. ROBOTC and pbLUA
code also call the native firmware ultrasonic device driver while NXC,
without such a capability, has to do an inline I2C read macro
expansion.
The only source code that doesn't look like Steve's pseudo-code is the
recent NBC example. It uses a second parallel task to poll the
Ultrasonic sensor. ROBOTC and pbLUA don't have this second task; it's
not in the pseudo-code.
I'm not complaining about the divergences from Steve's pseudo-code in
the dual task code. It is a reasonable way to cope with the firmware
limitations and it is something that I hope Steve will allow under his
rules although there is a good argument otherwise. But I do think it
is unlikely that this technique will be widely used; at least not
until code for the second task is automatically generated by the
compiler / firmware as it already is for ROBOTC and pbLUA.
|
|
Message has 1 Reply:
Message is in Reply To:
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
|
|
|
|
