Man werfe einen Blick ins Datenblatt und stelle fest, daß dieser Baustein (wie viele der heute noch hergestellten 8051-Derivate) besondere Peripherie beinhaltet, namentlich schnelle AD- und DA-Wandler.
Der auch heute noch gültige Vorteil der 8051-Serie ist der sehr kleine und einfach aufgebaute CPU-Kern, welcher sich entsprechend schnell in Speziallösungen integrieren lässt. Keine andere Controllerfamilie bietet eine derart grosse Peripherievielfalt und wird von derart vielen Herstellern gebaut.
Oder was auch immer. Peripherie jenseits von PIO, SIO und Timer dann meist extern.
wieso sollte man? Die Komplexität eines Algorithmus mag Rechenleistung erfordern, die mit breiteren Bussystemen besser zu lösen ist, aber solange Dir 8 Bit-Arritmetik ausreicht, Du aber kurze Reaktionszeiten und schnellen Datendurchsatz brauchst, wozu dann mehr Busbreite durchschieben? Ich erinnere mich an ein eben solches schmerzhaftes Erwachen, als ein Freund von mir mit dem ARM7 Derivat von Philips (damals noch) feststellen musste, dass dort die I/O Zugriffe sooooooooooo schnarchlangsam waren, daß es sein komplettes Projekt fast gesprengt hatte. Nix übrig geblieben vom 60 MHz 32 Bit Power. Zum Schluß war wieder ein 20 MHz 8-Bitter drin... der ist einfach schneller...
Ausserdem ist's halt einfach, wenn man mal so auf die schnelle wa codiert, ohne gross über die Architektur zu grübeln.
Bei großen Stückzahlen gehts sowieso darum, was man als kleinste CPU einsetzen kann, die das noch schafft. Kostenminimum für BOM halt. Da haben Architektur und die Wünsche des Entwicklers sowieso Nachrang.
"Helmut Schellong" schrieb im Newsbeitrag news:evi0vf$a98$03$ snipped-for-privacy@news.t-online.com...
Ich stimme dir nicht zu.
Es gibt bestimmte einfache Aufgaben (z.B. Datenseparation oder Erkennung von Adressen in Datenstreams) fuer die ein uC zu langsam und ein CPLD nicht ganz passend ist, und fuer die man sich haenderingend nicht nur einen 100MHz, sondern warum nicht einen einfachen 3GHz uC wuenschen wuerde. Es erfordert kein floating point und keinen Speicher fuer Datenmengen, sondern nur eine schnelle CPU. Man waere froh, wenn es so eine uC in einem kleinen Gehaeuse mit wenigen Pins gaebe, und wuerde ihm sogar 1.8V core-Spannung zur Verfuegung stellen, aber jeder 'breite' Prozessor ist nicht nur zu teuer, sondern komplett unangemessen.
Man kann es auch andersrum aufzaeumen: Man zaehlt die Stromaufnahme.
16 bit kostet doppelt so viel Strom wie 8 bit weil doppelt so viel umzuschalten ist. Doppelte Taktfrequenz kostet auch doppelt so viel Strom. Wenn ein 16 bit uC nun doppelt so viel 'wegschafft' wie ein gleich schneller 8 bit uC, lohnt eine Steigerung der Taktfrequenz nicht. Bei manchen Jobs (z.B. Zahlen ueber 256 zu verarbeiten) geht es klar zu Gunsten des 16 bit uC aus, aber bei den angesprochenen Jobs fehlen den 16 bit uCs eben die 'in-einem-Takt-auf-vielen-Bits- parallel-verschiedenen-Operationen', so das der 16 bit uC die Aufgabe nicht schneller bearbeiten kann als der 8 bit uC - und dann lohnt sich ein 8-Bitter mit hoeherer Taktfreqeunz sehr wohl.
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
Beispielsweise der moderne 16-bitter mb90f345 von Fujitsu hat etwa 2...16 us einstellbare Wandlungszeit. Sample- und Compare time sind einstellbar. Kurze Zeiten kann man einstellen bei Ub>=4.5V und relativ niederohmiger Meßspannung.
Als (besonderen) Vorteil kann man also die Zeiten des 8051 nicht bezeichnen.
--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
Letzteres ist für seinen Vorgänger leider richtig - viel zu früh, mit
:-(
Der jetzige Inhaber dieser Professur, den Markus vermutlich meint, war (laut seinem offiziellen Lebenslauf) "leitender Angestellter" bis er sich auf die Professur beworben hat.
Das ist ein schlechtes Vergleichskriterium bei uC, wegen der unterschiedlichen Bitbreite.
Der hat zur Zeit 24 MHz, im Mittel etwa 3 Takte pro Instruktion, einen 32Bit-Akku und mehrere 32Bit-Register, 32:16-Division in etwa 20 Takten. Es ist geplant 64 MHz und 1 Takt pro Instruktion.
Eine von mir entwickelte sqrt(int)-Funktion braucht nur etwa 12 us. Das ist eine Stärke dieses uC.
--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
Fast so schlimm, wie die Story, die ich vor ein paar Jahren (5?) von einem meiner Azubis hörte. Die hatten an der Berufsschule ein 8080 System. Als er bei Intel wegen eines Datenbuchs nachfragte, fragte ihn die Nase im Callcenter "Sind Sie sicher, dass der von uns ist?"
Ob es sinnvoll ist, dass die Industrie die lernresistenten Mitarbeiter an die FHs abschiebt?
Das ist das einzig sinnvolle Vergleichskriterium, wenn es auf hohe Rechenleistung ankommt und wenn die Anwendung ein typisches 8-Bit Problem ist, bei der die 16 Bit keinen grossen Vorteil darstellen.
Das ergibt 8 MIPS.
Beim C8051F120 kann man im Mittel 1,5 Takte pro Instruktion ansetzen, das ergibt dann 66 MIPS, also mehr als 8 Mal so schnell.
Aber es kommt natürlich auf die Anwendung an. Bei manchen Anwendungen bringt ein 16 Bit Controller keinen Vorteil, und bei anderen Anwendungen kann das ganz anders aussehen.
Geplant wird viel... aber ob es dann auch realisiert wird steht auf einem anderen Blatt.
Natürlich paßt das für entsprechende Aufgabenstellungen. Wenn ich nur Daten habe, die 8Bit oder weniger beanspruchen, dann nützen mir 16, 32 oder 64-Bit Register und ALUs sogut wie garnix (höchsten für Adressberechnungen), hoher Takt hingegen aber sehr wohl.
Beispielhafte Preisfrage: Um wieviel schneller findet ein
64-Bit-Prozessor das Ende eines nullteminierten Ansi-Strings im Vergleich zu einem 8-Bit-Prozessor? Na?
Also: Der einzige Vorteil, den du aus den 64 Bit Registern bei dieser Aufgabe ziehen kannst, ist der größere Adressraum, die durchsuchbaren Strings dürfen also länger sein. Das ist schon alles.
Und selbst dieser Vorteil ist eigentlich kein echter. Denn die Größe der Adressregister hat ja meist mit der ALU-Breite garnix zu tun, weil es für die (einfachen) Adressberechnungen i.d.R. sowieso eine getrennte Einheit gibt.
Die meisten 8-Bitter haben z.B. sowieso 16 Bit breite Adressregister (als Paare von 8 Bit Registern), könnten aber genausogut auch breitere haben, denn es spricht rein garnichts dagegen, statt einem Registerpaar z.B. ein Trio oder ein Quartett vorzusehen. Es wäre also durchaus machbar, 8 Bitter mit einem 4GB-Adressraum zu bauen. Der Mehraufwand hielte sich in einem sehr bescheidenen Rahmen, jedenfalls wenn es keine komplexeren Adressierungsarten gibt als indirekt, indirekt+in/dekrement, indirekt+in/dekrement+8 Bit-displacement. Du brauchst dann nur die paar Gatter mehr, die nötig sind, um zwei weitere Überträge auszuführen.
Ich hatte bisher *nur* Daten, die unbedingt 16 Bit brauchten. Beispielsweise bis 300 V in 1/10 oder 1/100 Volt. Und ich brauchte bisher *unbedingt* mindestens eine ADC-10-Bit-Wandlung! Unbedingt! 8 Bit ist eine Auflösung, die fast immer absolut indiskutabel ist, weil die Sprünge des im im LCD gezeigten Wertes viel zu groß sind. Manche Kunden hatten sogar die 10-Bit-Auflösung nicht akzeptiert.
Ich verwende auch Objekte mit 32 oder mehr Bits, um einen Clocktick für Verzögerungen zu erhalten. Da wird gefordert, daß der Wert mindestens 8 Jahre nicht durch 0 geht.
Und so weiter, und so weiter, und so weiter.
[...]
Ich persönlich kann mit 8 Bit nur bei Satelliten-Controllern etwas anfangen - niemals bei Hauptaufgaben-Controllern. Dem Linker werden bei 16 Bit die Code-Segmente schon dauernd zu groß ...!
--
Mit freundlichen Grüßen
Helmut Schellong var@schellong.biz
Bei gescheiter Programmierung und entsprechenden ALU- Funktionen knapp achtmal so schnell ;-)
Genau für soetwas wurden gewisse Vektorbefehle (MMX & Co) erdacht.
Die CPU liest acht Zeichen mit einem Schlag ein und prüft alle acht parallel auf ungleich Null. Das ist eine gängige Vorgehensweise bei schnellen Library-Routinen.
Der Zusatzaufwand in der ALU für derartige Befehle ist marginal, deshalb sind sie z.B. inzwischen selbst in größeren DSP's Standard.
Schmarrn. Siehe Erklärung oben.
Naja, sehr viele Programme der lieben anspruchsvollen Kunden verwenden heute int-Größen mit mindestens 16 Bit.
Da bedeuten 8 Bit jedesmal einige zusätzliche Befehle und Zyklen.
Und zwar völlig unnötig, weil bei den heutigen Prozessdimensionen für Halbleiter selbst bei einem popeligen 0,8um Hochvoltprozess die 16 Bit breite ALU überhaupt nicht ins Gewicht fällt (*). Geschwindigkeit: Carry Look Ahead mit Generate und Propagate wurde vor ungefähr 40 Jahren schon mal erfunden ...
Ausnahmen mögen extremst-Low-Price-Produkte sein (China-Uhr), wo jeder Quadratmikrometer Chipfläche zählt.
Und die RAM bzw. Flash/ROM-Speicher sind auf dem IC sowieso rein aus Gründen geeigneter Kantenlängen eher deutlich breiter, selbst auf 16 Bit muss man meist runtermultiplexen.
Machbar schon, aber im Rahmen selbst des Standes der Halbleiterei von vor 10 Jahren weitgehend sinnfrei.
Gruß Oliver
P.s.: Ich hab' soetwas bei 0,35um schon mal gemacht: "Platz ? Ach lass uns doch den 16 Bit Rechenpfad zur Oberwellen-Kompensation und für andere mögliche Zwecke noch ein weiteres mal unterbringen." In dem Fall wäre ohne den zweiten Pfad kein Quadratmikrometer Silizium gespart worden, denn das Design war Pad-Limited, sprich die für die Anschlußpads nötige Fläche bestimmte die Chip-Größe.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.