ARM Mikrocontroller

[stegr]

Die 32-bit bringen dir rein gar keinen vorteil, wenn du keine 32-Bit-Operationen benötigst. Wenn du immer nur einzelne Bytes hin und her schaufelst, ist dein 8-biter genauso schnell wie dein 32-biter, aber sobald du mal zwei 16-Bit oder zwei 32-Bit-Zahlen addieren musst, sieht die Welt schon ganz anders aus.

Bei einem 32-Bit-System sind zwei Sachen relevant anders als bei einem 8-Bit-System:
1.) Die ALU ist (mind.) 32 Bit breit (ALU=Rechenwerk).
2.) Dein Instruktionsformat ist mind. 40 Bit oder noch breiter

Der erste Punkt bringt dir bei Rechenoperationen Geschwindigkeitsvorteile, der zweite Punkt lässt dich zum Beispiel größeren Speicher ansteuern (mehrere Gigabyte)...

Das ist nicht richtig. Wieso sollte das Instruktionsformat mind. 40bit sein?
Was Du meinst, ist das Addressformat. Operanden müssen aber nicht im jeweiligen Befehl stehen. Im Prinzip sind also durchaus 8bit-Instruktion denkbar.

Wenn kein einheitliches Instruktionsformat verwendet wird, ist Pipelining nicht mehr in dem Maße sinnvoll einsetzbar, da dabei structural hazards nur durch intensives stallen vermeidbar sind. Und dies senkt den cpi-Wert deutlich.

Zusätzlich hast du bei den meisten 32-Bittern Technologieänderungen, bedeutet, dass die
1.) von Haus aus schneller sind, da andere Prozessarchitektur
2.) meist Pipelinig haben (nachfolgende Befehle werden noch während der eine abgearbeitet wird aus dem Speicher geholt und vorverarbeitet)
3.) Viele Schnittstellen schon als Hardware-Modul, die du auf einem 8-Bitter in Software machen musst.

Das ist auch nicht richtig. Moderne 8bitter benutzen ebenfalls Pipelining, zum Beispiel die silabs-8051er. Die schaffen bis zu 100 Mips, womit sie insbesondere den kleinen ARMs leistungsmässig deutlich überlegen sind.
Von der Ausstattung können sie ebenfalls mithalten bzw. übertreffen viele 16- oder 32-bitter.

Ich hab mir grade mal das Datenblatt zu deinem super-8051 mit 100 MIPS angeschaut... das lustige Teil läuft mit externen 50MHz (intern-2x-PLL), und schafft nur bei einem Viertel der Befehle die auch in einem Systemzyklus auszuführen, rund die Hälfte braucht zwei Zyklen und der Rest bis zu 8 Zyklen - soviel zu den 100 MIPS. Da der 8051 kein einheitlich langes Instruktionsformat hat, geht weitere Rechenleistung durch stalls verloren, so dass der nette Controller überschlagsweise noch rund 30 MIPS real im Schnitt hat. Das ist schon deutlich weniger, oder?

Zum Thema AMD64: das ist vom System her nochmal ganz anders, weil das kein Mikrocontroller ist, sondern ein Mikroprozessor. Das bedeutet, dass kein Speicher und keine Peripherie enthalten sind - aber das ist ja grade die Sache, warum man einen ARM nehmen will...

Naja, auch nicht ganz richtig. Der AMD hat jede Menge Cache-Speicher und ausserdem auch den Speichercontroller sowie jede Menge andere Peripherie an Board (Timer, etc.).
Allerdings nutzt das Ding ohne Zusatzbeschaltung in der Tat nicht viel

Der AMD64 hat keinen Programmspeicher und ist somit kein Mikrocontroller. (<- Dies ist ein Punkt!)
Cache ist auch nicht als internen Speicher nutzbar, auch wenn es eine Speicherform ist, da dieser lediglich eine Zwischenspeicherung häufig benötigter Werte des RAMs darstellt. Dies lässt sich aber nicht direkt beeinflussen.

