Mindboards

I just said that the firmware has a field in the Input module IOMap that it calls "SensorRaw". That field is what you read when you call the SensorNormalized(port) function in NXC. In NXC this field is called NormalizedValueField. There is an NXC API function called SensorRaw(port) which does not return the value of the NormalizedValueField (which is called "SensorRaw" in the firmware source code). The SensorRaw(port) NXC API function returns the value stored in the Input module IOMap field that the firmware calls "ADRaw" which is called RawValueField by NXC.

For some reason you said:

SensorNormalized is reading the NormalizedValue (aka SensorRaw)...
The normalized value is available in NXC via SensorNormalized(port) or GetInput(port, NormalizedValueField).

aah, I see..
and by SensorRaw(port) if I undestand correctly...?

And I have now had to repeatedly try to clarify this. No, you cannot read the normalized value via an API function called SensorRaw(port) in NXC even though in the firmware source code the normalized value field happens to be called "SensorRaw".

John Hansen

John, could you pls change that (I honestly don't understand a single word)?
that is horrible and confusing and weird.
Please sacrifice those weird and odd definitions.

Most of all I would like to have a standard function
void InitSensor(port, SensorType) (or SensorInit) where SensorType is ANY type (analog, US, HTGyro, MSSumo, i2cLS, i2cHS and RS485/COM) (i2cHS for future like implemented by RobotC, RS485/COM for legacy HighSpeed)).

No more SensorTouch, SensorLowSpeed, SensorTemperature, SensorLightActive and all that. You may transfer them to kind of sensor types, not sensor initializing functions.

Then I'd wish to have
SensorValue(port, &value[]) which returns one or more dimensional sensor values, if not specified then returning the real raw values like the former SensorRaw() (0-1023)

Then I wish to have a
SensorUnit(port)
which may specify specific units like percent, inverse raw( 1023-0), touch, pulse, edge, normalized or scaled (what ever the latter 2 might be - i'm not supposed to use them EVER) .

That would make the usage VERY much more transparent and logical.

I know that this is VERY much non-Lego-like but very much comfortable for users for the future (legacy functions could be kept unducumented until extincted some day).

I'll add that to the wish list, just for the record :)

Doc, is there any reason why you can`t write your own functions to do what you have just described? I`m sure if you did so John would consider including them in the nxc library...

for analog sensors only rudimentarily possible, but not for i2c sensors or chimeras like the color sensor. I firmly believe that a lot of firmware changes (away from Lego compatibility) will have to be made for that functionalty, but I don't understand much about that.
I am no hardware programmer unfortunately...