Welcher Mikrokontroller hat welchen Verbreitungsgrad?

Da stimme ich zu.

8 Bit + 100 MHz passen irgendwie nicht 'homogen-vernünftig' zusammen.

In der Praxis kristallisiert sich eine jeweils 'vernünftige' Maximalgröße für 8/16/32 Bit heraus, betreffend die ROM-Größe (Code+Const).

Ich würde beispielsweise bei 16 Bit nennen: 384 + 128 = 512 KB Flash-ROM

Bei höherem Bedarf sollte man auf 32 Bit gehen.

--
Mit freundlichen Grüßen
Helmut Schellong   var@schellong.biz
 Click to see the full signature
Reply to
Helmut Schellong
Loading thread data ...

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.

Hergen

Reply to
Hergen Lehmann

WIE schnell denn ... bei 10 Bit Auflösung?

--
Mit freundlichen Grüßen
Helmut Schellong   var@schellong.biz
 Click to see the full signature
Reply to
Helmut Schellong

Hallo Henning,

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

Marte

Reply to
Marte Schwarz

man tool chain?

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.

Heinz

Reply to
Heinz Liebhart

Hallo,

ich hoffe mal das holprige Deutsch und die Rechtschreibfehler stammen von Markus und nicht vom Professor.

Bye

Reply to
Uwe Hercksen

"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/
 Click to see the full signature
Reply to
MaWin

Hi,

AD 8 Bit 500kS/s AD 10 Bit 100kS/s AD 12 Bit 100kS/s

Gruss Michael

Reply to
Michael Koch

Aha, *für ganz bestimmte Aufgaben* mag das sinnvoll sein.

Jedoch ich stimmte selbstverständlich in einem ganz allgemeinen Rahmen zu, keineswegs im Sinne von Spezialanwendungen!

--
Mit freundlichen Grüßen
Helmut Schellong   var@schellong.biz
 Click to see the full signature
Reply to
Helmut Schellong

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
 Click to see the full signature
Reply to
Helmut Schellong

Letzteres ist für seinen Vorgänger leider richtig - viel zu früh, mit

  1. :-(

Der jetzige Inhaber dieser Professur, den Markus vermutlich meint, war (laut seinem offiziellen Lebenslauf) "leitender Angestellter" bis er sich auf die Professur beworben hat.

Gruß Bernd

Reply to
Bernd Waterkamp

Ingrid schrieb:

Das bezog sich auf seine Position bei Infineon, siehe oben.

Gruß Bernd

Reply to
Bernd Waterkamp

Hi,

und wieviele MIPS schafft der?

Gruss Michael

Reply to
Michael Koch

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
 Click to see the full signature
Reply to
Helmut Schellong

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?

Gruß

Stefan

Reply to
Stefan Brröring

Hi,

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.

Gruss Michael

Reply to
Michael Koch

Hallo Michael,

... und was es am Ende kostet.

--
Gruesse, Joerg

http://www.analogconsultants.com
Reply to
Joerg

Ich absolut nicht.

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.

Reply to
Heiko Nocon

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
 Click to see the full signature
Reply to
Helmut Schellong

Die Antwort willst Du nicht hören:

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.

--
Oliver Bartels + Erding, Germany + obartels@bartels.de
http://www.bartels.de + Phone: +49-8122-9729-0 Fax: -10
Reply to
Oliver Bartels

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.