hi to all!
may I just remind to my thread opening question?
Is there meanwhile a solution in sight?

Hi Ford,

In my opinion a RS485 connection is just a connection between a lot of controllers, sending only data, with or without a master.
It is up to the user what the robot does with this data.

On this thread are some code samples, including my own, whitch can do this.

Creating a program whitch can do almost everything, like running motors with speeds and encoder targets, reading and writing to i2c sensors, will get a lot of data beiing send and taking a lot of CPU time, whitch results in a slow connection, when you are using more bricks.

Regards

hi,
I think you are wrong.
If you don't send or poll at any time, the RS485 data transfer won't need much cpu time.
I'm sure this type of bidirectional communication can be made, though it surely won't be trivial.

@Dick Swan:
Hello,
sorry if I have to ask again, I still didn't understand your intentions:

Because Bluetooth is far too slow to read sensors and motor encoders, a fast RS485 sending/receiving mode is needed.
What exactly are your plans for the implementation of RS485 in order to use a 2nd brick as sort of motor and sensor expander?

He is not talking about using BT to send messages. He is saying to use the same comms scheme as used by the BT system where messages are sent to mailboxes which are then read by the recipient.

Xander

thx, I misunderstood this.
So here my (new) question:

@Dick Swan:
Hello,
sorry if I have to ask again, I still didn't understand your intentions:

A fast RS485 sending/receiving mode maybe like bluetooth is needed.

What exactly are your plans for the implementation of RS485-TCP in order to use a 2nd brick as sort of motor and sensor expander?

@ docilio,
@ ogait,
@ Dick Swan:

I'm also highly interested in using this mux feature (by RS485 as well as by BT):
what about your code you promised to develop?

yes, docilio and ogait: any news about this?

sorry about that...

university is killing us...

as soon as possible, we will publish more...

you seem to have a lot of ideas (RS485 network, Bluetooth network, hardware development like multiplexers) but all I can see are those announcements.

What do you think if you better made less announcements and more improvements?
Mabe you could take the BT network as a first project to be finished?

yes, you are probably right...

My main priority is university. My second priority is my robotics team.

On my team, all that i am trying to do it would be very usefull. So, if i can do it, it is very good to me too...

I study in a diferent city of Ogait, and also in a diferent city of my team workspace, so only on weekends i could work with NXT.

I really need to have that thing on BT, but it's not easy.

It's not just say, "i will create the code today" and do it like that. If it's easy after is created, before needs work, so please don't rush me...

So, whenever it's finished, you and robotc forum would be the first to know it.

ok, I can completely understand your point, no question about this.

But then it's better if you made no announcements that you or Tiago will do that kind of work.
If you can't do it by now or close to now ( and I can fully understand that ) it was better if you announced NOTHING UNTIL you've done it.

BTW: My last request was primary addressed to the RobotC developers



- I appreciate if also anybody else wants to do the job, but if he takes the efforts, he should do it promptly. Otherwise he wastes the time of all the others.

I also appreciate the developers to establish a fast RS485 or at least a simply usable Bluetooth network for motor and sensor multiplexer functionality.
In NXT-G there are simple blocks, such thing should be available by RobotC macro commands, too.

yes, GWingz, that's the idea, but in spite of being a simple idea, it's not easy to create it...

Asap will be here...

if you don't have the time, docilio:

@Dick Swan: could YOU plz make it quickly available?