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...
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".
