Hi Leute, Atmel hat nen neuen Controller angekündigt. Hört sich ganz nett an, mit seinen 32bit und (so wie es aussieht) DSP-Fähigkeit. http://www.atmel.com/products/AVR32/
Hmm. Wenn sie diese verkrampfte Harvard-Architektur beibehalten, dann will ich das Teil nicht anfassen müssen.
Ist ja alles nur wischiwaschi, was da so steht. Interessant wäre doch die Architektur und der Befehlssatz. Peter
Nunja, aber die Benchmarks sprechen für sich. Einen ARM macht der ja locker lang (wohlgemerkt ARM11, nicht diese 7er Schiene, auf der sie sich ja mit Philips bekämpfen). Wenn der GCC portiert wird und der Preis attraktiv ist, wieso nicht?
@Peter: Da gibts ne PDF mit einigen Specs. Kann sowohl RISC als auch JAVA verstehen... Nur welche Architektur nun genau, steht da leider auch nicht. Oder ich habs überlesen.
"Wenn der GCC portiert wird und der Preis attraktiv ist, wieso nicht?" Laut Atmel wurden die Benchmarks mit dem GCC 4.01 gemacht...
"Nur welche Architektur nun genau, steht da leider auch nicht. Oder ich habs überlesen." Hast Du, es ist die AVR32-Architektur...
"Laut Atmel wurden die Benchmarks mit dem GCC 4.01 gemacht..." Hmmm, das hört sich doch schon prima an!
"Hmmm, das hört sich doch schon prima an!" Das schon, aber auf dem Logo für die AVR32-Architektur ist ein BGA-Gehäuse abgebildet. Das schließt schon mal selbstgemachte Prototypen aus :( Hoffentlich kommen da noch andere Gehäuse.
Soviel zum Preis: "Prices for the 32-bit MCUs are expected to be to be comparable to those of high-end 32-bit MCUs." Also nix mit ARM7 Ersatz!
Ja, die haben für Ihn ein Linux portiert und mit dem richtigen gcc den Benchmark gemacht. Nun ist nur die Frage, ob man ihn auch ohne OS betreiben kann. MfG, FeeJai
Da ich mir schon immer meine Digitalkamera selber bauen wollte, scheint mir das Teil optimal zu sein. Ich hoffe nur, daß man dafür nicht mehr diese lästigen 3,3V benötigt; 0,7V wären mir am liebsten 1/2 AA Batterie reicht dann :-)
Du hast sorgen. Ich würde mal lieber für ein annehmbares Gehäuse beten. Laufen denn die CMOS/CCD Sensoren nur mit 0.7V?
Es gibt zwei Mikroarchitekturen, die 32A ist für die kleineren und billigeren Controller gedacht (keine Shadowregister in Interrupts und für Returnadressen). Es scheint also auch kleinere Varianten zu geben. Die kommen sicherlich auch als TQFP64 oder ähnlich. Den Markt kann Atmel sich nicht entgehen lassen.
Bin jetzt nicht der Digital-Experte, aber ich hab das immer so verstanden, dass die Havard-Struktur für ein flottes DSP Design 1. Wahl ist, da dort mehrere Operationen in einem Takt auf verschiedene Speicherbereiche angewandt werden können. Das dadurch die Programmierung unhandlicher wird ist eine andere Sache, aber der neue Controller soll ja ausdrücklich DSP fähig sein. Hab ich da was falsch verstanden? Klärt mich auf...
@Thomas Das hast du richtig verstanden. Ich programmiere 16-Bit DSPs mit Harvard Architektur in Assembler und finde daran absolut nichts Negatives. Alex
In Assembler kann man Harvard ja auch gerne haben, aber in C ist das ein Krampf im Arsch ... Man muss sich nur die zig "wie bekomme ich $irgendwas ins Flash"-Threads hier ansehen.
Hmm, dem DSP-Compiler teile ich direkt mit, wohin er die Daten legen soll (Daten- oder Programmspeicher) und damit hat es sich. Allerdings hat der auch keinen Flash sondern besteht intern komplett aus RAM. Anders wird es auch nichts mit "vernünftigen" Taktraten.
Wenn ich mich recht entsinne, hatte ick mal vor ca 1 Jahr im Studium gelernt, das DSPs alleine schon aus gründen der geschwindigkeit den Speicher separieren. Programmspeicher und Datenspeicher sind getrennte Speicher. Wenn Programm und Daten im selben Speicher liegen würden, würde die arbeit des Programms durch zugriffe auf die Daten sich selber behindern und umgekehrt. Logisch ist dann also eine trenung von daten und programmspeicher. Das beide Speicher RAMs sind ist eine andere Sache, es ist aber immernoch eine Harvard-Architektur. CA
Hallo wenn ich mich mal mit einmischen darf... errinnert ihr euch noch an den guten alten 80c51 und seiner Neumann Architektur? 12 Takte hat der gebraucht und dazu musste noch jedes Byte durch den Akku hin und her geschickt werden ;-) ..finde ich schon ganz gut so mit dem Avr Harvard System. Dazu kommt bei dem hier, soweit ich es eben mal überschaut hab, das noch als 7 fache Pipeline ausgelegt ergo müssten dadurch auch bis zu 7 Befehle gleichzeitig ausgeführt werden können also fast wie bei einen Dsp - oder liege ich damit falsch? Frage @ Rufus: Wo ist das Problem, dafür etwas in C oder Asm zu schreiben und wieso muss ich (so wie ich das verstanden habe) etwas in der Programmausführung ins Flash schreiben? <- darin steht bei mir normal das Programm und keine Variablen. mfg Ulli
RAM-Variablen wollen anders behandelt werden als ROM-Konstanten, das nervt besonders in C. Dass der Ur-8051 12 Takte pro Befehl braucht hat mit Neumann <-> Harvard nicht viel zu tun, es gibt auch aktuelle Varianten mit 1 Takt pro Befehl.
"Dazu kommt bei dem hier, soweit ich es eben mal überschaut hab, das noch als 7 fache Pipeline ausgelegt ergo müssten dadurch auch bis zu 7 Befehle gleichzeitig ausgeführt werden können also fast wie bei einen Dsp - oder liege ich damit falsch? " Hmmm, also mein Pentium4 (Extreme Edition) hat eine Pipeline von 31 Stufen, ist aber nix DSP...
Hi Wenn der Compiler ordentlichen Support für Harvard bietet dann ist das eigentlich die Architektur der Wahl wenn man nicht gerade self-modifying Code schreiben will. Aber sowas tut man eigentlich nicht mehr. BTW: Auch von-Neumann Maschinen wie die aktuellen x86er arbeiten auf der Stufe des L1-Cache mit einer Harvard-Architektur. Das bringt natürlich etwas Verwaltungsaufwand mit sich aber zumindest im Bereich der PC-, Workstation- und Serverprozessoren spielen die paar zehntausend Transistoren bei megabyteweise Cache auf dem Chip keine Rolle. Matthias
"Auch von-Neumann Maschinen wie die aktuellen x86er arbeiten auf der Stufe des L1-Cache mit einer Harvard-Architektur." Leider sind diese Begriffe ziemlich zweideutig. Die klassische Bedeutung bezieht sich auf die Anzahl der Busse (implementation architecture). Wie man an den PC-Prozessoren sieht, ist das jedoch für jeden ausser den Chipdesignern völlig bedeutungslos (386=Von-Neumann, 486=? [1 Cache aber 2 Busse], Pentium=Harvard). Ich ziehe es vor, diese Begriffe auf die Anzahl Adressräume zu beziehen (instruction set architecture). Um diese Problematik auf die Spitze zu treiben hat Mitsubishi den M16c erfunden. Technisch in beiden Interpretationsvarianten weitgehend eine Von-Neumann-Architektur, hat man freilich beim Programmieren mit den gleichen Beschränkungen wie bei Harvard-Architekturen zu kämpfen (verschiedene Zugriffstechnik). Und der bzgl. Architektur exakt gleiche R8c ist hingegen mustergültig Von-Neumannsch.
"Wenn der Compiler ordentlichen Support für Harvard bietet dann ist das eigentlich die Architektur der Wahl wenn man nicht gerade self-modifying Code schreiben will" ...und man kein gesteigertes Interesse an portablem Code hat. Denn die Klimmzüge, die der Compiler dafür treiben muss, sehen bei jedem irgendwie anders aus. Wobei das natürlich bei Programmen auf unterster Ebene egal ist. Wer die Bits eines Controllers anspricht, ist ohnehin an den Controller-Typ gebunden, und wenn er sich dann auch noch an den Compiler bindet, ist das allenfalls auf sehr lange Frist störend. Aber je grösser Programme werden, desto geringer ist der Anteil gerätespezifischen Codes darin. Und desto grösser der Ärger mit unterschiedlichen Speicherklassen, verschiedenen Stringfunktionen dafür, usw.
Hab den AVR32 heute auf der embedded world gesehen. Hat mal eben fein Ice Age MPEG4 decodiert :) Laut MSC kommen wohl erst die Varianten ohne Flash etc. auf den Markt und dann für 9 wenn man EINIGE abnimmt. Auf der Messe war nur ein Developmentboard mit BGA zu bestaunen. Und wie der Herr von MSC gesagt hat, verfügbar wohl Ende des Jahres. Wer wie ich auf die AT91SAM7X Reihe wartet und Atmel schon was länger kennt, denkt sich schon seinen Teil. Zum Basteln wird das wohl nix werden. Aber wer sich so ein Dingen antun will, der kann sich jetzt auch schon auf nen XScale stürzen. :)
In dem Schrieb, den die verteilt haben, stand etwas von "Produktion läuft im zweiten Quartal an", aber das glauben sie wohl selbst nicht. Und über die Architektur des AVR ärgert sich schon, wer ein paar flexible Debugroutinen schreiben will (geschweige denn einen Interpreter). Wenn es wenigstens etwas RAM im Befehlsadreßraum gäbe, könnte man sich behelfen, aber dauernd temporäre Befehle flashen, das kann es nicht sein. Und genügend Controller beweisen, das es nicht sein muß!
L1 cache hat mit Harvard nichts zu tun! Ob Harvard oder Neumann sieht man in erster Linie daran, dass der Speicherbereich für Code und Daten getrennt ist oder nicht. Der L1-Cache hat damit garnichts zu tun, weil der von beiden Architekturen nicht definiert wird. Zum DSP: Viele DSPs haben mehrere getrennte Speicher, z.B. 1 Bus für's Programm, 2 Busse für Daten. "DSP-Befehle" bedeuten noch lange nicht, dass man mehrere Busse haben muss, oder die Architektur Harvard ist. Das bedeutet nur, dass "DSP-ähnliche" Befehle zur Verfügung stellen. DSP-Befehle sind z.B. für Faltungsoperationen, transformationen usw... hervorragend geeignet und stehen normalerweise auf normalen nicht-DSP-Plattformen so nicht zur Verfügung. Und jetzt zur Pipeline: Eine 7-stufige Pipeline bedeutet nicht, dass 7 Befehle "gleichzeitig ausgeführt werden können". Vielmehr bedeutet das, dass eine Befehlsausführung in 7 Teilschritte zerlegt wird und in jedem Teilschritt müssen weniger Aufgaben erledigt werden. Dadurch lässt sich die Taktfrequenz deutlich erhöhen. Tatsache ist, dass aber 7 Befehle gleichzeitig bearbeitet werden - es sieht aber für den außenstehenenden so aus, dass in jedem Taktzyklus 1 Befehl ausgeführt wird. Der Pferdefuß an einer Pipeline ist, wenn unvorhergesehen Sprünge im Programmcode vorkommen (bedingte Sprünge), denn dann muss die Pipeline komplett ausgeleert und neu aufgefüllt werden, was (relativ) lange dauert (=> enormes Problem beim P4 mit >30 Stufen!!). Der AVR32 soll aber (laut vorläufigem Datenblatt) eine recht gute Branch-Predict-Unit integriert haben, die zero-cycle-branches ermöglicht. Das sollte theoretisch einen recht guten Geschwindigkeitsvorteil bringen.
Abgesehen von der Architektur soll der neue controller big endian werden wenn ich das richtig verstehe - PCs sind doch little endian oder? - da wird die Ansteuerung von Speichermedien ziemlich problematisch denke ich mal. Ich glaube die neuen controller werden absolut nicht bastler-freundlich
@Lupin: Ja - der AVR32 ist BigEndian. Aber Probleme gibt's deswegen kaum. Daten, die aus Bytes bestehen bleiben unverändert. Genauso wie Strings oder ähnliches. Das Einzige was sich ändert ist die Byte-Reihenfolge in einem 16- und 32Bit Datum (WORD, DWORD). Aber darum braucht man sich normalerweise nicht zu kümmern, weil das ja der Compiler für einen erledigt. Hier und da muss man schon etwas aufpassen. Aber "ziemlich problematisch" würde ich das wirklich nicht nennen. Zum 2ten: Da bin ich mir nicht so sicher. Es soll laut dem Datenblatt mehrere AVR32-Varianten geben. Den AVRA, der eine abgespeckte Version darstellt und den AVRB. Der AVR-AP, der alles hat, ist die erste Version vom AVRB. Vorhin hat jemand das PDF zum AVR32 gepostet, da steht's nochmal drin. Ich könnte mir aber vorstellen, dass es vom AVRA kleinere, bastlerfreundlichere Devices gibt. Aber das weiß bis jetzt leider noch niemand. Auf der Embedded World hatte ich mich mit jemandem von Atmel unterhalten und der meinte, es wird welche mit und ohne Memory-Interface geben, also auch Flash-Based. Die Informationen natürlich ohne Gewähr :-)
"Hilfe! BigEndian!" Also ebenso wie PowerPC, HPPA, ARM, Alpha, Sparc, 68000 usw (ja, ich weiß: teilweise lassen die sich auch auf LittleEndian umstellen, aber nur teilweise). Jetzt wird also schon der Normalfall zum Nachteil erklärt? Gibt es außer x86 überhaupt eine Architektur, die nur LittleEndian kann? Wer damit Probleme hat, hat unsauber programmiert (beliebt: Konfigurationsarray mit Integern bytesweise ins Eeprom schreiben. So ein Code ist natürlich nicht mehr transportabel). Wer sich an die Regeln hält und nicht gedankenlos mit unions jongliert, merkt nichts davon. Atmel weiß genau, was die Kunden am AVR schätzen und wird das nicht über Bord werfen. Also: freudige Erwartung.
wie schon erwähnt, in der Pipeline werden keine Befehle gleichzeitig abgearbeitet. Die Pipiline dient zur vorrausschauenden Befehlsabarbeitung, wie dies für Branch-Predict und zero-cycle-branches notwendig ist. Damit ist aber bei Software-Zeitschleifen keine exate Zeitbestimmung möglich. Das bei bestimmten Befehlskombinationen die Pipline gelöscht wird, wäre ein Rückschritt. Beim Infineon XC161CJ ist mir dieses Verhalten nicht bekannt.
@Jussarian: "vorausschauende Befehlsabarbeitung" ist etwas irreführend. Das hört sich so an, als wärst du der Meinung die Pipeline ist nur dazu da, um vorausschauen zu können wo als nächstes hingebrancht wird. Der AVR32 hat einen eigenen Buffer drin, in dem "protokoliert" wird, wie die letzten Sprünge waren. Und aus diesem Wissen entscheided er dann, in welchem Pfad er weiterarbeitet. Ist die Annahme falsch, muss die Pipeline geleert werden und er macht im richtigen Zweig weiter. (Siehe AVR32-AP.PDF) In dem Punkt gebe ich dir recht. Exakte Zeitbestimmt wird nicht funktionieren. Das Branch-Predict-Feature ist vollständig unsichtbar für den Programmierer. Der Programmierer merkt davon nichts. Wenn der Prozessor/MC den nächsten Branch richtig voraussieht, dann arbeitet er einfach weiter. Irrt er sich aber, z.B. weil eine Schleife beendet wird, dann muss er die Pipeline ausleeren und sie wieder auffüllen. Du kannst gerne hier nochmal nachlesen: http://de.wikipedia.org/wiki/Pipeline-Architektur
auf der embedded habe ich folgendendes beim stand von atmel gesehen: - also der soll einen I- und D-Chache haben (also interne harvard, wie bei allen heutigen schnellen prozessoren) - neben bga und mlf soll es auch tqfp48 (+) varianten geben
Gibt es denn schon ein richtiges Datenblatt? Ich meine, wenn ein schneller Controller bastlerfreundlich sein soll, dann sollte er zumindest PLL haben, denn ein schneller externer Quartz ist keine so tolle Sache. Wie groß groß soll der Flash- bzw. RAM-Speicher sein?
irgendwie kann ich mir beim besten willen nicht vorstellen, dass sich atmel selbst konkurenz für einen chip macht.. wollten die nicht jetzt mal den sam7x oder wie das teil heißt mit ethernet releasen? für meinen teil klingt das doch irgendwie ähnlich.. wobei dieser "arm32" eher arm9 kaliver hat wie sich das so anhört... btw hans dieter... instruction und datacaches haben nix mit schnellen prozessoren zu tun.. du kannst nur keinen externen ram mit 1Ghz ansprechen ;) aber du kannst ja mal versuchen auf nem p4 oä. random ramzugriffe zu machen.. da freut sich die performance ;) die solln mal ein ding mit 256k ram und 256k flash oder so machen... das wär wirklich nett.. eigentlich würden schon 64k flash genügen... da braucht nur ein loader platz haben der mir von ner mmc das prog in den ram läd... och wär das schön ;) ein richtiger netter debugger :D oder aber sdram auch auf dem kleinsten der familie... 73
Hi >Exakte Zeitbestimmt wird nicht funktionieren. Natürlich kann man das (theoretisch) machen. Das was der Prozessor macht ist immer noch eindeutig bei gegebener Befehlsfolge. Das das aber dermaßen komplex ist das man das nicht (praktisch) machen will ist eine andere Geschichte. >du kannst nur keinen externen ram mit 1Ghz ansprechen <nitpickmode=on> Das erzähl mal Firmen wie nVidia und ATI. Die fahren ihre Speicher mit knapp unter 800MHz DDR. Da ist man nicht mehr weit weg von 1GHz echtem Takt. Noch extremer geht es bei Rambus zur Sache. <nitpickmode=off> Das Problem sind nicht die Transferraten. Ein P4 kann keinen Instruktionsstrom von sechs GByte/s verarbeiten. Es sind viel mehr die Latenzen. Die sind beim externen Speicher natürlich wesentlich größer als bei L2 oder sogar L1-Cache. Matthias
@Hans: mal etwas Off Topic... Ich kann mich da an so ein Display erinnern, was ist daraus geworden?
@Hans: "die solln mal ein ding mit 256k ram und 256k flash oder so machen... das wär wirklich nett.." Du meinst sowas? http://eu.renesas.com/fmwk.jsp?cnt=32192_root.jsp&fp=/products/mpumcu/m32r_family/m32r_ecu_series/32192_group/ 1MB Flash, 176KB RAM, 160MHz.
Hab das Teil gestern auf der Embedded World gesehen. Schaut schick aus. Und dekodiert MPEG4 tatsächlich ohne ruckeln in QVGA-Auflösung. Allerdings weiß ich nicht, mit wieviel MHz der gelaufen ist. Was BigEndian angeht, so ist das kein Problem. Irgendwo stand was von wegen Konvertiereinheit von Big in LittleEndian. Kann im laufe des Tages näheres Posten, wenn ich die Datenblätter mal näher gesichtet habe.
Naja, im PR-Material ist der Claim drin, das geht mit 100MHz, wo andere zwischen 170 und 266 MHz Takt dafür brauchen. Und die Peripherie wird gleichzeitig mit bedient. Gruss Jadeclaw.
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.