2.) Die ARM7TDMI haben sich eigentlich zum Marktführer in dem Bereich herausgebildet. Die sind dafür ausgelegt um die nächste Ebene über den 8-Bittern zu bilden - 16-Bitter lohnen sich fast nicht, da die nahezu gleichviel kosten wie die 32er, man aber zusätzliche Entwicklungskosten hat. Daher verwenden die meisten Firmen nur 8 oder 32-Bitter.

Das ist nicht ganz richtig. Der 16bit-Markt ist sehr aktiv und gerade aus Kostengründen sehr attraktiv. Schau mal bei den grössten Controller-Anbietern (Renesas und Motorola) nach, welche Vielfalt die anbieten.

Der 16-Bit-Markt ist auf dem absterbenden Ast. Die Kosten liegen in den meisten Fällen in der selben Größenordnung wie 32-Bit-Systeme, sind dafür aber nicht so leistungsfähig (bis auf wenige Ausnahmen). Motorola selbst empfiehlt für neue Designs auf 32-Bit-Systeme umzusteigen (und das war vor einem Jahr auf der Embedded-World) oder 8-Bit-Systeme zu verwenden.

Für den Privatbereich gibt es aber einen 16-Bitter, der recht interessant ist: Die MSP430 von TI, kosten ungefähr gleich viel wie die 8-Bitter, sind aber ein Stückle schneller und einfach zu programmieren. Einziger Nachteil: 44-Pin-TQFP-Gehäuse... aber bei Olimex (und anderen Anbietern) gibt es welche davon auf Header-Boards...

Das ist Geschmackssache. Fakt ist, dass die MSPs von TI für einen recht eingschränkten Anwendungsbereich entwickelt wurden und man das auch merkt. Leistungsmässig stehen sie noch unter den meisten 8bittern (nur 8Mhz) und haben auch kein externes Speicherinterface. Ein aktueller AVR (24MHz) oder 8051 (bis zu 100MHz) hängt die MSPs (erst seit November 2004 mit 16MHz, aber natürlich noch nicht erhältlich) also locker ab.

Ich hab nicht gesagt, dass die MSPs das absolute non-plus-ultra sind. Sie sind klar für minimale Leistungsaufnahme optimiert und daher natürlich nicht in allen Punkten 8-Bittern überlegen. Aber das hab ich ja auch nicht behauptet. Was bei den MSP430s sehr interessant ist, ist dass sie nen echten Hardware-Multiplizierer haben, was man bei den meisten 8-Bittern nicht findet (zumindest keinen echten single-cycle).
Externes Speicherinterface macht bei einem auf Batterieanwendung ausgelegten MikroCONTROLLER keinen Sinn - wöllte ich ein externes Speicherinterface würde, würde ich nen MicroPROZESSOR nehmen.

Was vielleicht auch interessant wird, sind die dsPICs von Microchip, die sind deutlich schneller, haben Hardware-Multiplizierer und schnelle AD-Wandler...
Nachteil: man bekommt se bisher kaum (selbst bei den Distris) und Preislich werden die auch nicht ganz so günstig sein.

Die benutzt leider kaum einer, man sollte sich also ein bisschen mit der Thematik auskennen.
Bekommen tut man sie (als Hobbyist) aber recht gut, Microchip schmeisst schliesslich recht grosszügig mit Samples um sich

Bei vielen Firmen sind die, zumindest in Prototypen, bereits im Einsatz, allerdings sind Kleinmengen nicht sinnvoll verfügbar (100er-Bereich). Samples bekommt man natürlich, allerdings will ich nicht für ne Kleinserie 17 Monate warten, bis ich die dann vollständig hab.
Für reine Hobby-Zwecke reichen natürlich die Samples, aber wir haben hier ja nicht nur Hobby-Leute...

So, noch mehr Fehler?

MfG
Stefan

Wenn kein einheitliches Instruktionsformat verwendet wird, ist Pipelining nicht mehr in dem Maße sinnvoll einsetzbar, da dabei structural hazards nur durch intensives stallen vermeidbar sind. Und dies senkt den cpi-Wert deutlich.

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.

