Embedded Linux: Dilnet/PC, Colibri Modul... wer macht mit?

[PicNick]

Damit ich auch was gescheites sagen kann:
Die Sache mit dem Programmaustausch Saftware, Treiber etc. hat derzeit noch den Haken, daß es kaum Standards (Schnittstellen, Protokolle,etc) gibt, die mit Controllern vernünftig anwendbar sind. Dadurch kocht jeder Compiler und Benutzer sein eigenes Süppchen (oder muß es sogar).
Wenn einmal das sichere Terrain "master/slave" verlassen werden müßte, fangt es meist zu dampfen an.
Ich weiß nicht, wie und wo ich dir helfen kann, aber wenn du Kummer hast, mach einen Thread auf, virtuell auf die Schulter klopfen kann ich dir allemal, manchmal fällt mir ja auch was ein.

[Schlebinski]

hehe =) ok das würde heissen, wenn man so ein Projekt aufziehen wöllte (also ich will es ja aber es müssten sich ja auch Leute finden die mitmachen) müsste man sich auf einen gemeinsamen Standard einigen, also in erster Linie welcher Controller? Verstehe ich das richtig? Wenn man sich aber auf allgemein Linux übliche Standard Compiler einigt müsste das doch theoretisch klappen? Und das auch mit verschiedenen Controllern?
Aber wenn man zu mehreren sich auf die komplette Hardware einigt und jeder baut das gleiche Maschinsche nach gemeinsamer Abstimmung, hätte man wohl den größten Erfolg.
Achja und was meinst du in dem Fall mit master/slave? Den Erbauer und den versklavten Roboter?

[voidpointer]

Ich denke, wenn man embedded Linux benutzt, kann man auch Software zwischen verschiedenen Controllern austauschen. Die Tücke steckt natürlich immer im Detail, aber gerade im Bereich I2C gibt es schon Treiber für viele Devices (z.B. Temperatursensoren), die man dann gar nicht erst entwickeln muss.

Wenn es doch Roboter gibt, wo sich die Sensoren und Treiber unterscheiden, kann man sich immer noch auf einer höhreren Abstraktionsebene treffen - so eine Art Robo-Schichtenmodell. Aber das müssen dann alle Beteiligten wollen und die Gefahr ist groß, dass jeder wieder sein eigenes Süppchen kocht. Im Prinzip muss die Anwendung des Roboters schon ziemlich übereinstimmen, damit man eine gemeinsame Basis hat.

Zum Gumstix: OK, es hat einige zig Dollar Versand gekostet, aber bei dem aktuellen Kurs war es immer noch günstig.

Und ja, es ist natürlich einfacher, wenn I2C hardwaremässig unterstützt wird.

[Schlebinski]

aber es gibt doch bestimmt eine gute Möglichkeit das I2C selber zu realisieren, zum Beispiel hiermit:

http://www.semiconductors.philips.co...PCA9564PW.html

Hat hiermit jemand Erfahrung? Oder einen AVR könnte man doch auch als Wandler benutzen.

[PicNick]

Morgen !
Mit Standard mein ich zuerst mal hardwareunabhängige Dinge
Beispiel Kommunikation Embedded <> MC
Zwischen den beiden müßt sowas wie ein Protokoll stattfinden. Warum erfinden ?
Man könnt ja IP abkupfern, dann könnt man am embedded mit normalen Socken hantieren.
aber: mit kleineren MC wird der Overhead zu groß
So ein Protokoll auszuhirnen, hätt noch garnix damit zu tun, wer welches Betriebssystem oder Compiler verwendet.
Jeder könnte seine Peers programmieren und wüßte von vornherein, wie sich sein Parten am anderen System verhält.
Master /slave *hehe* Die meisten Implementierungen zeigen Schwächen, wenn sie mal nicht das große Wort führen. D.h. bestimmen können, WANN der Partner was will.
*lall* ungefähr verständlich, was ich meine ?
Es gehören die Eigenschafte diverser Klassen und Objecte überhaupt mal theoretisch definiert.
Konkret schreiben kann man das dann, wie man will.

[voidpointer]

