Forum: Mikrocontroller und Digitale Elektronik Vorteile 32 Bit Controller


von derEwigeLernende (Gast)


Lesenswert?

Hallo zusammen,
ich les überall was von 32 bit controllern,...
wo genau liegt denn jetzt der große Vorteil an den Dingern???
so viel mehr RAM als die 8 / 16 Bitter, und da wären die ja dann recht 
schnell voll.

Also was ist jetzt der entscheidende Vorteil, das die so einen Boom 
erleben?

Also im wiki und google hab ich keine passende Antwort gefunden...

Gruß
derEwigLernende

von Michael G. (linuxgeek) Benutzerseite


Lesenswert?

Das kommt auf die Anwendung an. Die Vorteile sind naturbedingt, nur dass 
man sie fuer vieles halt nicht braucht.

von Bernhard R. (barnyhh)


Lesenswert?

Das ist genau dasselbe wie mit den Autos: Ein 911er Porsche ist auch 
viel schneller als ein SMART - zumindest auf freier Strecke. Im Stau 
sind beide gleich schnell, und wenn es an die Tankrechnung geht, dann 
sieht es noch ganz anders aus. BTW: Der SMART kann notfalls auch quer 
parken!

Alle diese Dinger sind kein Selbstzweck; sie sind ausschließlich 
Hilfsmittel, um ein Ziel zu erreichen.

Grüße
Bernhard

von Michael G. (linuxgeek) Benutzerseite


Lesenswert?

Ich finde bei kleinen Mikrocontrollern wie den AVR vor allem schoen, 
dass sie so wunderbar ueberschaubar sind. Kein OS, keine komplexe 
Software im Hintergrund... alle Ressourcen gut unter Kontrolle. Das hat 
seine Vorzuege aber auch seine Grenzen. Da such ich ja gerade den 
Kontrast zur PC-Programmierung.

von Peter D. (peda)


Lesenswert?

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

Marketing, 32bit klingt einfach besser.

Du würdest doch auch die elektrische Zahnbürste kaufen, wo 32Bit 
draufsteht und die mit 8Bit liegen lassen.

Allerdings hat kein Ding nur Vorteile allein.

32Bitter sind natürlich komplexer zu programmieren (mehr zu lernen, mehr 
Fehlerquellen, mehr Bugs).


Peter

von tobi (Gast)


Lesenswert?

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

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

von Mike (Gast)


Lesenswert?

> 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

von Andreas K. (a-k)


Lesenswert?

Dass hat eher wenig mit der Datenbreite zu tun. Dir primäre Vorteil ist 
der einfache Umgang mit einem Adressraum über 64KB, Code und Daten 
zusammengerechnet.

8- und 16-Bit Prozessoren können mehr als 64KB Daten nur schlecht 
adressieren, und um nicht noch mit dem Code zu kollidieren sind die 
Code- und Datenadressräume oft getrennt. Das führt zu speziellen 
Vorkehrungen im Compiler und zu entsprechendem Aufwand bei der 
Programmierung. So unterscheidet die Datenadressierung bei 8051 zwischen 
7-Bit-, 8-Bit-, 16-Bit- und ROM-Adressen).

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.

von Ha Jo (Gast)


Lesenswert?

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

von derEwigeLernende (Gast)


Lesenswert?

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ß

von Andreas K. (a-k)


Lesenswert?

Ha Jo wrote:

> Stimmt nicht ganz, hängt davon ab ob die 32-Bit CPU eine
> "von Neumann" oder Harvard Architektur hat.

Wohl wahr. Indes sind 8- und 16-Bit CPUs mit einheitlichem 64KB 
Adressraum mittlerweile selten geworden, weil's einfach zu wenig ist. 
MSP430 hält hier noch die Stellung, aber sonst?

> Als Softwareentwickler in einer höheren Programmier-
> sprache merkt man dieses allerdings nicht. Wie beim AVR halt auch.

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.

Compiler für Harvard-Architekturen definieren bestimmte Attribute um 
verschiedene Daten- und Pointerklassen zu definieren (so sie dazu in der 
Lage sind). Solche im ROM, solche im RAM, kurz adressierte Daten (8051 
8bit, M16c 16bit), lang adressierte Daten (8051 16bit, M16c 20bit) und 
universelle Daten bei denen langsame Laufzeitfunktionen mit 24-Bit 
Pointern nötig sind um sie letztlich auf die unterschiedlichen 
Zugriffsbefehle abzubilden.

von Ha Jo (Gast)


Lesenswert?

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

von Andreas K. (a-k)


Lesenswert?

Ha Jo wrote:

> Aber da kommt man doch nicht hinter, da der Compiler sich eben um diese
> Attributvergabe kümmert.