Ich hab mir grade mal das Datenblatt zu deinem super-8051 mit 100 MIPS angeschaut... das lustige Teil läuft mit externen 50MHz (intern-2x-PLL), und schafft nur bei einem Viertel der Befehle die auch in einem Systemzyklus auszuführen, rund die Hälfte braucht zwei Zyklen und der Rest bis zu 8 Zyklen - soviel zu den 100 MIPS. Da der 8051 kein einheitlich langes Instruktionsformat hat, geht weitere Rechenleistung durch stalls verloren, so dass der nette Controller überschlagsweise noch rund 30 MIPS real im Schnitt hat. Das ist schon deutlich weniger, oder?

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.

Der 16-Bit-Markt ist auf dem absterbenden Ast. Die Kosten liegen in den meisten Fällen in der selben Größenordnung wie 32-Bit-Systeme, sind dafür aber nicht so leistungsfähig (bis auf wenige Ausnahmen). Motorola selbst empfiehlt für neue Designs auf 32-Bit-Systeme umzusteigen (und das war vor einem Jahr auf der Embedded-World) oder 8-Bit-Systeme zu verwenden.

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.

Ich hab nicht gesagt, dass die MSPs das absolute non-plus-ultra sind. Sie sind klar für minimale Leistungsaufnahme optimiert und daher natürlich nicht in allen Punkten 8-Bittern überlegen. Aber das hab ich ja auch nicht behauptet. Was bei den MSP430s sehr interessant ist, ist dass sie nen echten Hardware-Multiplizierer haben, was man bei den meisten 8-Bittern nicht findet (zumindest keinen echten single-cycle).

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.

Externes Speicherinterface macht bei einem auf Batterieanwendung ausgelegten MikroCONTROLLER keinen Sinn - wöllte ich ein externes Speicherinterface würde, würde ich nen MicroPROZESSOR nehmen.

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.

So, noch mehr Fehler?

Hey, nicht gleich beleidigt sein.
Noch Fragen?

[bhm]

