Hallo allerseits, mal eine grundsätzliche Frage: Ist ein Mikrocontrollersystem bestehend aus mehreren kleinen Mikrocontrollern in Form eines "Multiple-Core-Prinzips" leistungsfähiger, als ein System mit nur einem Controller, der dafür dann aber etwas größer ausfällt? Beispielsweise könnte man ja in einem Roboter einzelne Sensoren und Aktoren für z.B. eine Gleichgewichtslage von jeweils einem Controller auswerten und regeln lassen und die Daten dann zu einem kleinen zentralen Chip schicken, der nurnoch verwaltend mehrere kleine Subprozesse überwacht. Fraglich ist aber, ob damit wirklich etwas gewonnen wird, oder ob es nicht sinnvoller wäre, statt mehrerer kleiner Controller einfach den zentralen Controller eine Nummer größer und schneller zu wählen, so dass dieser alle peripheren Aufgaben einfach direkt selbst übernimmt. Der Routing-, Timing- und Softwareaufwand ist bei einem Multicoresystem schließlich ungleich höher, als wie bei einem Singlecore-System... ...Und im Gegensatz zu der GHz-Computerbranche gibt es im Mikrocontrollermarkt ja stets einen größeren und leistungsfähigeren Chip. mfg
Großes Fragezeichen schrieb: > Ist ein Mikrocontrollersystem bestehend aus mehreren kleinen > Mikrocontrollern in Form eines "Multiple-Core-Prinzips" > leistungsfähiger, als ein System mit nur einem Controller, der dafür > dann aber etwas größer ausfällt? Möglich. Ich habe hier so ein Ringnetzsystem zum Experimentieren herum liegen, wobei man zwei oder mehrere Boards miteinander verbinden kann. Schon 15 Jahre alt. Es sind bei mir 3 gleiche Boards, die alle einen SAB80C517A haben, ein leistungsfähigeres 8051-Derivat, und natürlich mit LWL-Schnittstelle. LWL am UART ist einfach nur Klasse. Der schnöde UART macht dann die Maximaldatenrate 1 Megabaud bei 12MHz-Quarz, wenn man will. Auf einem Board der Ringkette, am Master, muß man dann den Jumper ziehen, damit der Ring dort unterbrochen wird. Angenommen, man hätte auf einem der Boards nur den Standard-8051, und auf einem anderen den SAB80C517A, der ein schnelles Rechengenie für Floating-Point-Arithmetik ist, weil er eine MDU-Unit hat. Dann könnte man rechenintensive Sachen an den Coprozessor übergeben, und das Ergebnis wieder abholen. Konkret bin ich aber noch nicht dazu gekommen, weil ich die Libraries erst mal mit der MDU aufmöbeln muß, was etwas arbeitsintensiv ist. Z.B. Standard-Libraries des SDCC-Compilers mit der MDU manipulieren. Mit den Multiple Datapointern im SAB80C517A konnte ich schon mal was machen, und zwar schnelles FiFo-Management für die serielle Schnittstelle in Assembler. Dort müßte ich z.B. die Funktion memcpy() im SDCC eben so nacharbeiten, sie wird damit erheblich schneller. Also, ich habe mit den ollen Kamellen noch viel Bastelstoff.
Es geht oft darum ob der Controller überhaupt schnell genug an allen Pins wackeln kann bzw. auf Interrupts reagieren kann oder ob schon zuviel Kram läuft der den Kern blockiert. Oder ob überhaupt genug ADCs oder Pins verfügbar sind oder ob die nicht physikalisch einfach zu weit vom Sensor weg sind (Störungen). 10 über den Roboter verteilte Ultraschallsensoren (ohne eigenen Controller) möchte man nicht wirklich mit einem einzelnen Controller auswerten würde ich sagen.
@Wilhelm, ist das dann nur Zeitvertreib, oder setzt du diese ganzen Entwicklungen auch in Projekten ein? Falls ja, wo verwendest du das?
Tim schrieb: > @Wilhelm, ist das dann nur Zeitvertreib, oder setzt du diese ganzen > Entwicklungen auch in Projekten ein? Falls ja, wo verwendest du das? Na ja, die Industrie wollte mich nicht mehr, wahrscheinlich zu alt (Ü50). Meine Bewerbungsanzahl locker über 300. Für ein Butterbrot gehe ich aber als Entwickler auch nicht mehr überall hin, besonders nicht zu bundesweiten Zeitarbeitsreisen. Aber das ist ein anderes Thema. Sonst mache ich hier, was mir gerade Spaß macht. Tools-Setup, das ist mit dem Freeware SDCC, der keineswegs ready to use ist, und wo es keine Beispiele gibt, durchaus schon mal intensiver. Oder wie kürzlich, den alten 8051-Simulator von 1991, wo ich hier im Forum echt gute Hinweise z.B. DOSbox bekam, was dann funktionierte. Ich hab viele Ideen, wollte den mechanischen Programmschalter der 25 Jahre alten Waschmaschine schon mal gegen so ein Board austauschen. Vollständig eigenes Waschprogramm dann. Wenn ich das will, kann ich das auch. Keine Frage. Es ist aber nicht eilig. Mir gefällt das mechanische feste Waschprogramm nicht. Die Laugenpumpe zum Abpumpen läuft beispielsweise 10 mal länger, als nötig. Aus langjährigen Beobachtungen. Im Augenblick entwickele ich ein Spaßprogramm für jemand interessiertes, wo z.B. ein Millisekunden exakter Reaktionstester drauf kommt, und ein paar Würfelspiele, und Lottozahlengenerator. Dafür befasse ich mich gerade mit Mathematik, Statistik, das kam im E-Technik-Studium etwas zu kurz. Der Reaktionstester hat Menschen fasziniert, denen ich es mal kurz zeigte, und in den Bann gezogen. Man glaubt es kaum, aber es ist so. Das muß mit 8051-Assembler alles in 2KB Speicher hinein. Na ja, ich entwickele mich selbst noch. Und fühle mich in der Technik fit. In der letzten Firma machte ich zuletzt einen vollständigen CAN-Bus-Treiber für einen Kunden. Ööhhh, das geht wahrscheinlich noch, wenn ich 80 werde. Industrieprojekte, da hab ich auch keinen Bammel vor. Immerhin war ich über 20 Jahre berufstätig, davon über 3 Jahre als Entwickler.
>..oder ob es nicht sinnvoller wäre, statt mehrerer kleiner >Controller einfach den zentralen Controller eine Nummer größer und >schneller zu wählen.. Der Controller "eine Nummer größer" müsste dazu aber auch entspr. schnellere INT-Zeiten aufweisen, was meistens wohl nicht der Fall ist.
MCUA schrieb: > Der Controller "eine Nummer größer" müsste dazu aber auch entspr. > schnellere INT-Zeiten aufweisen, was meistens wohl nicht der Fall ist. Na ja, das muß der Anwendung eben entsprechen. Ich sehe da grundsätzlich kein KO.
Ich würde auch sagen das man, für den Anfang hält mehrere Controller nimmt. Wobei das auch immer auf die Anwendung drauf ankommt. Ingo
Das ist so ähnlich wie der Vergleich Boot vs Dampfer. Ein Dampfer kann in der gleichen Zeit definitv mehr transportieren. Aber ist er deshalb schneller?
MCUA schrieb: > Das ist so ähnlich wie der Vergleich Boot vs Dampfer. > Ein Dampfer kann in der gleichen Zeit definitv mehr transportieren. Genau das ist es doch, wenn in meinem beschriebenen Ringnetz der Master ein einfacher 8051 ist, und die Slaves SAB80517A. Das können natürlich auch ganz andere sein, die nichts mit 8051 zu tun haben. Vielleicht ein PIC oder ARM? Da übergibt der Master was an die komplexeren Slaves, was er nicht kann, und erhält das Ergebnis zurück.
Mehrere Mikrocontroller zu vernetzen kann durchaus Sinn ergeben. Ein Lego Mindstorms Roboter besteht typischerweise aus 3 Mikrocontrollern, die via I2C kommunizieren: - einer im Ultraschall-Sensor - einer für die Motor-Steuerung (PWM) - einer für das Hauptprogramm Es kann einfacher Sein, Teilfunktionen auf separate Mikrocontroller zu verteilen, als alles in einem Zusammen zu bringen. Vor allem, wenn die einzelnen Teilfunktionen unabhängig voneinander entwickelt werden.
Großes Fragezeichen schrieb: > Ist ein Mikrocontrollersystem bestehend aus mehreren kleinen > Mikrocontrollern in Form eines "Multiple-Core-Prinzips" > leistungsfähiger, als ein System mit nur einem Controller, der dafür > dann aber etwas größer ausfällt? Das Aufspalten auf mehrere Controller ist vor allem dann sinnvoll, * wenn diese räumlich getrennt sind (was dann Verkabelungsaufwand spart) * wenn Prozesse aus Sicherheitsgründen getrennt werden müssen (z.B. Medizintechnik) * wenn Redundanz gefordert wird (z.B. Luftfahrt) Wenn es um Rechenleistung geht, ist der Wechsel auf eine andere, besser geeignete Architektur sinnvoller, weil so ggf. eine Leistungssteigerung im mehrere Zehnerpotenzen erzielt werden kann. Einige Aufgaben können auch besonders effizient in FPGAs realisiert werden, wo ja alle Logikelemente zeitgleich parallel arbeiten. Ich habe hier in diesem Forum schon etliche Projekte gesehen, bei denen nur deswegen mehrere Controller zum Einsatz kamen, weil die Kenntnisse der Erbauer begrenzt waren. fchk
Oft ist es auch eine Frage was man kennt, wenn man (als Firma) seit Jahren auf AVRs setzt und dann für ein einzelnes Projekt nen ARM nehmen würde wäre der Aufwand für die Einarbeitung größer als der für das Multicore-system... Desweiteren hat ein Multi-controller-System bei richtigem Design gleich ein Stück Sicherheit dazu (Redundanz), so kann z.B. bei Ausfall des Haupt-controllers (z.B. in einem Quadrocopter) eine Kommunikation direkt zwischen den Sensoren zu einer Art "Notbetrieb" genutzt werden um das System crashfrei zu landen.... Oder in einem Auto der Abstandwarner direkt die Bremse anfunken....
Beispiele für existierende Single-Chip Multicore-Microcontroller: - Parallax Propeller: 8 32-Bit 20MIPS Cores auf einem Chip, SMD und sogar DIP. Etwas eigenwillige Programmiertechnik. Wirkt eher als Bastlerchip. - XMOS: 8 Hardware-Threads pro 32-Bit 400MHz Core, 1 Core als xQFP-Chip, 4 Cores als BGA-Chip. Spezielle serielle Kommunikationskanäle ermöglichen eine effiziente und schnelle Verbindung mehrerer Chips. Beiden Systemen ist eigen, dass die in klassischen µCs üblichen Interrupts durch Thread-Programmierung ersetzt werden. Es sind kaum I/O-Module wie serielle Schnittstellen fest verbaut, statt dessen werden solche Funktionen bis hin zum Ethernet-MAC (XMOS) per Software realisiert. Dazu und deshalb sind diese Cores/Threads in der Lage, extremen bis taktgenauen Echtzeitbedingungen zu genügen. Führt zu weit grösserer Flexibilität gegenüber fest eingebauten I/O-Modulen und ragt etwas in jenen Anwendungsbereich hinein, der sonst nur mit FPGAs realisierbar ist.
Oh Mann, A. K., du bist ja schneller, als die Polizei erlaubt. Wobei ich das am schnöden 8051 anschaulich machen wollte. ;-) An der FH in Datenverarbeitung hatten wir 1995 Übungen in FORTRAN. Mit dem FORTRAN77-Compiler. Der Stand der Technik war zu dieser Zeit ein 80486DX2. Keine Ahnung, woher mein FORTRAN-Compiler stammt, irgend einer der Jungs Studenten zog den irgendwo. Bei mir zu Hause lief alles proper. Die Kumpels hatten schon mal vom Bruder geerbte 80386 ohne Coprozessor 80387. Ich versuchte, meine Entwicklungsumgebung für die Übungen da bei denen zu Hause zu installieren. Da begann der Mist. Der Fortran-Compiler suchte den 80387 Coprozessor, findet ihn nicht, und macht eine Meldung, oder auch gar nichts. Compiliert jedenfalls nicht. Irgendwo gab es einen Switch, daß der Fortran-Compiler den 80387 in Software emuliert, aber den fand ich viiiiieeeeellll später, als alles vorbei war. Ich installierte den Jungs auf den Rechnern dann den FORTRAN-Compiler von DIGITAL-RESEARCH, den wir irgendwo fanden, der machte es problemlos ohne Coprozessor.
prominentes Beispiel für Multicore ... das Auto. Für jeden Furz gibts n eigenes Steuergerät, das am gemeinsamen Bus hängt. Macht also schon Sinn bestimmte Aufgaben an Coprozessoren abzugeben, die dann eigenständig agieren. Was den Propeller angeht, hab mit dem Teil vor Jahren mal herumgespielt, ist schon ne interessante Platform, wenn man aber alle Peripherie wie SPI UART etc. per Cog nachstellen muss relativiert sich die Kernanzahl auch schnell wieder. Allerdings ist man dafür schön frei in seinem Leiterplattenrouting :)
Hallo "Großes Fragezeichen" also wenn DU sozusagen im Ruhestand bist und noch was lernen willst würde ich wirklich mal einen Blick in den Parallax Propeller emmpfehlen. Ganz anderes Paradigma. 8-Kerne, aber keine Interrupts. Ich bedaure, dass ich mich vom Bastlerimmage habe abschrecken lassen und erst kürzlich die Mühe - die dann Spass war - gemacht habe, mir selber eine fundierte Meinung zu bilden. Ist als DIP40 ganz einfach auf Breadboard aufzubauen und mit der SW ViewPort (30 Tage frei) hast Du sofort einen super einblick in alles. Und falls es dann packt - gibt es demnächst den Propeller II der viel besser wird. Mit super Analog-Funktionen.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.