ARM Mikrocontroller

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.

In meiner Vorlesung war das aber etwas anders
Wenn nämlich (aus Kostengründen) einzelne Funktionseinheiten, beispielsweise Speicherbusse, eingespart werden, dann tritt Dein Fall in Kraft. Das ist dann aber bewusst so hingenommen.
Gerade bei den DSPs aber ist es halt so, dass es mehrere Busse gibt, so dass diese halt nicht den Flaschenhals bilden und somit structural hazards im Wesentlichen durch diese bewussten Einsparungen bedingt sind.

Hab ich jemals behauptet, dass die ARM7TDMI, speziell die LPCs besonders stark leistungsfähig sind im Vergleich zu deinem Controller?
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.

Ich meinte damit auch nur, dass speziell die LPCs meiner Meinung nach nur den 32bit-Hype ausnutzen, in vielen Fällen aber nichtmal 8bit Niveau erreichen (speziell I/O).

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.

Das hat man schon vor über 15 Jahren zu den 8bittern gesagt. Bis heute wird aber noch prima damit verdient (sogar 4bitter gibt es etliche!).
Fakt ist, dass Chipfläche viel Geld kostet. Und ein 32bit-Bus samt 32bit-Speicher (Cache, onboard-RAM/ROM/FLASH) frisst viel Fläche. Das macht Controller teuer. Dazu kommt die grössere Code-Grösse, die grössere Speicher erforderlich macht.
Sogar bei den Arms gibt es dazu ja die Thumb-Erweiterung, die eine Reduktion auf 16bit ermöglicht, damit eben Ressourcen eingespart werden können.

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.

Wobei gerade Deine Argumente eher für den AVR sprechen (bis auf die Stromaufnahme, die allerdings nur für wirkliche "Nur-MCU-Anwendungen" interessant ist)- er ist günstiger erhältlich, da selbst Hobbyisten sie in ihren Webshops führen, es gibt wesentlich mehr Projekte damit, die Einsteigern behilflich sind und dazu 2 exzellente Foren (deutsch und englisch), die sehr rege und von vielen Fachleuten besucht werden.

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.

Hehe, ich habe mit dem 8048er angefangen und dann mit nem selbstgelöteten Eprom-Emulator auf dem 8051er weitergemacht. Das war auch nicht sehr teuer. Den PIC16C84 habe ich dann probiert und mich dann mit Grausen abgewandt (man denke nur an den begrenzten Hardwarestack, das umständliche W-Register, die umständlichen Interrupts, etc.). Gegenwärtig nutze ich privat die Renesas M16C sowie für kleiner Sachen die AVRs.

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

Dass der 8051 so lange gehalten hat, liegt ganz einfach daran, dass er eben gerade eine Architektur hat, die trotz ihrer Schwächen gerade im embedded-Bereich mit den vielen Port-Ein- und Ausgaben den AVRs und ARM überlegen ist. Das braucht nicht mehrere Befehle/Zyklen. Da kann man dann oft den Controller eine Nummer kleiner (und billiger) wählen als bei der Konkurrenz. Des weiteren gibt es den wohl weltbekannten Keil-C-Compiler, der für den 8051 einfach eine Klasse für sich ist und in der Effizienz von keinem Compiler geschlagen wird.

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

Das trifft aber nur Hobbyisten und kleine Ingenieurbüros. Bei Massenanwendungen fällt das schlicht nicht ins Gewicht.
Deshalb sind die 16bitter auch billiger als die 32bitter. Jeder Cent bei der MCU zählt da.

Im Übrigen gibt es die M16C-MCUs (jeweils 4 Stück) samt Development-Kits gerade bei Renesas für lau - vom "kleinen" R8C/13 bis hin zum "fetten" M32C/83 samt eingebautem DRAM-Controller

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

Trifft für Hobbyisten zu, im Massenbereich ist das wieder anders, wobei die ARMs da ordentlich zulegen.


So, und jetzt feiert mal schön!