Tut er das? Wie sieht dein Aufruf printf("%s %s %s", string1, string2, 
string3) aus, wenn
- der Formatstring im ROM liegt,
- die Variable string1 im RAM liegt,
- die Variable string2 im ROM liegt,
- von der Variablen string3 nicht bekannt ist, ob sie in ROM oder RAM 
liegt.

Wie sieht bei dir eine Funktion aus, die einen String unabhängig davon 
akzeptiert, ob dieser im ROM oder im RAM liegt?

von Michael (Gast)


Lesenswert?

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

von Andreas K. (a-k)


Lesenswert?

Yep. Ist MSP430X nun eine 16-Bit CPU oder eine 20-Bit CPU?

von Ha Jo (Gast)


Lesenswert?

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

von Andreas K. (a-k)


Lesenswert?

Ha Jo wrote:

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

Ich finde es viel angenehmer, wenn ich mir diesen Zirkus nicht antun 
muss. Vielleicht nicht zuletzt deshalb, weil ich schon mit recht vielen 
Architekturen beschäftigt habe und mich nicht allzu gern auf proprietäre 
Erweiterungen der Compiler einlasse.

Versuch mal, Code zu übernehmen, dessen Autor sowas nicht auf der 
Rechnung hatte, beispielsweise den TCP/IP-Stack uIP. Da erweist sich 
diese Adressraumtrennung als sehr hinderlich.

von Michael (Gast)


Lesenswert?

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

von Johnny Maxwell (Gast)


Lesenswert?

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

von Ha Jo (Gast)


Lesenswert?

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

von Joe (Gast)


Lesenswert?


von Michael König (Gast)


Lesenswert?

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

von Rudi (Gast)


Lesenswert?

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

von Andreas K. (a-k)


Lesenswert?

Michael König wrote:

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

Aus Sicht des Programmierers hat MSP430X 20-Bit Daten/Adressregister und 
20-Bit Daten/Adressoperationen. Dass diese 20 Bits durch einen 16-Bit 
Bus geschleust werden, hat nur auf die Geschwindigkeit, nicht aber auf 
die Programmierung selbst Einfluss.

> * 68000 ist ein 16-Bitter, obwohl er einen 24-Bit Adressbus und 32-Bit
> Register hat.

Ich wollte diese alte Nummer nicht wieder aufwärmen. Aber nun denn. 
68000 ist also ein 16-Bitter und 68008 ein 8-Bitter. Nur: Ohne den 
Rechner aufzuschrauben wirst du den Unterschied nur an der Uhr 
festestellen. Wenn ich nicht grad CPU-Implementierungen auseinander 
nehme, sondern mit den Dingern arbeite, zählt für mich die Sicht des 
Programmierers (ISA = Instruction Set Architecture). Und so war 68000 
für mich immer eine 32-Bit Architektur mit 16-Bit Bus (der Compiler sah 
das ähnlich).

> * Der Pentium ist aufgrund seinen Datenbusses eigentlich ein 64-Bitter,
> obwohl man sich da aufgrund der 32-Bit Register streiten kann.

Welcher Datenbus zählt für dich? Bei aktuellen PC-Prozessoren findest du 
alles zwischen 16 und 256 Bits, je nachdem auf welchen Bus du dich 
beziehst (Integer-ALU, SSE-ALU, L1-Cache, L2-Cache, Bus-Bridges, 
Speicherbus, Hypertransport).

Wenn man den externen Bus betrachtet sind also die aktuellen AMD-CPUs 
gleichermassen 16-Bitter (Hypertransport) und 128-Bitter (Speicher), nur 
garantiert keine 64-Bitter.

von Christian R. (supachris)


Lesenswert?

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

BTW: Wieso implementieren die eigentlich nicht mal mehr RAM? Die neuen 
F261x haben nur noch max. 8kByte. Schlimm sowas. Nicht mal ein externer 
Speicherbus. Ich mag ja die MSP430 total, aber der RAM-Flaschenhals ist 
schon übel, alles muss man zu Fuß machen.

von Thomas (Gast)


Lesenswert?

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

von mr.chip (Gast)


Lesenswert?

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.

von Christian R. (supachris)


Lesenswert?

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

Oha, woher hast du die Info? Gibts da mehr zu erfahren?

von Michael König (Gast)


Lesenswert?

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

von Andreas K. (a-k)


Lesenswert?

Michael König wrote:

> Das ändert aber nichts an der Tatsache, daß Prozessoren üblicherweise
> über den Datenbus eingestuft werden.

Das sind die gleichen Leute, die Von-Neumann und Havard an den 
getrennten internen Bussen festmachen 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.

