Hallo. Ich habe eine Fragen zu Multicontrollern. Die wichtigste Frage ist, welcher Bus nun am geeignesten ist, wenn man am Ende die Controller im gesamten da stehen lassen möchte wie z.B. ein normaler Intel Quadcore. Sprich, die Software soll gar nicht merken, dass es sich hier im mehrere controller handelt. Man kann hier im Forum viel über RS485 oder den Can bus lesen. Ich kenne von früher den Can Bus sowie die Serielle Schnittstelle RS232. Ich kenne mich ganz gut mit Multithreading Programmierung aus und habe sogar schon mal ein kleines Multithreading Betriebssystem geschrieben allerdings nur für eine SingleCPU. Ich habe im Microcontrollerbereich bis jetzt nur im Single Mode gearbeitet. Wie ungefähr der Master-Slave Ablauf ist, kann man ja im Forum nachlesen, nur ist mir noch unklar, wie das ganze am Ende ablaufen soll. Irgendwie muss ja das Programm, welches am Ende ausgeführt wird, im Falle von mehreren Threads auf die Controller verteilt werden. Es wäre nett, wenn mir das Jemand etwas genauer erklären könnte. Nutzen möchte ich mehrere Arm-Cortex-a8 Controller. Ziel ist es, das ganze so Modular aufzubauen, dass X beliebige Module rangesteckt werden können. Bei dem RS485 Bus scheinen aber nur 32 Teilnehmer das Limit zu sein. Danke
Gast
#1627569
>Sprich, die Software soll gar nicht merken, dass es sich hier im mehrere
controller handelt.
Das sind abgehobene Konzepte. Und daher sehr weit weg. Als
eingearbeiteter Spezialist nach einigen Jahren Arbeit dran vielleicht...
Gast
#1627675
Wie soll die Hardware etwas aufteilen, was die Software nicht weiß?? wer bastel das auseinander und wieder zusammen ohne Software?
Du solltest erstmal das Ziel beschreiben. Und dann kann man nachdenken, wie es am besten zu realisieren ist. Nicht umgekehrt. Also nicht, sich irgendne Architektur ausdenken und danach versuchen, diese auf ne Anwendung aufzupfropfen, das geht schief. Peter
Wenn Du RS-485 verwenden willst, nimm 8-Bitter. Wenn Du 32Bit Boliden vernetzen willst, nimm Gigabit-Ethernet. 32bit paßt jedenfalls nicht zu RS-485. Peter
Kuck Dir mal die XMOS µC an, die sind für solche Aufgaben prädestiniert. Sind Nachfolger der früheren Transputer. Oder den Propeller µC von Parallax. Gruß Tom
Grundsätzlich einsetzen möchte ich es für Bildverarbeitung und Objekterkenunng. Es soll aber auch ein Spaßprojekt werden, welches ich über die Zeit immer und immer mehr erweitern möchte. Von daher ist mein Ziel, erstmal einen Arm Cortex zu benutzen, ihn als Modul aufzubauen und dann mit einem anderen zu erweitern usw. Und MarioT: Bei anderen Computern wie beim X86 weiß die Software auch nicht wieviele CPUs bzw. Kerne zur verfügung stehen und da geht es ja auch. Das regelt dann das Betriebssystem oder in diesem Fall die Firmware. Das mit dem Gigabit Ethernet klingt erstmal komisch, es ist zwar schnell aber hat es nicht eine relativ hohe Latenzzeit?
Gast
#1628332
naja beim X86 geht es aber auch nur wenn die Software darauf ausgelegt ist (also selbst in kleine Teilprozesse zerlegt ist). Wenn es nur ein thread ist so bleibt es bei einem Prozessor und der Rest wartet ab was so kommt.
Gast
#1628340
da musst du mit verteilten Systemeen arbeiten.
Gast
#1628401
>Und MarioT: Bei anderen Computern wie beim X86 weiß die Software auch >nicht wieviele CPUs bzw. Kerne zur verfügung stehen und da geht es ja >auch. Das regelt dann das Betriebssystem oder in diesem Fall die >Firmware. Ich hätte jetzt behauptet das ein Betriebssystem oder Firmware Software wäre. Ich kenne mich nicht so aus, aber wenn ein "Arm Cortex" ein solches Betriebssystem oder Firmware hat, wo ist dann das Proplem.
Wie ich selber schrieb:
1 | |
2 | |
Also ist mir wohl sehr wohl bewusst, dass das nur geht, wenn das Programm dafür ausgelegt ist. Um mal eine andere Möglichkeit zu nennen. Es wäre ja möglich sich mehrere BeagleBoards zu kaufen (Beitrag "Neu im Shop: BeagleBoard (1200 MIPS ARM Cortex M8, TMS320C64x+ DSP)") und diese dann über SPI zu vernetzen. Es wären zwar viele Bauteile dabei die unnötig und doppelt sind aber wenn man sich mal den Preis von 150 Dollar anguckt, kommt man niemals günstiger bei weg, wenn man alles selber baut. Es wäre auf jedenfall die einfachste Lösung, wenn auch nicht die schönste. Auf jedenfall bietet das Board mehrere Bus Systeme an, welche sehr praktisch zu sein scheinen. Und nein, die Firmware muss man eben selber schreiben, das ist ja der Trick dran.
Gast
#1629140
Wenn du grosse Daten schieben möchtest und das sehr schnell dann ist der SPI falsche Wahl. Die FPGA's bieten sehr schöne Schnittstellen, dort könntest du deine Kommunikation zwischen Beagle Boards ermöglichen.
wie genau meinst du das mit den FPGA's? Ich hab mal ne weile mit nem FPGA von Xilinx gearbeitet aber so ganz mein Fall war das nicht. Könntest du da bitte mehr ins Detail gehen?
Gast
#1631693
Mario, wenn das ganze hinterher mal eine ordentliche Leistung bringen soll, dann müssen die einzelnen Controller über einen richtigen Hochgeschwindigkeitsbus vernetzt sein - wenn man das in Software machen will, verbrät man nur wieder Rechenleistung. Da bräuchte man schon Prozessoren, die für Mehrprozessorsysteme gebaut sind.