Hab grade extra nochmal nachgelesen, weil bei mir die Vorlesung auch noch nicht so lange her ist: Wenn das Instruktionsformat uneinheitlich ist, würden durch die quasiparallele Abarbeitung einige Befehle auf die selbe Ressource zugreifen, was aber nicht möglich ist. Daher muss in diesem Fall ge-stall-t werden. Structural hazards sind nicht nur bei uneinheitlichem Instruktionsformat auftretend, aber hier jedoch in hohem Maße.Zitat von Anonymous
Wir sind hier in einem allgemeinem Forum. Mich beeindruckst Du jedenfalls nicht durch schlechtes Deutsch mit ein paar Fachbegriffen.
Im Übrigen ist meine Vorlesung "Rechnerarchitekturen", speziell das Kapitel "Pipelines und superskalare Architkekturen" noch gar nicht so lange her
Daher weiss ich auch, dass structural hazards zwar durch stallen begegnet wird, das aber nicht am Instruktionsformat liegt.
Und sorry, ein kleiner Fehler von mir, der dir gar nicht aufgefallen ist, sondern erst mir beim wiederholten durchlesen: Der CPI-Wert wird natürlich erhöht, nicht gesenkt, aber das ist ja eigentlich klar.
Hab ich jemals behauptet, dass die ARM7TDMI, speziell die LPCs besonders stark leistungsfähig sind im Vergleich zu deinem Controller?Du hast wohl vergessen, zu erwähnen, dass das beim ARM genauso ist!
Speziell bei den LPCs ist es so, dass der Flash über 20MHz nicht mehr mitkommt und jedesmal 2 Wartezyklen einlegen muss, sobald etwas nicht mehr im Cache steht. Das bedeutet, dass man bei 60MHz im Schnitt nur etwa die doppelte Geschwindigkeit erreicht wie bei 20MHz.
Viele Befehle dauern auch 2 Zyklen.
Ein simples Pin setzen in kostet 3 Befehle also insgesamt 6 Zyklen, das geht beim 8051er viel besser.
Ich hab mal testweise mit einem Timerinterrupt nur eine Variable hochgezählt, sonst nichts. Da konnte ich die Interruptfrequenz auf maximal 60 Zyklen setzen oder es gehen Interrupts verloren.
D.h. nur Interrupt betreten, Interruptflag löschen, Wert hochzählen und Interrupt verlassen kostet allein schon mal etwa 50 Zyklen -> Übel!
Was die LPCs angeht, so sind die allenfalls sinnvoll, wenn viel mit 32bit gerechnet wird. Ansonsten schneiden die schlecht ab.
Ich hab nur gesagt, dass man nicht Äpfel mit Birnen vergleichen kann. Natürlich ist an jedem Controller irgendwo ein Pferdefuss zu finden, aber wenn man einen Controller für eine spezielle Aufgabe sucht, dann wählt man genau den aus, den man braucht. So käme wohl auch keiner auf die Idee nen MSP430F4xx (also aus der Displayreihe) für ne Motorsteuerung zu verwenden, da der einfach nicht dafür ausgelegt ist.
Klar, viele Kunden, die bisher 16-Bitter im Einsatz haben wollen ja wohl auch nicht alle bereits geschriebene Software neu schreiben. Und grade für den Motorola nach Renesas-Wandel stellt IAR schöne Cross-Compiler zur Verfügung. Was ich damit sagen wollte ist nur, dass in Zukunft mehr Leute 32-Bitter verwenden werden als 16-Bitter und auf Dauer (die nächsten 5-10 Jahre) werden die für die Massenproduktion aussteigen. Das sind aber Fristen, die in dem Bereich normal sind. Und am Ende wird es trotzdem immer noch mindestens einen Anbieter geben, der die weiterhin im Programm hat, auch wenn se dann nur noch ein Nieschen-Dasein leben.Klar, dass die das empfehlen. Die haben ja ordentlich Miese gemacht und an Marktanteil sowie Gewinn verloren. Nicht umsonst ist die Sparte jetzt ausgegliedert und heisst Freescale. Des weiteren war 16bit schon immer Motorolas Schwäche. Ausser der 12er und der 16er Reihe hatten die nichts zu bieten.
Der Marktführer Renesas jedenfalls baut seine 16bit-Reihe massiv aus und gewinnt gerade deswegen auch enorm an Marktanteilen.
Nein, eine Allzweck-MCU ist er sicher nicht, aber für viele Aufgaben, grade wenn es auf Leistungsaufnahme ankommt, gut geeignet. Er ist aber gut erhältlich, die Entwicklungswerkzeuge sind sehr günstig und man bekommt in D recht guten Support für, auch Hobby'ler. Und das sind für mich die hier interessanten Argumente. Wobei er natürlich in vielen Gebieten sogar einem normalen AVR unterlegen ist, aber das ist, wie oben schon erwähnt, vom Einsatzzweck abhängig.Was nutzt der Hardware-Multiplizierer, wenn die schnellere MCU das in Software genauso fix macht?
Aber ich wollte den MSP430 nicht schlecht machen. Als Allzweck-MCU ist er aber sicherlich nicht geeignet.
Im Übrigen hat die genannte silabs-100Mips-8051er-Familie eine Reihe MCUs mit 2-Zyklus-MAC-Einheit. Das ist schon wesentlich interessanter als ein Hardware-Multiplizier.
Hab ich gesagt, dass es keiner benötigt? Nein. Manchmal brauch ich auch ein externes Speicherinterface, weil ich einfach zu viele Daten für den internen Speicher habe.Das ist ja Unsinn. Viele Geräte benötigen die Eigenschaften eines Controllers samt externem Speicher.
Wieso sollte auch sonst in so viele Controller ein externes Speicherinterface implementiert sein, wenn es denn keiner benötigen würde?
Stromsparende Speicher gibt es auch viele.
In den meisten Fällen, die hier auftreten, braucht man jedoch kein externes Speicherinterface, sondern einen schönen kompakten Controller, der alles drinnen hat, bei dem ich mir keine Gedanken um irgendwelche Speichertimings machen muss, sondern der einfach so läuft, wie ich es will. Natürlich sieht die Geschichte je nach Anwendungsgebiet anders aus: Wenn ich, wie z.B. bhm, Bildverarbeitung machen möchte, dann brauch ich in erster Linie viel Speicher, und das wird kaum ein Controller zu einem sinnvollem Preis integriert haben. Also wird man etwas externen SRAM oder, je nach Controller, auch DRAM dran hängen. Wenn man auf die ARMs gehen würde, wären das beispielsweise die ARM720-CPUs. Die haben sogar meist etwas internen Speicher, aber auch ein externes Speicherinterface. Man muss jedoch immer unterscheiden, was man braucht - es gibt keinen absolut universellen, für alles passenden Controller, sondern für jeden Anwendungsfall einen am besten dafür geeigneten. Da man meist nicht die Zeit hat sich in zig verschiedene Controller einzuarbeiten wird man eher hingehen und schaun, welche für die einem interessierenden Haupteinsatzgebiete am besten geeigneten Controller erhältlich sind und auf den 2-3 Controllern versuchen möglichst alle Anwendungen zu implementieren.
Ich selber bin überzeugter PIC-Programmierer, obwohl ich weiss, dass die AVRs zu einem ähnlichen Preis deutlich leistungsfähiger sind. Dies ist bei mir aus zwei Gründen so:
1.) Ich hab mit 8051 angefangen, bin dann aber recht schnell auf nen anderen Controller umgestiegen, da damals die Entwicklungsumgebungen nicht bezahlbar waren. Die PICs haben sich damals angeboten und daher hab ich se mal ausprobiert.
2.) Hab ich recht viele Firmenkontakte in dem Bereich und die meisten verwenden für kritische Anwendungen PICs, weil diese einfach extrem viel robuster sind als die AVRs. Das hab ich schon oft erlebt und es gibt viele Sachen, die man mit AVRs einfach nicht sauber machen kann (wie beispielsweise das direkte Betreiben an 220V und die Gleichrichtung über die internen Schutzdioden).
Mittlerweile zieht Atmel nach, was die Robustheit angeht, und Microchip zieht bei der Leistung nach. Da ich mich mit den PICs recht gut auskenne, werde ich wohl auch bei denen bleiben.
Nun gibt es aber auch bei mir einen Bereich, für den die PICs zu schwach sind, nämlich eine sinnvolle Ansteuerung von graphischen Displays. Natürlich könnte man das auch auf PICs realisieren (hab ich teilweise schon gemacht) aber es macht nicht mehr wirklich Spass. Als gut geeignet scheinen die ARM7TDMI, ob se im Praxiseinsatz wirklich für diesen Zweck geeignet sind, muss ich noch herausfinden. Für ARM7 hab ich schon in Assembler und C programmiert, kenn daher die Architektur und muss mich auch nicht mehr vollständig einarbeiten. Auch wenn se mir in manchen Bereichen nicht gefällt, scheint der ARM7 mir doch als guter Kompromiss. Sollte der interne Speicher nicht reichen, kann ich ohne große Änderungen zu einem ARM720 gehen, welcher ein externes Speicherinterface hat und daran einige Megabyte SD-RAM anschließen. Von welchem Hersteller ich jetzt aber einen Controller mit ARM-Kern nehmen werde, das weiss ich jetzt noch nicht. Da warte ich einfach die Embedded ab und unterhalte mich mal mit den verschiedenen Herstellern. Bei Controllern mit ARM-Kern gibt es für fast jedes Einsatzgebiet spezielle Abwandlungen von, die genau für diesen Zweck ausgelegt sind, und man muss sich nicht so sehr einarbeiten.
Bei den komplexeren Motorsteuerungen, zum Beispiel, würde ich jedoch keinen ARM (obwohl es dafür spezielle gibt) nehmen, sondern eher einen dsPIC, aber das sind persönliche Vorlieben und jeder muss selber schaun, was für ein Controller im am besten schmeckt. Es gibt keinen für alle Anwendungen am besten geeigneten Controller.
Meine persönlichen Empfehlungen:
- Im 8-Bit-Bereich empfehlen sich die PICs oder AVRs (genaueres siehe oben); Die 8051 mag ich aufgrund der Architektur nicht so wirklich. Es sind jedoch die Controller, die sich seit Jahrzehnten auf dem Markt gehalten haben (wobei das aber bei vielen Firmen daran liegt, dass se keine funktionierende Software neu schreiben wollen, wozu auch).
- Im 16-Bit-Bereich ist der Marktführer Renesas, aber deren Entwicklungsumgebungen sind unheimlich teuer, so dass das für die meisten nicht finanzierbar ist - und ich bekomm für nahezu den gleichen Preis nen 32-Bit-System, das sonst nahezu nichts kostet.
- Im 32-Bit-Bereich empfehle ich die ARM7, weil man dafür so ziemlich alles frei bekommt und auch die Controller zu vernünftigen Preisen in Kleinmengen und Großmengen erhältlich sind. Welche Controller im Details von welchem Hersteller, das muss man selber sehen und das hängt auch von den persönlichen Wünschen bezüglich der Ausstattung und den Einsatzgebieten ab.
Bin nicht beleidigt... aber ich mag keine Fehler, die offen stehen bleiben... darum frag ich ja auch, bin auch nicht allwissend...Hey, nicht gleich beleidigt sein.
Noch Fragen?
MfG
Stefan
Zitieren
Lesezeichen