mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR32 vs. ARM


Autor: Teplotaxl X. (t3plot4x1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ich alles recht verstanden hab zielen AVR32 und ARM auf ähnliche 
Anwendungsbereiche. Was sind die Vor- und Nachteile der beiden 
Prozessoren?

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Einfach das ganze Werbematerial bei atmel.com durchschauen, z.B.

http://www.atmel.com/dyn/resources/prod_documents/...

Ist zwar nicht sonderlich ARM-Kritisch, schließlich wollen die weiterhin 
ihre eigenen ARMs verkaufen...

Autor: Anonymous (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
AVR32 würde ich nicht nehmen, weil der zu neu ist. -> Keiner kennt sich 
damit aus.

Autor: klausy (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Atmel will einfach keine Lizenz gebühren zahlen. Desshalb der AVR 32. 
Der wird von Atmel so stark beworben damit die Leute den Kaufen und nich 
den ARM.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was erzählt ihr hier für ein Stuss?

Atmel hat den ARM9 Kern lizensiert (AT90RM9200) und jetzt auch den 
Cortex M3
(Werden wahrscheinlich erst Ende 2009 Controller dazu anbieten).
Glaub einen ARM7 auch, bin mir da allerdings nicht sicher.

---

Der AVR32 ist ein Fall für sich. Gebaut wurde das Teil für 
Multimedia-Anwendungen, die nur wenig Platz brauchen dürfen. Z.B. ein 
kleiner tragbarer Player oder PDA. Die kleinen ARM Kerne (ARM7TDMI, 
Cortex M3) sind eher für Mikrocontrolleranwendungen gedacht. Die haben 
auch keine MMU, sondern höchstens eine MPU.

ARM9, AVR32 sind Controller, auf denen ein Betriebssystem (z.B. Linux, 
CE/Mobile drauf laufen soll [PDA, Handy, etc.].

Also wenn schon ein Vergleich, dann bitte nur mit Bezug auf den 
Anwendungsfall. Der AVR32 hat z.B. in der AP Ausführung ein LCD/TFT 
Controller mit drauf. Was für Anwendungen mit Bildschirm sehr 
vorteilhaft ist!

...

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lassen wir das mit dem Stuss mal beiseite.

Atmel hat intern 2, manchmal konkurierende Abteilungen, die eine macht 
recht erfolgreich ARM7 und ARM9 basierende Microcontroller, die andere 
sehr erfolgreich AVR 8-bit und noch nicht so erfolgreich AVR 32-bit 
Controller.

ARM und AVR32 sind erst mal einfach cores und ARM7 wurde ganz bestimmt 
nicht von Beginn an als Microcontroller konzipiert, dazu klemmts viel zu 
sehr an verschiedenen Ecken, z.B. beim Interrupt um nur mal eine zu 
nennen. ARM7 gibts seit >15 Jahren und erst in den letzten 5+ Jahren ist 
der MCUs richtig populaer geworden.

AVR32 wurde entwickelt fuer Multimediaanwendungen wo der Core Funktionen 
(Befehle) zur Verfuegung stellt, die locker mit einem ARM9 mithalten 
koennen, eigentlich sogar einiges besser sein sollen. Wie bei ARM, gibt 
es auch bei AVR32 ein Lager mit Microcontrollern, (uC3xxx) und eines mit 
mehr Prozessoren (AP7xx). Der Unterschied: Microcontroller mit internen 
Speicher, Prozessoren mit externem Speicher.

Zum Zeitpunkt der Ankuendigung war der AVR32 eine echte Verbesserung 
gegenueber dem ARM7, kein Wunder, er wurde ja auch mehr als 10 Jahre 
spaeter entwickelt. Jetzt, nach Verfuegbarkeit von Bausteinen mit dem 
CortexM3, sind viele der Vorteile, z.B. Interrupt, DIV Befehl, bessere 
Debug Moeglichkeiten.. wieder eliminiert.

Zur Politik / Finanzen, die dahinter stehen. Die Gebuehren, die ARM 
verlangt sind nicht gerade zu vernachlaessigen, die Kosten, die es mit 
sich bringt einen neuen 32-bit Core zu entwickeln, zu pflegen und 
Entwicklungswerkzeuge dafuer zu bekommen auch nicht. Beim AVR (8-bit) 
war das ganze recht ueberschaubar, Atmel hat das Team fuer einen Appel 
und Ei bekommen. Jetzt sind bestimmt 2-stellig Mio Betraege 
reingeflossen. Da bin ich mir ziemlich sicher, da ich schon mal bei 
einer Firma gearbeitet habe, die eine eigene 32-bit Architektur am Markt 
etabliert hat.
Den AVR32 zu den Akten zu legen, weil er kaum noch Vorteile bringt waere 
sehr teuer, ihn weiter am Leben zu erhalten wohl auch. Als Verbraucher 
wuerde ich keine Kostenvorteile erwarten dadurch, das Atmel keine Lizenz 
an ARM bezahlen muss. Der AVR32 Core hat allerdings, wie bereits 
erwaehnt, ein paar Vorteile.

Vorteile ARM: dafuer gibt es alles an Tools, software, viele Entwickler 
kennen sich damit schon aus, Konkurrenz der Anbieter erzeugt niedrige 
Kosten fuer die Bausteine

Vorteile AVR32: Neuere graduell bessere Architektur, niedrigerer 
Verbrauch , Aehnlichkeiten mit AVR soweit es moeglich war, keine Bindung 
an ARM fuer Atmel, somit die Chance mehr Profit zu machen, das steigert 
das Eigeninteresse.

Die Entscheidung musst Du schon selber treffen.

Gruss, Robert

Autor: EFA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die objektive und ausführliche Erläuterung.

Ich sehe den AVR32 als eine interessante Alternative zu den ARMs, freue 
mich über Atmels Mut, auch mal andere Wege zu gehen und hoffe, dass der 
AVR32 nicht zu den Akten gelegt wird.

Autor: crazy horse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nun ja, ich habe den AVR32 wieder zu den Akten gelegt. Ist mir zu 
unsicher, damit wirklich was auf die Füsse zu stellen. Ein Projekt damit 
entwickelt man nicht mal eben in ein paar Stunden. Und was, wenn es den 
plötzlich nicht mehr gibt? Ne.

Autor: Hans Wurst (hans_wurst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich kann mir nicht vorstellen dass Atmel die AVR32 Serie so einfach 
beenden wird. Zum einen weil es eben (wie bereits erwähnt) viel Geld 
gekostet hat und zum anderen, weil Atmel sich in so einem Fall sicher 
schwer tun würde jemals wieder etwas neues am Markt etablieren zu können 
(da jeder Anwender sonst immer Bedenken haben müsste, ob der gleiche 
Fall erneut eintreten würde).

@ Robert:
Woww... das war ein echt interessanter Beitrag. Danke für diese gut und 
kurz zusammengefasste Info.

Ich hätte da allerdings noch eine Frage zu den Tools für die ARM's. Sind 
gute Tools dafür kostenlos verwendbar (genauso wie bei Atmel)?

Autor: Zubuku (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich hätte da allerdings noch eine Frage zu den Tools für die ARM's. Sind
>gute Tools dafür kostenlos verwendbar (genauso wie bei Atmel)?

Das ist nämlich bei mir auch das Problem.
Beim AVR32 bekommt man die IDE kostenlos, bei ARM muss man (kommerziell 
genutzt) sehr viel Geld hinlegen. :-(

Ich weiss auch nicht so recht welchen ich nehmen soll. ARM verbrauchen 
auch noch mehr Strom...

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anonymous wrote:
> AVR32 würde ich nicht nehmen, weil der zu neu ist. -> Keiner kennt sich
> damit aus.

Genau! Immer rein mit diesem Totschlagargument. NIEMAND kennt sich damit 
aus, wirklich niemand.

Egal ob es welche gibt, du kennst sie ja nicht. Also ist es absolut 
niemand, Null, Niente.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich denke, ab einem gewissen Punkt ist es egal, welcher Kern in einem 
µC/µP werkelt. Wenn man spezielles IO erledigen muß z.B. 
Kameraeingang->TFT-Ausgang, hat, glaube ich, ein AP7000 gute Karten. 
Braucht man CAN, USART, Ethernet, Timer oder sonstige Geschichten, muß 
man sehen, welcher Prozessor das Gewünschte möglichst komplett bietet. 
Und ob mir ein GCC Code für einen ARM oder für einen AVR32 erzeugt (oder 
was es sonst dafür gibt), ist mir eigentlich auch schnuppe.

Für mich ist eher der Knackpunkt, welches Gehäuse ich in kleinen 
Stückzahlen überhaupt noch handhaben kann: BGA definitiv nicht. Platinen 
aus dem Pizzaofen würde ich nie verkaufen.

Wenn es um gute Interruptverarbeitung geht, wäre auch die SH-Serie von 
Renesas sehr interessant. SH sind allerdings keine Modeprozessoren 
sondern solide und sehr gereift.
Für 'einfache' Aufgaben ist ein SH7211 gut geeignet :-) Ein absolut 
geiles Teil, wenn ich das so sagen darf. Code dazu wird ebenfalls von 
GCC geliefert.

Soweit mein Senf!

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gast wrote:
> Für mich ist eher der Knackpunkt, welches Gehäuse ich in kleinen
> Stückzahlen überhaupt noch handhaben kann: BGA definitiv nicht. Platinen
> aus dem Pizzaofen würde ich nie verkaufen.

Das finde ich auch sehr bedauerlich. Was will man machen bei so vielen 
Pins.

Autor: Sascha Pypke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ja das Thema musste ja mal kommen.+++

Ich selbst stehe gerade an der Entscheidung ob ich einen AT91SAM9XE oder 
einen AVR32UC3 nehmen soll.
Danke Robert für deinen Bericht fand ich gut.

Ich denke Atmel wird den AVR32 nicht fallen lassen, aber was mich viel 
mehr interresiert wie sieht die Zukunft für AVR32 aus. Welcher Prozessor 
bekommt als erstes eine FPU (wow dann würde es intressant werden).

Bei ARM hat man halt die gewissheit, es geht schon immer weiter.....

Ich schreibe sehr viel in Assembler, da ich DSP mache und auf ARM7TDMI 
schon zu hause bin, fällt es mir sehr schwer den AVR32 zu verstehen. 
Nicht jede Umsetzung die Atmel da gemacht hat finde ich sinnvoll, aber 
die meisten Programmieren ja eh in C und dann ist es doch egal ?!?

Bei ARM arbeite ich mit JTAG Debugging, geht sehr gut.
Bei AVR32 ?????

Allerdings muss ich sagen hat der AVR32 schon eine sehr nette Framework 
Umgebung, die sich klasse nutzen lässt.

Also die Entscheidung fällt mir sehr schwer, da beide Kontroller auch 
eine sehr gute externe BUS unterstützung haben.

Den Grafikcontroller setze ich immer extern, damit der CPU bus nicht 
belastet wird. Dafür braucht man BUS-Arbitration und beide können das 
auch.

Nur 66MHz (AVR32UC3) ist vieleicht doch etwas eng, und der AT91SAM9XE 
macht das Rennen mit 180-200MHz ?, da er auch noch preiswerter ist.

Bitte keine Totschlägerargumente, denn oft leben totgesagte länger !

Autor: Ich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal davon ab, dass es die AVR32 ja noch nicht wirklich gibt, zuindest 
nicht die Controller.
Die ersten UC3 Versionen sind erst vor höchstens zwei Monaten bei 
Digikey aufgetaucht.

Was ich gerade an den UC3 sehr interessant finde gegenüber zum Beispiel 
den LPC von NXP ist, die haben USB-OTG schon ab 64 Pins.
Welcher ARM hat denn das sonst?

Jeder interessiert sich doch für andere Details.

Autor: Andreas Watterott (andreasw) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich wrote:
> Was ich gerade an den UC3 sehr interessant finde gegenüber zum Beispiel
> den LPC von NXP ist, die haben USB-OTG schon ab 64 Pins.
> Welcher ARM hat denn das sonst?
z.B. die Cortex-M3 von Luminary:
http://www.luminarymicro.com/products/product_sele...

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> AVR32 würde ich nicht nehmen, weil der zu neu ist. -> Keiner kennt sich
> damit aus.

Alles eine Ansichtssache. Jeder Controller, der neu ist, ist für einen 
Programmierer ein Überaschungsei. Da zahlt man ne Menge Lehrgeld, bis 
einem das Teil "aus der Hand frisst". Aber deswegen würde ich so ein 
Teil nicht gleich abschreiben. Hardware Bugs sind halt die übelsten 
Überraschungen, gefolgt von Compilerbugs. Das kostet am meisten Zeit und 
Nerven. Aber sonst, kann man auch mal andere Besonderheiten entdecken.

---

>Bei ARM arbeite ich mit JTAG Debugging, geht sehr gut.
>Bei AVR32 ?????

Für den AVR32 gibt es den AVR ONE!. Eine etwas gehobenere JTAG Variante, 
die auch Trace erlaubt. Aber mit knapp 700 Euro recht teuer ist. Der 
soll aber in Zukunft alle AVRs (zumindest die mit JTAG) unterstützen. 
Dann lohnt sich der zumindest für kommerzielle Anwender.
Den AVR32 (AP Controller) würde ich auch nur mit Linux benutzen. Dann 
braucht man den JTAG sowieso nur, um den Bootloader zu programmieren. 
Den Rest muss man dann über GDB o.ä. machen. Einziger Wehrmutstropfen 
bei den AVR32 ist, dass man auf dem Markt kein externes Embedded SDRAM 
mehr bekommt, dass noch 3,3V und eine hohe Speicherdichte unterstützt. 
Da hat der Markt die AVR32 Entwicklung leider schon überholt. Dafür kann 
man aber weiterhin die nicht Embedded RAMs einsetzten, was halt zu einem 
höheren Platzbedarf führt.

Nächstes Jahr gibt es allerdings zwei neue AP Controller, die das 
Problem beheben und ein paar nützliche neue Features haben.

Was die BGAs betrifft:

Klar dass ein Hobby Bastler da keinen Blumentopf mit gewinnen kann. Aber 
die Teile, die als BGAs verkauft werden, sind dazu da, dass man auf 
wenig
Platz viel Peripherie unterbringen kann. Eine "Eierlegende Wollmilchsau"
lässt sich halt nicht mehr in ein TQFP packen, ohne dass man zig weitere 
Chips drum herum pflanzen muss. Bei 325 Balls (AVR32APxxxx) braucht man 
auch schon eine multilayer Leiterkarte mit mind. 6 Lagen und 
wahrscheinlich auch schon Microvias (teuer). Also eher was für 
komerzielle Anwender, die auch ein wenig Geld ausgeben können.

---

Bei den Entwicklungsumgebungen gilt auch, dass man die Einarbeitungszeit 
mit der Leiostung und den Kosten vergleicht. Der GCC ist kostenlos, Aber 
wenn man noch nie wirklich was damit gemacht hat, dann dauert es eine 
Weile, bis man mit dem gut umgehen kann. Einige komerzielle IDEs bieten 
da ein wenig mehr intuitive Bedienung. Allerdings ist Keil mit ca. 2000 
Euro + 300 Euro JTAG (ULINK ME gibts zusammen mit nem ST EVAL Board 
schon für 100 Euro) nicht gerade billig. Der Umgang damit ist allerdings 
auch nicht so schwer. Ich persönlich fand die Keil Umgebung einfacher. 
Die Rowley oder CodeSourcery Teile hab ich irgendwie nicht so zum Laufen 
gekriegt.
Aber da werden die Leute, die schon sehr viel mit GCC und Make geamacht 
haben, evtl. anderer Meinung sein.

Autor: Hmm... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zum Thema GCC:

Wenn man damit noch nix gemacht hat oder gar keine Erfahrung mit 
Kommando-Zeilen basierten Tools, ist die Bedienung von dem Ding schon 
ein nicht zu unterschätzendes Hindernis, egal für welche Plattform man 
ihn nutzen will.

Wenn man allerdings schon einige Makefiles geschrieben hat und etwas 
Erfahrung mit einer Plattform hat kann man damit extrem schnell auf 
einer anderen Plattform loslegen oder bestehenden Code portieren da der 
Code-Parser im wesentlichen der selbe ist und (fast) keine 
Plattform-spezifischen Compiler-Optionen benötgt werden.

In vielen Fällen wo es um reine Berechnungen/Algorithmik (PID-Regler, 
Quicksort, usw.) geht, kann man dann den geschriebenen Code in kleinen 
Happen sogar auf einem PC(!) testen, mit allen damit verbundenen 
Debugging-Möglichkeiten.

Und nicht zu vergessen:

Eine IDE in die der GCC einmal eingebunden ist, kann für nahezu alle 
möglichen anderen Plattformen für die es einen GCC gibt mit wenig 
Aufwand angepasst werden.


Den Komfort einer x000€ Euro Toolchain wird man jedoch damit nicht 
erreichen...

Autor: Stefan Wimmer (wswbln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias wrote:
> ...Was die BGAs betrifft:
>
> Klar dass ein Hobby Bastler da keinen Blumentopf mit gewinnen kann. Aber
> die Teile, die als BGAs verkauft werden, sind dazu da, dass man auf
> wenig
> Platz viel Peripherie unterbringen kann. Eine "Eierlegende Wollmilchsau"
> lässt sich halt nicht mehr in ein TQFP packen, ohne dass man zig weitere
> Chips drum herum pflanzen muss. Bei 325 Balls (AVR32APxxxx) braucht man
> auch schon eine multilayer Leiterkarte mit mind. 6 Lagen und
> wahrscheinlich auch schon Microvias (teuer). Also eher was für
> komerzielle Anwender, die auch ein wenig Geld ausgeben können.

Ich klink' mich da mal mit 'nem Kommentar ein:
Die "Profis" haben für die BGAs auch nicht immer das passende Equipment 
für den Prototypenbau herumstehen, also gibt man die eben zum Bestücker 
raus. Da gibt es welche, die vorzugsweise nur Serienfertigung machen und 
solche, die sich auf Klein(st)serien spezialisiert haben. Manche haben 
auch Abteilungen für beides. Und soooo teuer ist das oft gar nicht. Vor 
allem, weil es dann preislich kaum einen Unterschied macht, ob man 1 
oder 10 BGAs auf der Karte hat...

Und das mit Micro-Vias und teuer war einmal: Da heutzutage jedes Handy 
und viele ander Kompaktgeräte BGAs, FTBGAs und Chipscale-Gehäuse 
verwendet ist das lange nicht mehr so exotisch wie es mal war. Wenn man 
sich dann noch darauf beschränkt die Micro-Vias nur jeweils zwischen den 
beiden äusseren Lagen zu verwenden, kann die Platine weiterhin mit nur 
einem Pressvorgang gefertigt werden. Dann beträgt der Aufpreis gegenüber 
normalen 6-Lagen Platinen nur noch so 20-30%. Auf jeden Fall günstiger 
als auf 8 Lagen gehen zu müssen.

Ok, im Bastlerbereich müssten sich trotzdem noch ein paar Leute z.B. 
über ein Forum wie dieses zu einem Gemeinschaftsprojekt verabreden um 
die Vorlaufkosten zu schultern, aber völlig ausserhalb der Reichweite 
ist das heute nicht mehr. (Ich lasse mir für meine Bastelprojekte ja 
auch schon zunehmend 4-Lagen Platinen machen. Das hätte ich mir noch vor 
einigen Jahren kaum vorstellen können..)

Autor: Stefan Wimmer (wswbln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach so, nochmal zurück zum eigentlichen Thema:

Wie alt die ARM7/9 Cores sind, wurde ja schon erwähnt. Und 
Multimediaprozessoren sind das auch bei hohen Taktraten (wo sie dann 
auch schon merklich heizen) nicht wirklich. Demgegenüber ist die AVR32 
Architektur um einiges moderner und optimaler, allerdings auf Grund der 
beschränkten Speicherbandbreite auch nur bei QVGA bis max. so 800x600 an 
Auflösung. Wenn man bei höheren Auflösungen noch was wuppen will/muss 
(JPEG4 auf 1024x768 oder größer decodieren, scalen und darstellen z.B.) 
braucht man entweder eine entsprechend hurtige CPU (wie sie z.B. in den 
OMAPs von TI drin ist) oder einer entsprechend ausgelegte 
Hardwareunterstützung (zusätzlicher DSP oder Codecs) wie in einigen 
neuen Mitgliedern der DaVinci-Serie von TI.

Natürlich haben andere Hersteller da auch entsprechendes auf der Pfanne 
(Analog mit Blackfin, Freescale mit i.MX, etc.), aber mit den TI-lern 
habe ich mich in der letzten Zeit am intensivsten beschäftigt...

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@hans_wurst

gute und umsonstige tools fuer ARM, der Versuch einer Antwort.

Hier gibts eine kleine ARM Tool Uebersicht mit Links, die nicht nur auf 
LPC2000 sondern auch auf andere ARMs zutreffen.
http://www.lpc2000.com/tools/

Also mehr vom hoerensagen als aus eigener Erfahrung wuerde ich zu 
Yagarto tendieren. Aus eigener Erfahrung im professionellen Bereich habe 
ich immer Keil und IAR als Hauptkonkurrenten gesehen. Beide haben auch 
freie Versionen aber eben nur 16k / 32k.

Der Compiler ist nicht das eigentliche Problem, sondern viel mehr der 
Debugger, das Zusammenspiel von Hardware und Software. Meiner Meinung 
nach das beste Preis/Leistungsverhaeltnis im non-commercial ARM Bereich 
bietet Segger J-Link non-commercial mit Yagarto. Fuer semi-professional 
wuerde ich Rowley empfehlen, denn auch da gibt es eine sehr gute 
Anbindung von Compiler, Debugger und Flash-Moeglichkeiten mit gutem 
Support.

Sorry, falls ich jetzt mal wieder Werbung (fuer viele!?) gemacht habe, 
zum Glueck kann man mir im Moment nicht Eigeninteresse vorwerfen, denn 
ich arbeite fuer keine der erwaehnten Firmen ;-)

Gruss aus dem sonnigen Kalifornien :-)),  Robert

Autor: Sascha Pypke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nochmals Bezug auf den AVR32UC3 zu nehmen was SDRAM betrifft, kann ich 
nur eins sagen, das neue EvalBoard von Atmel hat einen 32MB SDRAM chip 
drauf
(48LC16M16A2) und ich verbaue auch SDRAMs auf meinem EPSON Grafikkarten.
Also die wird es sicherlich noch ne weile geben. Halt nicht mehr von 
jedem Hersteller ?!? Habe mir so ein Board erst zugelegt. Der UC3 wird 
aber auch etwas warm.
Wunder werden da wohl keine mehr verbracht.
Und überhaupt immer die Stromsparerei, sollen doch erst mal die Autos 
weniger sprit verbrauchen, vor die EU mir die Glühbirne zwangsenteignet.

Gruß Sascha

PS. ich gehe auf die Electronica nach München, und werde dort mal sehen 
was sich tut.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>nochmals Bezug auf den AVR32UC3 zu nehmen was SDRAM betrifft, kann ich
>nur eins sagen, das neue EvalBoard von Atmel hat einen 32MB SDRAM chip
>drauf
>(48LC16M16A2) und ich verbaue auch SDRAMs auf meinem EPSON Grafikkarten.
>Also die wird es sicherlich noch ne weile geben. Halt nicht mehr von
>jedem Hersteller ?!?

War nur auf "Embedded Rams" bezogen. Alle anderen Hersteller liefern 
"normale" RAMS, aber dann muss man die immer paarweise einsetzen. Die 
Embedded haben die gleiche Speicherdichte in einem kleinen Gehäuse. Und 
da haben die Hersteller die 3,3V Typen abgekündigt. Deshalb hat auch 
Atmel bei den neuen AVR32APs die Spannung für das RAM anpassbar gemacht 
(<3,3V).

Autor: Sascha Pypke (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Matthias,
dann habe ich es nicht richtig verstanden, mir ist da der Unterschied 
nicht ganz klar !?!
Kannst du mir mal ein paar typen nennen, dann schau ich mir das mal an.
Ich nutze bis jetzt immer noch die von ISSI z.B. IS41LV16100B usw.
Die haben wohl mit EPSON einen Langzeitvertrag gemacht ?!?

Gruß Sascha


PS. ich glaube ich nehme den ARM9 also AT91SAM9XE als den AV32.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unter

http://www.samsung.com/global/business/semiconduct...

Gibt es bei den Produkten "SDRAM" und "mobile SDRAM". Die unterscheiden 
sich in Betriebsspannung (jetzt fast nur noch 1,8V/2,5V - früher auch 
mal 3,3V) und Platzbedarf. Andere Hersteller haben sowas auch im 
Programm.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.