@RobotC developers:
reading through this forum, I don't find any single third party sensor with which your customers DON'T have any problems .
The last unresolved question was to the color sensor!

Please be kind enough to publish easy to use driver codes - without having to start any endless tasks and I2C-feedings, just like the example of Hitechnic that I have published beyond NXT Programming: Tips for Beginning with ROBOTC.

THIS IS URGENT!

Then these driver codes can be easily copied by RobotC users and also can be updated easily by you .

Every sensor value must be able to be read like the original Lego sensors



or at least like in my compass driver example like



for the color sensor this maybe has to be modified like



anything else is unreasonable for your customers!
Please contact the third party manufacturers to improve those driver codes!
It's also a very bad advertisment for RobotC if those easily to handle drivers are not available!

I think you're having a little trouble differentiating what you want from a nxt language and what others might need. I would imagine that the guy who wrote it wanted a compass sensor that ran as a constant task. That's what he needed at the time and he was gracious enough to let us see and use the code for our own projects.

I've found all the sample i2c code to be very helpful and had little or no trouble with my projects. There was a learning curve, but that was part of the fun.

The way I look at robotc is that it's a package that bridges the gap between nxtG and c for other microcontrollers where there usually aren't drivers.

If they wrote robotc to work specifically with each third party sensor, it would come up short when it came to custom sensors. I believe they did this the right way. It's a little hard to understand at fist, but it does make sense. And it's a lot easier than writing you're own i2c code directly in c/asm.

It's really not hard to dissect the sample programs and tailor them to your needs. You could easily modify the compass code to be poll only. You can always ask for help if you are having trouble.

There are examples to use I2C messaging and many drivers are supplied for custom sensors, you need to look for them. They are in the:

C:\Program Files\Robotics Academy\ROBOTC for Mindstorms 1.17 Beta\Sample Programs

As a software that is designed for educational use, I don't agree with making every single feature a simple command. I2C messaging is not easy and is very complex, and is different than using analog sensors. By dumbing down the code, I see it as a disservice in not showing the user what is really going on. It basically is two micro controllers talking and exchanging information. There are so many possibilities with this type of communication, it is going to end up complex and the current system works very well, but has a learning curve too.

I am just like you, I am a fellow enthusiast who has learned everything about c by experimenting and using RobotC. I'm not part of the development team and I thought the same thing when I started I2C lol, why does it have to be so hard! . But over time I have realized that it does work and involves allot of work. Just hang in there and look through the examples, you will do fine.

Remember, many custom sensors do have an analog mode where you can define the sensor as a sonar and use it similarly.

Scott B-)

hi,
In programming I'm not just a beginner, in hardware programming I am!
And this may relate to many RobotC users.
Please recall: what may be the reasons to anyone for buying RobotC?
To me it was (and would probably be for most of others):
- do anything what's possible with NXT-G, but in a script language
- do it quite easily like NXT-G, but in a script language
- do it similar to NXC or pbLua, but with more features
- if you need help, you'll get it like by the NXC or pbLua developers, but more, easier, and faster
- get access to anything that can be attached to the NXT, and don't have to worry about technical details: just plug and play!

Using a NXT-G block, you don't have to think about any I2C connections, failures, value checking. You plug it and it works. That way RobotC driver routines should work, too. If anyone wants to program "machine-oriented" he might do it - but he must not have to do it. (Like programming Windows applications: I want to write a program, and I don't want to think about how to draw a form, a button, a panel, or a drop down menu, and how to erase it and free the memory).

So please give us easy-to-use interfaces to any third party sensor (like the compass sensor driver by Hitechnic that I posted) and don't let us crush our heads thinking about I2C.

OK?

By the way: the pbLua developer even speaks German and posts and gives help in a German Mindstorms forum!