Vorteile 32 Bit Controller

um mal nur bei den Vorteilen (die auf anhieb einleuchten sollten) zu 
bleiben.

32bitter bieten mehr rechenleistung als 8- oder 16bitter.

> ich les überall was von 32 bit controllern,...
>
> Also was ist jetzt der entscheidende Vorteil, das die so einen Boom
> erleben?

Kurz gesagt, die höhere Datenverarbeitungsrate.

In ein 32 bit-Register passen nun mal 4 mal mehr bits als in eins mit 8 
bit. Daher kann er im Prinzip 4 mal mehr Daten mit einem Maschinenbefehl 
transportieren als der 8-bit Controller. Dies ist insbesondere bei 
Anwendungen, die viele Daten schaufeln müssen wichtig, z.B. Audio oder 
Videobearbeitung. Bei Rechenoperationen ist der Vorteil meist noch 
grösser. Eine 32x32 Bit Multiplikation schafft der 32-Bitter meist in 
einem Assemblerbefehl, mit 8 Bit brauchts dazu ca. 100.

Für einfache Aufgaben, wo weder viele Daten geschoben noch viel 
gerechnet werden muss, ist ein 32-Bit Controller dagegen immer noch ein 
Schuss mit der Kanone auf Spatzen.

Fazit: 8bit, wenns reicht, 32 bit, wenn man es braucht!

Gruss
Mike

Andreas Kaiser wrote:
> Bei 32-Bit-Prozessoren entfällt dieser Aufwand, ROM, RAM und I/O-Ports
> liegen im gleichen Adressraum und lassen sich mit den gleichen Zeigern
> adressieren.

Stimmt nicht ganz, hängt davon ab ob die 32-Bit CPU eine
"von Neumann" oder Harvard Architektur hat. Bei letzterem
sind Daten und Adressen auch in getrennten Speichern unter-
gebracht. Als Softwareentwickler in einer höheren Programmier-
sprache merkt man dieses allerdings nicht. Wie beim AVR halt auch.

Und Datenbreite ist auch ein Vorteil, der Geschwidigkeit bringt.
Bei einem Speicherzugriff 32 Bit oder nur 8 Bit zu verarbeiten
ist schon ein Unterschied.

Hajo

Ganz großen Dank für all die tollen und informativen Beiträge.

Man lernt nie aus und dank euch ist bei mir ne weitere Lücke 
geschlossen,...

DANKE

Gruß

Andreas Kaiser wrote:
>
> Im Gegenteil. Man merkt es dauernd, weil man bei Daten stets im Auge
> behalten muss wo sie liegen. Bei Pointern wie auch bei statisch
> angelegten Daten.

Aber da kommt man doch nicht hinter, da der Compiler sich eben um diese 
Attributvergabe kümmert. Du mußt es nur beachten, wenn Du einen 
Speicherdump machen willst. Dann mußt Du genau berücksichtigen, welchen 
Speicher mit welchen Adressen will ich jetzt dumpen. Aber eigentlich 
sollte auch das diese Arbeit vom Debugger abgenommen werden.



Hajo

Der MSP430 hat die Beschränkung auf 64kB Speicher mit der Einführung des 
MSP430x Cores auch schon länger aufgehoben.

Viele Grüße
Michael

Andreas Kaiser wrote:
> Ha Jo wrote:
>
> Wie sieht bei dir eine Funktion aus, die einen String unabhängig davon
> akzeptiert, ob dieser im ROM oder im RAM liegt?

OK, das ist sicher war. Man muß dem Compiler sagen, wo das Zeugs liegt,
allerdings ist das auch mit Schlüsselwörtern abstrahiert und ich
finde das dann ausreichend. Der Compiler erkennt das natürlich nicht
automatisch. Aber er erkennt ja auch nicht bei