öhm, ja, welches ist denn nun der beste µC ? (Öl-auf's-Feuer-gieß ...)
nee, ernsthaft, welcher µC wäre wohl geeignet um zB das Bild einer Webcam in Echtzeit zu verarbeiten (zB Kanten finden) ? Er braucht ja wohl zum einen etwas Rechnenpower und zum andern auch reichlich Speicher.
ciao .. bernd

[stegr]

Wenn kein einheitliches Instruktionsformat verwendet wird, ist Pipelining nicht mehr in dem Maße sinnvoll einsetzbar, da dabei structural hazards nur durch intensives stallen vermeidbar sind. Und dies senkt den cpi-Wert deutlich.

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.

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

Ich hab mir grade mal das Datenblatt zu deinem super-8051 mit 100 MIPS angeschaut... das lustige Teil läuft mit externen 50MHz (intern-2x-PLL), und schafft nur bei einem Viertel der Befehle die auch in einem Systemzyklus auszuführen, rund die Hälfte braucht zwei Zyklen und der Rest bis zu 8 Zyklen - soviel zu den 100 MIPS. Da der 8051 kein einheitlich langes Instruktionsformat hat, geht weitere Rechenleistung durch stalls verloren, so dass der nette Controller überschlagsweise noch rund 30 MIPS real im Schnitt hat. Das ist schon deutlich weniger, oder?

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.

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.

Der 16-Bit-Markt ist auf dem absterbenden Ast. Die Kosten liegen in den meisten Fällen in der selben Größenordnung wie 32-Bit-Systeme, sind dafür aber nicht so leistungsfähig (bis auf wenige Ausnahmen). Motorola selbst empfiehlt für neue Designs auf 32-Bit-Systeme umzusteigen (und das war vor einem Jahr auf der Embedded-World) oder 8-Bit-Systeme zu verwenden.

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.

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.

Ich hab nicht gesagt, dass die MSPs das absolute non-plus-ultra sind. Sie sind klar für minimale Leistungsaufnahme optimiert und daher natürlich nicht in allen Punkten 8-Bittern überlegen. Aber das hab ich ja auch nicht behauptet. Was bei den MSP430s sehr interessant ist, ist dass sie nen echten Hardware-Multiplizierer haben, was man bei den meisten 8-Bittern nicht findet (zumindest keinen echten single-cycle).

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.

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.

Externes Speicherinterface macht bei einem auf Batterieanwendung ausgelegten MikroCONTROLLER keinen Sinn - wöllte ich ein externes Speicherinterface, würde ich nen MikroPROZESSOR nehmen.

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.

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

So, noch mehr Fehler?

Hey, nicht gleich beleidigt sein.
Noch Fragen?

Bin nicht beleidigt... aber ich mag keine Fehler, die offen stehen bleiben... darum frag ich ja auch, bin auch nicht allwissend...

MfG
Stefan

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!

[John13]

öhm, ja, welches ist denn nun der beste µC ? (Öl-auf's-Feuer-gieß ...)
nee, ernsthaft, welcher µC wäre wohl geeignet um zB das Bild einer Webcam in Echtzeit zu verarbeiten (zB Kanten finden) ? Er braucht ja wohl zum einen etwas Rechnenpower und zum andern auch reichlich Speicher.
ciao .. bernd

Dafür würde ich einen DSP nehmen.
Wenn Du das als Hobby machen willst, dann bestell Dir bei Analog Devices kostenlos 2 Samples des 21065ers. Die kann man auch mit wenig Aufwand (da Hardware-unterstützt) parallelschalten und haben auch den DRAM-Controller eingebaut. Einfach alte PC-SIMMs anschliessen und los gehts.
Nur ne 4Layer-Platine wäre halt sinnvoll.

[bhm]

Dafür würde ich einen DSP nehmen.
Wenn Du das als Hobby machen willst, dann bestell Dir bei Analog Devices kostenlos 2 Samples des 21065ers. Die kann man auch mit wenig Aufwand (da Hardware-unterstützt) parallelschalten und haben auch den DRAM-Controller eingebaut. Einfach alte PC-SIMMs anschliessen und los gehts.
Nur ne 4Layer-Platine wäre halt sinnvoll.

Ist 'ne nette Idee, nur das mit den 2-Layer-Platinen wird wohl ein Problem, da Hobby. Ich wollte mir eh mal DSPs ansehen, schon allein wegen der ganz anderen Philosophie.
ciao .. bernd

[Kjion]

Hi,

mittlerweile hab ich auch schon ne Antwort von Axotec.de bekommen, leider sind die Preise wie ich das schon erwartet hatte recht hoch.
Zum Beispiel das µX-PRO Board kostet 438 € in der Grundausstattung, für die zusammengestellten Linux System wollen sie nochmal 350 € ( bzw. 2000 € für die Developer Edition ) haben. Das ist mir dann doch etwas viel ...

Diese Boards gehen leider alle in diese Preisklasse, allerdings bekommt man für diesen Preis schon ein VIA Epia Board mit Netzteil und allem Zubehör. Wenn da nicht der Stromverbrauch und der benötigte Platz wäre eigentlich Ideal

MfG Kjion

[engineer]

Das ist in der Tat sehr hoch. Ich habe mich mal eine Weile mit solchen embedded Webservern befasst- ebenfalls auf der BAsis von ARM. Wie man den Bildern entnimmt, sind die Viecher recht komplex:

http://home.arcor.de/devicemaster/images.html

Dieser läuft auf ECOS, mit einem free SDK. Kosten für des Teil (16 Kanäle) €1450,- im Jahre 2002.

Was Eigenentwicklungen angeht, würde ich zu einem der olimexboards raten. Hier gibt es eines für 69,- www.shop.mikrocontroller.net "olimex board LPC2101"

Das habe ich auch bestellt. Dazu habe ich mir eines in Eagle gebaut - mit den jeweils benötigten Sonderfunktionen.

[muraad]

Schade das sie echt so teuer sind, vor allem die Developer Edition . Ich fand die Boards auch so interresant da sie ideal für nen Roboter währen.
Aber gibt es jetzt echt keine ARM Boards, außer das olimexboard, welche für privat/hobby erschwinglich sind?!
Gruß Muraad