TX und I2C - Wann wirklich ?? - Diskussion

[vleeuwen]

The discussion about the role of I2C in relation with the possibilities offers by RoboPro and the Transfer Area is more than two years old now.

Some facts:
I2C is a low level communication protocol.
The TA is not able to transfer a lot of byte during one transfer session.
For example a 100 by 100 pixel image will need 10.000 bytes. The TA is probably able to transfer 100 data bytes extra data a time, the transfer of an image will ask 100 TA cycles.

Most of the I2C sensors data are not direct usable at the more abstract RoboPro level.
There is a need for data preprocessing below TA level.
The best thing is to see the I2C bus in a way the RoboInterface is using the RS232 bus for messaging.

There exist more ways to implement the preprocessing of the raw I2c sensor data.
For example: take a micro controller (DSP) as I2C slave for the TX-C and let do the micro controller the data preprocessing for the I2C sensors and actuators.

Contrary to MS-RDS is RoboPro not so suitable for the implementation of complex mathematics.

My conclusion is that the TX-C I2C bus will offer to a small group of engineers the possibility to create nice sets of sensor/actuators.

[vleeuwen]

@Ford,
What you ask is possible.
You build/choose your own system that does two things:
1) Acting as a slave I2C for the TX-C (communication with the TX-C environment)
2) Acting as preprocessor for your sensors and actuators.
Your choice for the configuration of your system is completely free.
The programming language that can be used depends on your choice for the system.
More personal freedom is not possible.
See for example Elektor for some possibilities.

[sven]

Hallo!

Das ist der Bereich an fischertechnik.
Hier bitte keine Diskussionen!!!
Bitte nutzt dazu einen anderen Bereich im Forum!

Gruß
Sven

[lionfighter]

so was ist jetz? kommt i2c noch dieses jahr noch oder wird vorher schon ein Nachfolger des TX angekündigt?
Bitte Klartext und keine Vermutungen.

[vleeuwen]

Hi Sven,
Could you split up this item into a question about "TX und I2C - Wann wirklich ??" for FT and move this discusion about the use of I2C to the Computing section?

I notice that move the discussion, thanks
==========================================================================================
@general
I2C is a 3 wires protocol.
The use of a low level communication protocol is a lot more than connecting the 3 wires.
There is a need for device control software (drivers).

See for example the LEGO user LinkedIn group.
An I2C device has normaly its own power supply. I2C knows two power levels 5V or 3.3 V for the communication.

Some time ago I took a look into the LEGO I2C and I notice that LEGO has some possibilies to preproces I2C data localy.
The TX-C don't has that option.

In some discussions it is not clear to me: what user are expecting from the I2C bus in relation with the abstract level of ROboPro or the FTMscLib?

A strong point of the fischertechnik interfaces is the standard connectors. Why changing this to the LEGO-standard?

[sven]

Hallo!

So, habe das Thema mal geteilt, diskutieren könnt ihr nun hier.
Unter "an fischertechnik" gehört das nicht!

Gruß
Sven

[vleeuwen]

Hereby some links to the basics of I2C:
http://www.nxp.com/documents/user_manual/UM10204.pdf
http://www.nxp.com/documents/applicatio ... N10216.pdf
http://web.inter.nl.net/users/Ussel-Int ... c_i2C.html

A "I2C processor" has nothing to do with the I2C protocol.
It is the same concept as I already suggested, a microcontroller that does some prerpocessing of the I2C data to bring the device at a higher abstraction level. It is transforming I2C data to a higher abstraction level.
A "I2C processor" is not part of the I2C protocol.

The control screens which are included by you, are application that making use of the I2C bus to communicates with the device.
Like RoboPro is using USB to communicate with the device TX-C.

The TX-C is only offering low level I2C commands, and that is I2C simple and not more.

[Defiant]

..I can't stop laughing, please..you are killing me.

[vleeuwen]

There exist some smart I2C device that has already preprocessing of raw data on board.


However
the fuction ReadSensorHTAccel(S1, x, y, z) contains probabely more I2C commands and will do some manipulation with the byte stream from the I2C read command.
Can you show use the body of this function?

SetSensorLowspeed(S1); is not a I2C command, it is also a function that constructs at least a I2C write bye stream.
Can you show use the body of this function?

Suggestion:
Go to the LinkedIn group
LEGO Mindstorms Enthusiasts and Fans and search for the discusion about the low level I2C commands.
(I2C bus on LEGO bricks )

[thkais]

Hallo,

"Scheint an einem grundlegenden Hardware-Design-Fehler zu liegen"
Interessant. Du weißt da offenbar mehr, als ich. Kannst du da konkreter werden?