printf("%s %d","string_var,int_var);

die Variablentypen. Ist ein ähnlicher Fall. Da ist C halt beschränkt :-(
Und auf der Ebene betrachtet finde ich, nimmt der Compiler einem auch
Arbeit ab, wenn es um Speicherbereiche (FLash,Ram) geht.

Hajo

Der MSP430x Core ist eine 16Bit CPU, die aber einen 20Bit Adressraum 
hat. Dazu werden 4Bit von der Befehlscodierung für die zusätzliche 
Adressierung abgezweigt. So ganz grob umschrieben ;-)

>Aber er erkennt ja auch nicht bei
>
>printf("%s %d","string_var,int_var);
>
>die Variablentypen.

Sollte er eigentlich schon! Der GCC z.B. gibt eine Warnung aus wenn man 
z.B. printf("%s %d", int_var, string_var); schreibt.

Johnny Maxwell wrote:
>>Aber er erkennt ja auch nicht bei
>>
>>printf("%s %d","string_var,int_var);
>>
>>die Variablentypen.
>
> Sollte er eigentlich schon! Der GCC z.B. gibt eine Warnung aus wenn man
> z.B. printf("%s %d", int_var, string_var); schreibt.

Ja aber du hast leider nicht verstanden, was ich meine oder
ich habe es zu schlecht erklärt.

Hajo

http://www.youtube.com/watch?v=D3ZhUv_acxE

> Ist MSP430X nun eine 16-Bit CPU oder eine 20-Bit CPU?

Die Bitbreite eines Prozessors richtet sich normalerweise nach der 
Breite des Datenbusses, nicht nach der Adressbreite.

Am besten Verständlich wird das Anhand von Beispielen:

* 6502 und 6800 sind 8-Bitter, obwohl sie einen 16-Bit Adressbus haben.
* 8086 ist ein 16-Bitter, obwohl er einen 20-Bit Adressbus hat.
* 68000 ist ein 16-Bitter, obwohl er einen 24-Bit Adressbus und 32-Bit 
Register hat.
* Der Pentium ist aufgrund seinen Datenbusses eigentlich ein 64-Bitter, 
obwohl man sich da aufgrund der 32-Bit Register streiten kann.

Man kann einfacher mit größeren Zahlen als von -128..127 bzw 0..255 
rechnen. Wer schon mal probiert hat ein Videosignal auf einem Tiny15 in 
Echtzeit zu berechnen stößt schnell darauf das es mehr als 255 Zeilen 
gibt....

@ Christian R
In dieser Richtung wird es schon sehr bald was geben :-)

Hauptvorteile eines 32-Bitters, IMHO:

- Adressbreite: Man bekommt damit bis zu 2^32 Speicherwörter adressiert, 
das sind normalerweise 4 GB und das reicht für alle erdenklichen 
Embeddend-Anwendungen. Im Gegensatz zu den 8-Bittern, wo bereits sehr 
kleine Controller mehr als 256 Speicherwörter besitzen und daher die 
Adressen über jeweils 2 Register berechnen müssen.

- Zahlengrösse/-genauigkeit: 8-Bit-Zahlen sind für viele Anwendungen 
genug, aber in sehr vielen Fällen eben viel zu wenig. Wenn man nur 8 Bit 
pro Operation verarbeiten kann, werden grössere Zahlen bei grossen 
Geschwindigkeitsanforderungen schnell ein Problem.


Im Gegensatz dazu haben 8-Bitter IMHO keine echten Vorteile, ausser halt 
dass sie günstiger in der Herstellung und im Stromverbrauch sind. 
Bekommt man einen 32-Bitter zum gleichen Preis und mit dem selben 
Stromverbrauch wie der 8-Bitter gibt es IMHO keinen Grund, einen 
8-Bitter zu nehmen.

@Andreas Kaiser:

Ich persönlich würde die "Bittigkeit" eines Prozessors auch eher an der 
Breite des Akkumulators oder der Universalregister festmachen.

Das ändert aber nichts an der Tatsache, daß Prozessoren üblicherweise 
über den Datenbus eingestuft werden.
In der einschlägigen Literatur wird der 68000 definitiv als 16-Bitter 
geführt. Und ich weiß sehr wohl, daß er intern anders aussieht, da ich 
ihn lange Zeit in Assembler programmiert habe. Im übrigen hing es sehr 
stark vom C-Compiler ab, ob "int" als Long oder Word interpretiert 
wurde. Die meisten Compiler für den Atari ST setzten "int" mit einem 
16-Bit Word gleich.

Die absolut skurrilste (falsche) Klassifizierung, die ich jemals gehört 
habe, war, als jemand behauptete, der ARM sei ein 32-Bitter, weil die 
Instruktionen 32-Bit lang sind. (Von Thumb hatte er offensichtlich noch 
nichts gehört.) Das richtig üble daran war, daß es sich dabei meiner 
Ansicht nach auch noch um einen Studenten von Steven Furber handelte...

>Im Gegensatz dazu haben 8-Bitter IMHO keine echten Vorteile, ausser halt
dass sie günstiger in der Herstellung und im Stromverbrauch sind.
Bekommt man einen 32-Bitter zum gleichen Preis und mit dem selben
Stromverbrauch wie der 8-Bitter gibt es IMHO keinen Grund, einen
8-Bitter zu nehmen.<

Im Prinzip ja; aber es gibt auch Anwendungen, wo ein 8-Pinner ausreicht, 
sodaß ein 8-Bitter passend ist: jedes Bit hat seinen eigenen Pin :-)

Wie Andreas würde ich auch die Bittigkeit anhand der Breite der ALU oder 
Register einordnen. Ansonsten ist das doch alles Wurscht. Für die 
meisten Anwender ist doch bei der Auswahl entscheidend, ob man mit dem 
Prozessor vertraut ist und ob das I/O passt.
Für den einen ist es wichtig, einen Portpin mit 10MHz schalten zu 
lassen, der andere liebt es 10MFlops zu rechnen. Die 'guten' 32-Bitter 
machen beides :-)

>Auch haben 8Bitter immer eine vorhersagbare Zykluszeit und in der Regel
>auch eine deterministisch funktionierende Interruptlogik.

