www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Neuer Microcontroller von Atmel


Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm. Wenn sie diese verkrampfte Harvard-Architektur beibehalten, dann
will ich das Teil nicht anfassen müssen.

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist ja alles nur wischiwaschi, was da so steht.

Interessant wäre doch die Architektur und der Befehlssatz.


Peter

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schade, nen AVR16-Neumann würde uns wohl mehr bringen.

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Wenn der GCC portiert wird und der Preis attraktiv ist, wieso
nicht?"


Laut Atmel wurden die Benchmarks mit dem GCC 4.01 gemacht...

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Nur welche Architektur nun genau, steht da leider auch nicht. Oder
ich
habs überlesen."

Hast Du, es ist die AVR32-Architektur...

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Laut Atmel wurden die Benchmarks mit dem GCC 4.01 gemacht..."


Hmmm, das hört sich doch schon prima an!

Autor: Andi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: FeeJai (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: romanua (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: ,,,, (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Jim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha:
"AVR16-Neumann" gibt's doch schon, nennt sich MSP430.

Autor: Thomas W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Thomas

Das hast du richtig verstanden. Ich programmiere 16-Bit DSPs mit
Harvard Architektur in Assembler und finde daran absolut nichts
Negatives.

Alex

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Ulli (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Andreas Schwarz (andreas) (Admin) Benutzerseite Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Didi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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...

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Lokko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :)

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß!

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 :-)

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"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.

Autor: Jussarian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Pototschnig (pototschnig)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: hans dieter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: embedded Besucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im April kommt bereits eine "abgespeckte" Version des AVR32

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. N. (netbandit)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Hans:

mal etwas Off Topic...
Ich kann mich da an so ein Display erinnern, was ist daraus geworden?

Autor: Markus K. (markus-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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&...
1MB Flash, 176KB RAM, 160MHz.

Autor: Frank Erdrich (erdi-soft)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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.