Wenn ich alles recht verstanden hab zielen AVR32 und ARM auf ähnliche Anwendungsbereiche. Was sind die Vor- und Nachteile der beiden Prozessoren?
Einfach das ganze Werbematerial bei atmel.com durchschauen, z.B. http://www.atmel.com/dyn/resources/prod_documents/doc4092.pdf Ist zwar nicht sonderlich ARM-Kritisch, schließlich wollen die weiterhin ihre eigenen ARMs verkaufen...
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.
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! ...
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
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.
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.
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)?
>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...
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.
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!
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.
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 !
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.
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_selector_guide.html
> 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.
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...
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..)
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...
@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
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.
>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).
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.
Unter http://www.samsung.com/global/business/semiconductor/products/dram/Products_DRAM.html 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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.