Hallo! ich bin noch n00b in AVR prozessoren, Nun meine Frage: ist es möglich, ein echtes multiprocessor system mit mehrere AtMega8 auch mit 16Mhz zu schaffen ? Die MCUs könnte über I/O ports kommunizieren. Programmierer können ihre Programme in sogenannte Threads teilen. Diese übernehmen dann die verschiedenen Aufgaben des Programms. Die Kommunikation kann man mit Interrupts über I/O machen. Die Aufgabe für mehr als 2 MCUs sehe ich schon nicht trivial.
Hi, das ist relativ sinnlos. Es ist wohl möglich, seine Programme auf zwei (oder mehr) Controller aufzuteilen, die dann z.B. mittels SPI kommunizieren, das macht aber auch nur dann Sinn, wenn man das Programm in zwei (oder mehr) Teile aufspalten kann, die einzelne Aufgaben erledigen. Es wäre z.B. möglich auf einem Controller eine kleine 3D-Engine einzubauen und das Bild dann über irgendeine Schnittstelle zum anderen Controller zu schicken, der es auf ein entsprechendes Ausgabegerät (Display) ausgibt. Das hat den Vorteil, dass der Controller für die Berechnungen den gesamten RAM frei hat und nicht nebenbei noch das ganze Bild puffern muss. Selbstverständlich wäre es für diese Aufgabe auch möglich einen Controller mit mehr RAM zu verwenden (Sofern möglich). Eine andere Notwendigkeit für mehrere Controller sehe ich sonst noch in den Pins. Hat man z.B. sehr viele LEDs die einzeln angesteuert werden müssen, ist es möglich, mehrere Controller zu verwenden, von denen jeder jeweils einige LEDs ansteuert. Alles andere macht aber u.U. nicht wirklich Sinn.
@Philipp Burch Hast du etwas über Fast-Fourier-Transformation gehört? Die kann ganz gut auf mehrprozessorsystem funkzionieren: SOUND =>[ADC]->MCU1_ALU->[I/O]->MCU2_ALU->[I/O]-> SPECTRUM => steht für Analog signal -> steht für Digital signal Danach, kann man z.B. im MCU3 das Spectrum analysieren und bestimmte aufgaben lösen.
>ist es möglich, ein echtes multiprocessor system mit mehrere AtMega8 >auch mit 16Mhz zu schaffen ? Selbstverständlich. Selbst mit 1 Hz Taktfrequenz geht das. Das ganze System ist dann halt sehr langsam. >Die MCUs könnte über I/O ports kommunizieren. Ja. >Programmierer können ihre Programme in sogenannte Threads teilen. Das können sie aber auch auf nur einem einzigen Controller realisieren, und zwar viel leichter. Für viele Aufgabenstellungen reicht ein simples kooperatives Multitasking völlig aus. >Die Aufgabe für mehr als 2 MCUs sehe ich schon nicht trivial. Wie die Erfahrung lehrt, ist die Aufgabe bereits bei 2 MCUs so unvorstellbar knifflig, dass kein vernünftiger Mensch an einen zweiten Controller denkt, solange er dafür nicht einen ausgesprochen guten Grund hat. Die Ansteuerung von 200 LEDs zählt übrigens eindeutig nicht dazu. Das Erweitern von Ports erledigt man üblicherweise schmerzlos und effizient z. B. mit Schieberegistern.
@AVRFan Mehrprozessorsystemen sind ganz popular im Roboter-technik; es gibt manche roboter, die mehr als 10 MCUs im parallel geschaltete haben, z.B im Advanced Motion Control, Visual Recognition, Speech Recognition
in meiner neuesten Entwicklung sind 4 Microcontroller vorhanden, 3 haben etwas weniger zu tun, aber der 4. ist total ausgelastet. Ich habe mir neuerdings angewöhnt jede Baugruppe, die ich für Steuerungszwecke entwickel, mit Micorprozessoren auszurüsten. Kostet kaum mehr und bin in der Anwendung sehr flexibel geworden kann so z.B. problemlos Zeitprobleme umgehen.
Kann es sein, daß Du Multi-Core/Multitasking/Multithreading mit Outsourcing verwechselts? Selbst bei den Robotern macht man das so. Ein Kern ist der Server, 1 bis n Positionscontroller, 1 bis n Motorsteuercontroller, ein Protokollcontroller, ein Ausgabecontroller, usw... Die laufen alle parallel aber nicht als Multi-Core-System. Man hat die Aufgaben nur aufgeteilt, um die gesamt Leistung zu erhöhen. Das mache ich auch in meinen Projekten so. Ich habe ein "Server" der die Aufgaben an die unterschidlichen AVR's verteilt. Und selbst die "Slaves" können sich untereinander Aufgaben zuteilen, ohne das der "Server" damit belastet wird.
Es ist heutzutage üblich, intelligente Sensoren und Aktoren zu benutzen, die dann z.B. über den CAN-Bus mit dem Hauptprozessor kommunizieren. Ich würde das aber mit als Multiprozessing bezeichnen, sondern als Modularisierung. Es geht dabei ja überhaupt nicht um bessere Auslastung, sondern um sichere und einfachere Kommunikation (weniger Leitungen). Peter
.. wie will man das auch noch vernünftig realisieren? Mcu1 macht ne Berechnung .. Mcu2 macht auch eine und die 3. bekommt bzw holt sich beide Ergebnisse um die dann weiter zu verarbeiten .. Nun ja ich glaube mal es wäre zuviel Aufwand von nöten, als das man das nur mit einer Mcu bewerkstelligt.. Aber ich hab z.Bleistift vor mir irgendwann mal ein Mischpult (analoge Eingänge und digitale Ansteuerung) zu bauen und denke mir, dass ich da pro Kanal eine Mcu einsetze, die dann von einer Haupt-Mcu angesteuert wird und die damit ganz deutlich entlastet wird
@Vexti für Mischpult wäre es IDEAL! echte-zeit Fourier, filtern, und andere verschiedene DSP funktionen; ein MCU pro Kanal google mal "DSP multiprocessor mobile"
KLar wäre es das .. nur würde ich dann keinen Dsp nur für einen Kanal einsetzen und abgesehen davon wollte ich etwas einfaches bauen, mit ICs die man auch löten und vorallem verstehen kann ;-) l.g Vexti
>echte-zeit Fourier Und da haben wir sie wieder: Die Echtzeit! Echtzeit bedeutet nur, dass das Ergebnis (welches auch immer) innerhalb einer bestimmten Zeit vorliegt, und diese Zeit deterministisch, also vorhersagbar, ist. Wenn man eine FFT optisch ausgeben will, sollte das möglichst zeitnah passieren, weil die Anzeige sonst nicht zur "Musik" passt. Die Signalanalyse ist recht anstrengend für einen Controller, der Flieskommaberechnung in Software nachbilden muß. Die Anzeige ansich dagegen ist trivial... >echte-zeit Fourier, filtern, und andere >verschiedene DSP funktionen; ein MCU pro Kanal Kennst du DSPIC? Das sind Mikrcontroller (von Microchip) mit integrierter DSP. Die erschlagen sowas ganz alleine...
Wozu braucht man immer gleich unbedingt ne FFT?? normal reichen auch ein paar Algos, wie FIR/IIR Filter oder ein Dynamik Prozess aus
multi-MCU platform... good idea I wonder whether it is possible to achieve a computable power comparable with a normal PC, like 1Ghz x86 CPU? How many MCU you need and how complex is circuit structure?
Well, at 200$ per "normal" PC-Processor and $2 per MC you can theoretically use up to 100 MCUs to save money. But it makes no sense to do so, because you will never have a way to move data as fast between multiple MCUs as a single CPU can process it. And there's another big problem: Most MCUs can't get their program code from a RAM whithout programming it into their own program memory (flash). That costs time and is extremely inefficient. The complexity will come near to infinity ;) Tell me where it would be necessary to do something like this.
Hallo, Also aus reiner Spielerei kann man das mit dem Multi-AVR System machen. Es mag auch Situationen geben, wo solch ein Mikrocontroller-Verbund sinnvoll eingesetzt werden kann. Zum Beispiel, wenn diese fast unabhängig operieren und wenig Daten austauschen. Aber sonst würde ich dazu raten irgendwie die Aufgaben mit einem Prozessor anzugehen - nofalls mit einem leistungsfähigerem. Es gibt ja auch unter den Controllern recht Leistungsstarke Erscheinungen. Gruß Wolfgang Brushless Development Kit http://www.ibweinmann.de/html/brushless.html
I wonder if it's in great demand to use a massive of MCUs on a PCI board as an Application Specific Board (analogues with FPGA-PCI boards). A lot of applications can "unabhängig operieren und wenig Daten austauschen".
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.