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
Das kommt auf die Anwendung an. Die Vorteile sind naturbedingt, nur dass man sie fuer vieles halt nicht braucht.
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
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.
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
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
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.
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ß
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.
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
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?
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
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.
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
> 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....
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.
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.
@ 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.
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?
@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...
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.
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
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.
>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 :-)
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
>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!
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.
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.
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.
> 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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.