"oder an einer völlig ungeeigneten Firmware"
Dafür, dass dich diese Funktionen eigentlich garnicht interessieren, lehnst du dich mit deinen Diagnosen wirklich weit aus dem Fenster.

Leute, jetzt macht mal halb lang. Wir haben von ft die Aussage, es wird daran gearbeitet. Ich gehe davon aus, dass es wichtige Gründe gibt, weshalb sich das Release verzögert (schonmal daran gedacht, dass die Spielwarenmesse vor der Tür steht?). Wie es implementiert ist, wird man sehen - gleichwohl ist es wichtig, dass der Frontend einfach zu bedienen ist (auch für Anfänger) und auf der anderen Seite der Backend so flexibel ist, dass sämtliche Adressierungsarten (7-Bit und 10-Bit) realisiert werden können und dass erweiterte Adressierung (repeated start-condition) implementiert sind. Das sind Grundlagen der I²C-Kommunikation und das ist auch nicht von Lego erfunden worden

[thkais]

Hallo Ford,

Thomas - ich schrieb "scheint", und es war eine "oder"-Aussage.

Passt schon - worauf ich hinaus möchte: Der Personenkreis, der eine Eignung der Hardware beurteilen kann, dürfte sehr klein sein. Ich gehe mal davon aus, dass der Entwickler des TX schon wusste, was er tat.
Bei der Firmware liegt das ähnlich - hinzu kommt, dass die Firmware jederzeit austauschbar ist und damit Fehler ausgebügelt werden können (und wurden).
Falls ich dir mit meinen Kommentaren auf den Fuß getreten sein sollte - sorry.

[vleeuwen]

@Ford
I think that I miss your point. What is your message about I2C?
The TX-C concept and approach different a lot from the LEGO brick concept and approach.
The TX-C is not a LEGO brick.

LEGO is using I2C as base for his concept, Fischertechnik doesn't.
The actuators and sensor are controlled in a different way.
However in is possible to add I2C based components to a TX-C.
You are refering to third party sensors for the LEGO system.
These sensors consist of hardware and dedicated LEGO drivers.
These drivers are not loadable on a TX-C.

What you mean with C-script? Does there exist a standard C interpreter for standard ANSI-C?
Or is this a LEGO invention too?

A lot of sensors are not developed by LEGO but by third parties too.

I2C based sensors and actuators will have one big disadvantage.
I2C is asynchronous and this will give more latency and bad semi real time performance.
I read that the advice for the NXT is too calculated with a sample rate of 50 ms or higher is closed control loop situations.
With the TX-C this is 10ms (USB connection)

I already wrote that it is possible for third parties to develop and to add a good I2C preprocessor and connect that to the TX-C.
Rei_Vilo proved already that an I2C preprocessor is possible.
During the last FT-meeting in Schoonhoven AD shows already that it even possible to connect a I2C preprocessor to the RS485 bus.
What you want more? Develop you own LEGO based I2C preprocessor; this is possible.

[vleeuwen]

@Ford,
The LEGO concept is clear to me.

I already publish direct after the FT-convention 2010 that the TX-C will need a driver (low level preprocessing ) concept for the I2C devices. However there are more ways to implement this concept.
-) run the drivers on the TX-C as threads in the RTOS.
-) run the drivers on a dedicated microcontroller.

About:
<<script-Orientiert (Java oder C, Bytecode- oder Maschinencode-basiert)>>
It looks like that you mix up text based programming with script base programming.
Text base programming can be script or compilation based.
For Java, C you will need a compiler (one or more pass) and not an interpreter.
JScript is an script language.

Visual programming can be based on compilation or interpretation.
The VPL (part of MS-Robotics developer studio) has been based on compilation.
RoboPRo is also compilation, it is generating a complete program before it runs it.

Bytecode- oder Maschinencode is the end result (outcome) of a compilation process or interpreter process.

[vleeuwen]

@Ford,
From you reaction I have got the idea that you don't get the architecturale picture right of LEGO NXT and the TX-C and the place of I2C in both of these interface. This makes that your expectation and remarks about the TX-C are not always right.
1)
The plug and play is not part of I2C bus or protocol.
With the TX-C is possible to read and write I2C byte streams with the TX-C.
It is up to the I2C device to deliver I2C data that will have a meaning on the abstract level of RoboPro.
This is I2C.
The LEGO plus and play what your suggesting has nothing to do with I2C.
In your example It is only using I2C as lower level communication protocol.

2)
In case you like text based programming, this is available for the TX-C.
See the FtMscLib C based.
JAVA with JNI (I hope that you know what this is) is not the most suitable language for semi real time programming.
With the right JNI interface to the FtMscLib you will able to program in JAVA too.