Weil anno John von Neumann getrennte Busse auch getrennte Adressräume 
implizierte, hat man sich leider an die konkretere Darstellung 
getrennter Busse geklammert statt an die abstraktere der getrennten 
Adressräume.

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

8-Bit PICs werden der Einfachheit auch gern als 12-, 14- und 16-Bitter 
bezeichnet, weil das Codewort grad so breit ist und man irgendeine 
sprachliche Regelung dafür finden muss. Das ein "14-Bit" PIC meist PIC16 
heisst und ein "16-Bit" PIC18 macht die ja auch nicht einfacher. ;-)

Komischerweise hatte sich nie jemand darauf verstiegen, irgendeinen 
alten 680x Controller als 1-Bit Maschine zu bezeichnen, bloss weil 
Motorola die ALU anfangs kostengünstig seriell implentierte.

von Peter D. (peda)


Lesenswert?

mr.chip wrote:

> Im Gegensatz dazu haben 8-Bitter IMHO keine echten Vorteile, ausser halt
> dass sie günstiger in der Herstellung und im Stromverbrauch sind.

Sie haben noch ne Menge anderer Vorteile.

Mir ist z.B. kein 32-Bitter bekannt, der mit 1,8V..5,5V ohne 
Stabilisierung arbeitet.
Und manche benötigen sogar mehrere stabilisierte Betriebsspannungen.

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

Es ist also bei nem 8Bitter viel einfacher, worst case Zeitbedingungen 
auszurechen und zu überprüfen.


Peter

von Andreas K. (a-k)


Lesenswert?

mr.chip wrote:

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

Sagt sich auch mancher Anfänger und stürzt sich als Einstieg gleich in 
einen STR9 (ARM9) rein -- wie höhere Chargen früherer Jahrhunderte in 
ihr Schwert.

von Gast (Gast)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

Andreas Kaiser wrote:

> Sagt sich auch mancher Anfänger und stürzt sich als Einstieg gleich in
> einen STR9 (ARM9) rein -- wie höhere Chargen früherer Jahrhunderte in
> ihr Schwert.

Und lacht aber über diejenigen, die erstmal mit nem (8Bit-)Taschenmesser 
anfangen.
Und ist dann verblüfft, was für hübsche Dinge die innerhalb kurzer Zeit 
damit geschnitzt kriegen.


Peter

von Gast (Gast)


Lesenswert?

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

von Andreas K. (a-k)


Lesenswert?

Peter Dannegger wrote:

> Und lacht aber über diejenigen, die erstmal mit nem (8Bit-)Taschenmesser
> anfangen.

Nö. Der sitzt kurz drauf hier im Forum und verzweifelt öffentlich 
darüber, dass er nicht einmal einen einfachen Interrupt zuverlässig 
(oder überhaupt) gebacken bekommt.

von Thomas (Gast)


Lesenswert?

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.

von Andreas (Gast)


Lesenswert?

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.

von Michael König (Gast)


Lesenswert?

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

von Andreas K. (a-k)


Lesenswert?

Andreas wrote:

> So ist eine einzige Spannungsversorgung bei aktuellen 32-Bit-Controllern
> mittlerweile schon üblich.

Weil ein interner Regler drin ist. Batteriebetrieb wird dadurch nicht 
leichter, AVRs,PICs,MSPs arbeeiten bis runter auf 1,8V und teilweise auf 
auf 5,5V. ARMs ob mit oder ohne internem Regler wollen 3,3V +/-10%. Also 
dann doch wieder externer Regler fällig, der selber wiederum Strom 
verbraucht.

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

Versuch mal mit den kleinen 8KB/28pin LM3 Maschinchen einen ATmega88 im 
Batteriebetrieb oder Batteriepufferbetrieb zu ersetzen. Aber auch ohne 
Batterie: ausser "Rechnen" gibt es wenig, was diese Zwerge besser können 
als ein Mega88, dafür aber einiges was sie nicht können.

von Andi (Gast)


Lesenswert?

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

von Andreas K. (a-k)


Lesenswert?

Jeder Anwendung das was dafür sinnvoll ist. Handelt es sich um eine 
simple Lüftersteuerung die in 7KB passt, ist das mit AVR viel einfacher 
als mit allem 32bittern mit denen ich bisher zu tun hatte. Die 
getrenntne Adressräume sind in dieser Grössenordnung nicht weiter 
schlimm.

Ist das eine Anwendung mit >40KB Code, reichlich Strings und Tabellen 
und mit eher komplexer Software in mehreren Layern, möglicherweise noch 
TCP/IP mit an Bord, dann favorisiere ich hingegen irgendwelche ARMs. 
Auch wenn das mit AVR ebenfalls geht, sind mir die dafür aufgrund der 
weiter oben skizzierten Adressraumhandhabung zu umständlich.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.