Wie, und die 32-Bitter machen mal so, mal so?
Ist doch Quatsch!

Also,

in der Regel haben die 32bit Controller eine Pipeline mit Prefetch usw. 
eingebaut. Damit kann man halt nicht mehr so leicht die Cycles zählen.

Was ich aber noch für ein viel wichtigeres Argument halte:
- 32bit Controller werden nie den Ruhestrom eines 8bit Controlelrs 
erreichen.
- Zumindest in großen Stückzahlen sind die 8bit Controller deutlich 
billiger.

In wie weit in diesem Zusammenhang noch "hochgezüchtete" 8bit Controller 
wie die XMEGA, die deutlich auch Anwendungen für 32bit Controller 
adressieren, Sinn machen, muss man denke ich von Fall zu Fall 
entscheiden.

Die Controlleranbieter lernen aber, so daß vieles nicht mehr so 
kompliziert ist wie noch vor einigen Jahren.

So ist eine einzige Spannungsversorgung bei aktuellen 32-Bit-Controllern 
mittlerweile schon üblich.
Der Stromverbrauch ist bezogen auf die Frequenz auch nicht signifikant 
höher als bei 8-Bittern, in den meisten Anwendungen dürfte das nicht 
spürbar sein.

Ein ARM-Cortex-M3 hat auch eine feste Interrupt-Latenz, die hat nicht 
mal der (8Bit-) AVR.

Zudem liefern Hersteller wie Luminary oder ST Libraries zu ihren 
Controllern, die einen Einstieg leicht machen.

Wer z.B. schon mal einen ARM-Cortex-M3-Controller genutzt hat, weiß, 
wovon ich rede.
Der Einstieg in die Atmel-AVRs hat mich mehr Zeit gekostet als in die 
Luminary-Controller. Bei den Luminaries einfach ein paar API-Funktionen 
aufrufen, passt. Simpler geht es nicht.
Wenn man dann spezielle Funktionen braucht (die es eh auf 8Bittern nicht 
gibt), kann man sich immer noch mit den komplizierteren Details 
beschäftigen.

Den vielen Hobbyisten hier im Forum kann ich die Cortex-M3 als 
"Standard"-Controller nur empfehlen. Nur bei sehr kleinen Baugrößen 
(<28SOIC) oder wenn es partout PDIP sein muss, kommt noch ein AVR in 
Frage.
Man hat ja auch im Hobby nicht unbegrenzt Zeit, warum also nicht gleich 
mit den 32ern anfangen? Die decken halt einen größeren Anwendungsbereich 
ab.

@Andreas Kaiser:

> Das sind die gleichen Leute, die Von-Neumann und Havard an den
> getrennten internen Bussen festmachen

Zu dieser Kategorie gehören dann aber meiner Ansicht nach auch John 
Hennessy und David Pattorson, die im Prozessorbereich eigentlich 
anerkannte Spezialisten sind.

> und damit aus PC-Prozessoren
> wahlweise das eine (486, Cyrix) wie das andere (Pentium, Kx) machen. Was
> nahezu jedem Programmierer völlig schnurz sein kann und den Sinn dieser
> Kategorisierung weitgehend ad absurdum führt.

Die IA-32-Prozessoren haben hierbei allerdings einen Sonderstatus. Aus 
Performanzgründen haben die neueren Implementierungen getrennte 
Instruktions- und Daten-Caches, aber aus Kompatibilitätsgründen wird der 
Datencache mit dem Instruktionscache abgeglichen.

Wenn du selbstmodifizierenden Code auf einem Prozessor ausführst, der 
die Caches nicht abgleicht, wirst du sehr wohl einen Unterschied 
feststellen, da du ohne einen Flush das Datencaches sehr fehlerhaftes 
Verhalten bekommst.
Habe ich selbst auf einem StrongARM (getrennte Caches) im Vergleich zu 
einem ARM610 ausprobiert (ein Cache).

Bevor jetzt der Einwurf kommt, daß selbstmodifizierender Code ohnehin 
schlechter Stil ist:
Ich habe mich zu diesem Zeitpunkt mit dynamischer Binärcodeübersetzung 
(auch bekannt als "dynamic recompilation") beschäftigt.

> Im Gegensatz dazu haben 8-Bitter IMHO keine echten Vorteile, ausser halt
> dass sie günstiger in der Herstellung und im Stromverbrauch sind.
> Bekommt man einen 32-Bitter zum gleichen Preis und mit dem selben
> Stromverbrauch wie der 8-Bitter gibt es IMHO keinen Grund, einen
> 8-Bitter zu nehmen.

das stimmt, der lpc2101 bzw lpc2103 kostet nicht mehr, wie ein 0815 AVR 
µC.
Tatsache ist, dass ein AVR überschaubarer ist wie ein lpc2101 und die 
Appication läuft schneller auf dem AVR, als auf dem lpc. Ich persönlich 
würde mich lieber mit dem AVR rumschlagen, wie mit einem lpc. Für mich 
heißt das, 32bit wenn nötig, 8/16bit wenn möglich.