[vleeuwen]

The “when question” is for fischertechnik and is allocated in a different forum.

My final conclusion:
The fischertechnik bus will offer third parties and (hobby) engineer a lot of opportunities to develop I2C based sensor/actuator systems.
The LEGO architecture different from theTX-C architecture but with the TX-C exist also a need for a kind of I2C hardware with corresponding driver combination.
However this preprocessor will probably be an external one or maybe a kind of driver on the TX-C itself. This first approach could be offer more freedom to the developers. It also does not exclude that someone creates an embedded Jave solution for it but there exists a lot of other options. See for example the experiments of Rei_Vilo (beta tester) and Ad (RS485 bus).

[Masked]

Hallo,
ich bitte Euch, insbesondere Ford, darum, die Diskussion mal ein wenig zurückzufahren.
Ja, I2C mag eine schöne Sache sein und Ja, ft hat es für den TX versprochen/angekündigt.

Aber bitte denkt nochmal drüber nach:
1. Wie viele Leute würden I2C wirklich nutzen? Wenn das 50 Leute im ersten Jahr werden, würde es mich überraschen. Die dazu nötige Entwicklungsarbeit steht meiner Meinung nach in keinem Verhältnis zum Nutzen. Insbesondere, da, wenn der übliche Rhythmus eingehalten wird, nächstes Jahr ein neues Interface fällig ist.
2. Wenn ft sagt, dass sie (bzw. in diesem Fall MSC und der RoboProEntwickler) daran arbeiten, dann tun sies auch. Aber im Moment ist Vor-Spielwarenmesse-Zeit. Und damit gibt es definitiv wichtigere Sachen zu erledigen. Getreu dem Motto: was schon 2 Jahre wartet, kann auch noch 2 Monate warten.
3. Der Vergleich ft<->Lego hinkt alleine schon aufgrund der Größe des Unternehmens. Lego hat eine dreistellige Zahl Entwickler (geraten), ft hat nicht mal eine Hand voll. Und die sind für die komplette Entwicklung zuständig.

Also: Beruhigen, Abwarten und Tee trinken. Drängeln hilft meistens schon, hier aber ausnahmsweise mal nicht.

Grüße,
Martin

[vleeuwen]

Hi Martin,
I agree with you, I already ended the discussion. The coming TX-C I2C implementation will give enough space for the small group of developers to create nice thinks. Maybe they like to act as third party.

To combine fischertechnik with a lot of other developments, there is the connection with the MS Robotics Developer System.
In this project is fischertechnik a partner.
In that area are already powerfull sensors available.
For example: using the XBOX Kinect to control a model (skeleton control) or the WII controls like the balance board is an option.

[Defiant]

Also Masked kann ich da generell zustimmen, aber wenn mit I2C Unterstützung geworben wurde, dann ist das eine einzige Frechheit.

du denkst doch nicht ernsthaft, dass ich mir die i2c-Beispiele aus den Fingern gesogen habe?

Das war auf den ganzen Thread bezogen nicht nur auf deine Beispiele.
Also wenn jemand anfängt die i2c-specs hier zu posten dann läuft was falsch.

To combine fischertechnik with a lot of other developments, there is the connection with the MS Robotics Developer System.

Which requires an active connection to a PC, right?

In this project is fischertechnik a partner.

Didn't you say the last time that you did all the work...nice partner than.

In that area are already powerfull sensors available.

No tricky when you have attached a PC.

For example: using the XBOX Kinect to control a model (skeleton control) or the WII controls like the balance board is an option.

Same both are so easy to attach with a PC, there is nothing special in your RDS there.

[thkais]

Na und?
Ich bin zwar über 40, aber du hast das nun so oft wiederholt, dass sogar ich es kapiere. Lego kann I²C. Schön.
Die Erde dreht sich auch ohne I²C weiter.

[Masked]

So, und eben langts.
Ich hab heute Mittag dazu aufgerufen, das ganze hier zu versachlichen und endlich aufzuhören, sinnlos OT zu diskutieren. Und erst Recht gehören keinerlei Beleidigungen oder Andeutungen in dieser Richtung hierher.
Da das anscheinend nicht funktioniert, mache ich hier jetzt zu.

Weitere Diskussionen zu diesem Thema wird es erstmal nicht mehr geben. Gründe siehe oben. Falls weitere Fragen auftauchen, bei denen eine Beantwortung möglich ist (also nicht, wann i2c eingeführt wird), dann wendet euch direkt an ft, die Mailadresse dürfte bekannt sein.

Wer sich beschweren will, kann das gerne bei einem meiner Admin-Kollegen tun.

Martin