hi,
I would appriciate very much if the sensor values of Lego and third party sensors could be polled in the same way, e. g.


another idea to general I2C sensors:



This would simplify the requested program code to a very convenient level !

Great idea. But....

This only works if a sensor has a single returned value. This is not the case for many sensors including:
* Two axis gyros that return two 16-bit values
* Cameras that have many, many returned values.
* Two axis accelerometers with two 16-bit values
* Etc.

There doesn't seem to be a nice clean way to provide a common end user interface to these!

One way this is handled is by the hardware manufacturers. For example, the HiTechnic color sensor can be configured in "basic" mode where it behaves similar to a ultrasonic sensor. It returns a single value (range 0 to 16). But it has a more powerful mode where it returns 3-different 16-bit values for the three different color components.

OK, I see, sth. like

won't work with a Cam.

But maybe



The I2C protocoll is much too complicate to handle. This really needs to be simplified a lot.
Why can't you implement a sensor protocol that allows some easy access to all sensors, equal if I/O, analog, or I2C (see above)?

As you said yourself, RobotC has been designed for beginners and novices.
An I2C protocoll is far too a low hardware- and bit-shifting level and appears to be more suitable for kind of professional embedded C programmers.

Novices and beginners need something like that 1 sensor block in NXT-G, but transfered to a convenient script language:

To get any sensor value, one line of RobotC code must fit!

You're absolutely right! Individual programmers should not have to write drivers for each 3rd party sensor that they own.

The ROBOTC sample program includes drivers for a few of the 3rd party sensors. I had hoped that the sensor manufacturers would use these samples to write drivers in ROBOTC code the same way they have written NXT-G blocks; unfortunately they haven't!

The NXT-G blocks for 3rd party sensors are in fact complicated subroutines that "compile" into many instructions of the NXT-G virtual machine. These are masked from the end user.

THe sample drivers for ROBOTC behave similarly. They are code written in ROBOTC contained in a separate #include file. They usually have a simple interface which is all the end user needs to know about.

In fact, the simple sensors with a single value can be accessed with the "SensorValue[xx]" variable used throughout ROBOTC since the driver code is allowed to write to this value.

As time permits, additinoal driver files will be added to ROBOTC.

That's really poor!
From the view of the customers, it seems that completely developed RobotC drivers are available just like NXT-G sensor blocks, because the manufacturers (Mindsensors, Hitechnic) picture your "RobotC label" on their websites.
That every single programmer has to write his own routines is unreasonably and impudently (babelfish English, sorry ).
Why don't you forbid them to show your trademark label, if they they don't hold, what they promise!?

I'll gladly wait for it...
Maybe we can start meanwhile publishing such private written drivers, if the code will be checked by you (just as I started with the HT Compass driver, see my posting in "NXT Programming: Tips for Beginning with ROBOTC")

I'm all for user contributions.

Did you notice that the compass sensor driver is one of the samples included with ROBOTC? There's two files -- a driver file and a sample of its use.

no, I didn't!
I probably e-mailed 20 times to Hitechnic, cause with the drivers I found I didn't get it to work.
Could you plz check "my" code and compare it with yours (especially the calibrating part of the routine)?
If the code is the same, I will delete my post.

I meanwhile found some compass code of you (I think), but
- it's much too complicated to handle
- it lets you not calibrate the sensor.
- some endless tasks are started, which consistantly search, if a compass has been connected (this is absolutely unnecessary, cause I know where I have attached a sensor, the driver must not search for this!) .

I think the Hitechnic Code (and my small header file adjustement) are the best and most convenient for the moment.

Maybe you can improve the code further on to initiate and access the sensor like

using the same routines, but expanding the RobotC syntax for sensor access (?) - I can't do that.
(it's hard to explain for me in English. What I mean is:
die Routinen des HiTechnic Codes sollen beibehalten werden, aber die bestehende RobotC Syntax für den Zugriff auf Sensoren soll entsprechend auf den Kompass erweitert werden)