Most Prolific Poster Award

Discuss anything and everything. Keep it clean (or else).
HaWe
Posts: 2500
Joined: 04 Nov 2014, 19:00

Re: Most Prolific Poster Award

Post by HaWe »

[OT]
mightor wrote:
So why have drivers for NXT-G and not for NXC?
I already explained it to you. If you don't make drivers for a particular programming environment then you don't need to support them. That saves time and money.
HT does not support these Tetrix controllers, Lego Education does. If you find the support for NXC lacking then you need to take this up with Lego Education, not HT.

But HT is the manufacturer, right?
And they provided a i2c register table for Mux commands, right?
You can build a standard driver from it, sending the published values to the published registers, right?
And this has already be done (by me, by you, by some others), right?
But they don't work because the controller doesn't obey to the (simple, standard) commands, right?
But with Lego blocks it works - is that correct? Or isn't it?
So if it's working with the Lego blocks: then the published documentation is faulty, because Lego then must have used others than these instead.
Or isn't it working with the Lego blocks? then the controller firmware is faulty - or the documentation - or both.
But does HT care about anything of that? No.
Right?
[/OT]

matt: 644 / me: 629 :(
mightor
Site Admin
Posts: 1079
Joined: 25 Sep 2010, 15:02
Location: Rotterdam, Netherlands
Contact:

Re: Most Prolific Poster Award

Post by mightor »

You can build a standard driver from it, sending the published values to the published registers, right?
A list of registers does not always tell you the sequence of commands that need to be sent to a controller. It's like a description of every single button on an oil rig, does not tell you what you need to do to get oil out of the ground.
And this has already be done (by me, by you, by some others), right?
I just took a wild guess at some stuff and it didn't work, no big surprise there.
But they don't work because the controller doesn't obey to the (simple, standard) commands, right?
Just because it doesn't work the way you command it to, does not mean it doesn't work when you use it properly.
But with Lego blocks it works - is that correct? Or isn't it?
I have no idea, I would assume so or it would not have passed LEGO QC.
So if it's working with the Lego blocks: then the published documentation is faulty, because Lego then must have used others than these instead.
No, they probably just use them in the right sequence. A protocol analyser would help in this case and is often how I figure out how these things work.
But does HT care about anything of that? No.
Because they don't support that product, LEGO Education does. Do they care that you can't use it with NXC? Not a chance.

If you have a problem with the lack of support for NXC, complain to LEGO, not HT. HT does not control this product, they merely manufacture it.

I consider this subject closed now. If you want to complain more about it, I suggest you take it up with LEGO. All subsequent posts which I deem to be whining for or about support for this sensor, will be removed. I am not joking. You are bordering on trolling and you know it.

- Xander
| My Blog: I'd Rather Be Building Robots (http://botbench.com)
| RobotC 3rd Party Driver Suite: (http://rdpartyrobotcdr.sourceforge.net)
| Some people, when confronted with a problem, think, "I know, I'll use threads,"
| and then two they hav erpoblesms. (@nedbat)
Locked

Who is online

Users browsing this forum: No registered users and 0 guests