NXC API: HTsmux implementation

[HaWe]

hey,
I can't find a NXC API implementaton for the HT sensor mux, but just the file provided on the HT website.

So for a new NXC API HTsmux implementation I would appriciate if the Sensor and SMUX port combinations could be divided into separate sensorport and muxport values to be passed, e.g.
instead of

Code: Select all

smuxSensorLegoUS(msensor_S1_1); //or 
smuxSensorLegoUS(msensor_S3_2)

it would be better to have it this way: // start counting at S1=Mx1=0 as usual in C

Code: Select all

smuxSensorLegoUS(S1, Mx1); == smuxSensorLegoUS(0,0);
smuxSensorLegoUS(S3, Mx2); == smuxSensorLegoUS(2,1);

the reason is: if the order of the attached sensor ports is reversed (e.g., later on, while building and developing a certain robot project) then only the first parameter has to be adjusted,
and if several mux ports have to be polled one can count through the mux ports just by a for(Mx=0...3) -loop

[mightor]

The sensor ports are labelled 1-4, as are the SMUX ports, it was a conscious decision to name the constants the same way. If you want new functionality, I suggest you implement them yourself and ask HT to update the driver on their website. I wrote this driver a long time ago an no longer maintain it. It should be trivial to make these changes.

= Xander

[HaWe]

Although your comment is OT - if it was trivial to me I certainly had already made those changes a long time ago by myself.
But actually it's not trivial because of many cross-overlapping #defines - it's quite obfuscated and I don't see through it.

Moreover, if I make a suggestion about an improvement it is quite impertinent to answer "it's trivial, do it by yourself and publish it to HT".

But anyway, back to topic:
the topic was not about you or Hitechnic support but about a new implementation integrated in the NXC API (like e.g., SensorUS or SensorHTGyro).
Lego labels also it's NXT sensor ports as 1,2,3,4, nevertheless S1,S2,S3,S4 in NXC are defined as char 0,1,2,3.
So muxports labeled as 1,2,3,4 could by accessed as Mx1,Mx2,Mx3,Mx4 which also might be defined as char 0,1,2,3.

But my fundamental suggestion actually was not about start counting but about splitting those weird combined addressing constants like e.g.,
msensor_S3_2,
into a unique sensor port address (like S3) and a unique muxport address (like Mx2).

[mattallen37]

Have you considered writing a simple wrapper function for it?

How about bit shifting, like this?

Code: Select all

smuxSensorLegoUS((S3 << 2) | Mx2); // smuxSensorLegoUS((NXT_Port << 2) | MUX_Port);

[mightor]

It's not impertinent when I'm the one who wrote the code. It was written a LONG time ago and if John hasn't implemented it yet, I wouldn't bet on it being implemented any time soon, I am sure he has his hands full with other stuff. This code works fine and was written by me and tested and verified by John. There is very little added value to integrating this with the standard NXC API.

The code is unsupported and unmaintained. If you want improvements, you'll have to do it yourself or find someone to do it for you. The API is the way it is to keep it as close to the ROBOTC API as possible.

Calling something off-topic because you don't agree with it or it's not what you want to hear is just silly.

You can convert quite easily between msensor_SX_Y values NXT/SMUX port and vice versa:

Code: Select all

#define HTSMUXreadAnalogueDH (X, Y) HTSMUXreadAnalogue (X*4+Y)

As for obfuscation, I think my code is extremely well documented, I've even included a few examples, as well as a nice HTML-ified API doc. If you didn't download it from here: [LINK] then you don't have the right one.

= Xander

[HaWe]

it was OT because the topic was not about you or Hitechnic support or doing anything by myself but about a future implementation integrated into the NXC API.

Indeed, I got my version from the HT website.
Of course I can handle the combined-address-thing by workarounds, the only thing I wrote was

So for a new NXC API HTsmux implementation I would appriciate if the Sensor and SMUX port combinations could be divided into separate sensorport and muxport values to be passed

[mattallen37]

Giving a suggestion, or presenting a work-around is not OT by any means. Xander is saying that since it won't happen in the official NXC API, here is the next best thing.

If all you want to do is present ideas without conversation, perhaps you should email them directly to John.

[HaWe]

I was not asking for help or workarounds, and I need no advice of you whom to mail to or not.
I just made a suggestion for an improvement for the future, for the benefit of everybody.

But it was crystal-clear that YOU had to have the last word.