Die Idee mit TCP/IP ist nicht schlecht. Meines Wissens wird eine schnelle Version z.B. in Kampfflugzeugen eingesetzt, um die verschiedenen Bordrechner zu verbinden. Aber für µCs ist es zu oversized. Man sollte sich an den vorhandenen Bussystemen in diesem Bereich orientieren, und das sind z.B. I2C, CAN, RS232, RS485 und noch einige parallele Busse. Sinnvoll ist hier, den Linux-Controller als Master zu definieren und die Sensoren und kleinen µCs als Slave. Falls erforderlich, kann es auch ein Multimastersystem sein, was aber auch ein paar Probleme mit sich bringt.

Was die Software betrifft, so gibt es sicher eine Menge Literatur, die den prinzipiellen Aufbau beschreibt, den man nachempfinden kann (Sensor- / Aktorschicht, Regelungsschicht, Navigationsschicht, Nachrichtenaustausch usw.) Es ist ne Weile her, das ich mich mit sowas beschäftigt habe und mittlerweile müsste sich im Web oder sogar hier im Forum einiges dazu finden lassen.

Der PCA9564 ist ne feine Sache, aber vermutlich muss man sich dann den Treiber selbst schreiben. Und den Baustein über parallele Pins anzusprechen kann auch mühsam sein.

Hier noch ein Tipp für die Auswahl: der Cobra5485 (http://elmicro.com/de/cobra5485.html) bzw. der Cobra5282. Beide mit µClinux und leider ziemlich teuer.

[PicNick]

Mein Gedanke ist der, wenigstens mal die ersten drei Layer zu definieren. Auf welche Art das dann physich übertragen wird, könnt' da mal wurst sein.
Man müßte ja auf jeden Fall Repeater, Bridges und Router möglich machen( Ihr kennt ja das OSI-Zeugs ).
Nach oben im stack ist es aber auch so, daß wir erst garnicht "Rechner" als Ziel oder Absender enumerieren dürfern, sondern gleich davon ausgehen, das eine undefinierte Menge von Objects miteinander quatschen, die irgendwie in diesem System verteilt sind.
Analog dazu könnt man die Sockets verstehen, wenn man beim IP-Beispiel bleibt.
Ziel wär es, daß irgendein Programm-teil durch logische Adressierung (DNS artig) dem Stepper-#x seine Schritte befiehlt, ohne sich drum zu kümmern, ob das über I2c, RS232, etc. oder alles zusammen geht.
Es sollt einer applikation auch sch.. egal sein, ob ein Entfernungsmesser mit IR oder US arbeitet, solange er vernünftige Werte liefert

Wie gesagt, Vorbilder gibt's in Masse, is ja auch nix originelles, aber man muß die Sachen ein bißchen zuschneidern, 1:1 is Overkill, auch ein Mini-Tiny sollte irgendwie mitspielen können

[Schlebinski]

ui das ist echt teuer

http://www.toradex.com/d/products.html

was sagt ihr zu dem? 99 euronen für dieses krass ausgestattete teil ist nicht schlecht. es wäre nur wichtig, dass man den gleich mit telnet und ftp server bekommt, sonst müsste man wie vorgesehen maus, tastatur und bildschirm anschließen. ich werde mal kontakt mit denen aufnehmen.
wie läuft das überhaupt bei diesen embedded systemen, wenn man das system zerschießen sollte und nichts mehr läuft? kann man den flash problemlos neu beschreiben?

[Schlebinski]

ah hab eben letzteres gefunden, man braucht anscheinend beim colibri einen speziellen steckverbinder, der an den parallelport eines pc's angeschlossen wird, hierüber kann dann geflasht werden.

[Schlebinski]

@PicNick: ich muss zu all dem sagen, nur dass du mich einschätzen kannst, ich versteh grundsätzlich worum es geht, auch wenn mir manche begriffe nichts sagen, habe aber noch nie ernsthaften kontakt mit solchen problemen gehabt, d.h. meine augen sind bestimmt momentan größer als mein mund bzw magen, aber der anreiz ist groß also ist das ganze für mich hoffentlich machbar

hab mich noch ein bissl mit dem colibri befasst, also was ich da vorhin laut gedacht habe ist wohl alles kein problem, d.h. der colibri scheint momentan die beste wahl zu sein, die frage ist nur wieviel ärger erspare ich mir, wenn ich das (leider teure) evaluationboard dazukaufe. eigentlich sollte es ja ohne gehen...