mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Atmel kündigt AVR XMEGA-Mikrocontroller an


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

Bewertung
0 lesenswert
nicht lesenswert

Die lange erwarteten XMEGA-Controller von Atmel scheinen langsam Gestalt anzunehmen. Auf der Atmel-Webseite sind sie seit heute erstmals unter den Produkten aufgeführt.

Die XMEGA-Reihe basiert auf dem erfolgreichen 8 Bit AVR-Kern, enthält aber einige interessante Neuerungen:

  • DMA
  • Crypto-Engine für AES und DES: einfach Key und Daten in Register schreiben, der Rest läuft automatisch
  • Event-System: ähnlich Interrupts, aber für die Kommunikation zwischen Peripherieeinheiten ohne CPU-Beteiligung

Die Speicherausstattung ist mit bis zu 256 kB Flash und 16 kB RAM ähnlich wie bei den ATmegas, dazu kommen bis zu 8 UARTs, mehrere bis zu 2 MS/s schnelle 12 Bit AD- und DA-Wandler sowie 8 Timer. Für Bastler gibt es allerdings eine schlechte, wenn auch nicht überraschende Nachricht: es sind keine 5 V-kompatiblen Modelle angekündigt (die spezifizierte Betriebsspannung ist 1,6 bis 3,6 V), DIL-Gehäuse sucht man ebenfalls vergeblich.

Mehr Informationen gibt es auf der XMEGA-Webseite von Atmel und im ATxmega Manual.


Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit den 5V ist natuerlich bloed... :( Gerade wenn man mit 
CMOS-Bausteinen arbeiten will, fuer die 5V eigentlich schon bald zu 
wenig ist. Aber ansonsten sind die Dinger echt heiss. Leider hab ich nen 
Foliensatz gesehen auf dem Stand dass mit Massenprodukltion fruehestens 
im Q1 2009 angefangen wird. Fuer Q1/Q2 2008 sind lediglich Samples 
beziehbar. Die ganz grossen Modelle mit mehr als 64 Pins sind uebrigens 
nur im BGA-Gehaeuse erhaeltlich.

Michael

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael G. wrote:
> Fuer Q1/Q2 2008 sind lediglich Samples beziehbar.

Theoretisch. Praktisch eher nicht, zumindest für Normalkunden. Zumindest 
wurde mir das am Atmel Stand auf der Embedded World gesagt.
Preislich sollten die ein kleinwenig über den vergleichbaren ATmegas 
liegen, die dann zunehmend auslaufen.

Erhältlich sollen die ab Mitte 2008 sein. Ich rechne aber eher mal mit 
Ende 2008.

Nett finde ich auch die mit 128MHz laufende Peripherie.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael G. wrote:

> Die ganz grossen Modelle mit mehr als 64 Pins sind uebrigens
> nur im BGA-Gehaeuse erhaeltlich.

Laut der Webseite gibt's neben CBGA100 immer noch TQFP100.  Irgendwie
muss man die Teile ja schließlich auch in den STK600 reinstecken
können...

TQFP100 ist zwar mit 0,5-mm-Raster nicht gerade das allerbastler-
freundlichste auf der Welt, aber zumindest keine Änderung gegenüber
den derzeit größten ATmegas (ATmegaXXX0) und hobbymäßig schon noch
beherrschbar.

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab gerade nen 144pinner Verlötet, alles im Rahmen des möglichen, 
die Platine war allerdings gefertigt.

Ich freue mich auch schon sehr auf die Controller :D

DMA und  Eventsystem finde ich besonders Interessant, auch im Bezug auf 
den schnellen ADC. Von den vielen Timern brauch ich garnicht erst 
anfangen zu schwärmen :D

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es von den AVR XMEGA wirklich kein einziges Exemplar mit USB?

Wäre wirklich schade.

Gruß

Stefan Salewski

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt wahrscheinlich auch noch kein einziges Exemplar ohne USB zu 
kaufen.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und, dass es kein Ethernet gibt, stört mich auch noch ein wenig ;)

Autor: Marc Seiffert (eurofighter) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Kaiser wrote:
> Es gibt wahrscheinlich auch noch kein einziges Exemplar ohne USB zu
> kaufen.

DIE aussage musst du mir erstmal erklären !

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc Seiffert wrote:

> DIE aussage musst du mir erstmal erklären !

Siehe Benedikt. Bis die jetzt angekündigten Varianten verfügbar sein 
werden, wird noch einige Zeit ins Land gehen. Bis dahin gibt es also 
weder welche mit USB noch welche ohne USB.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
USB und Ethernet kommen warscheinlich noch (laut Atmel Stand auf der 
Embedded)

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Kaiser (a-k) schrieb am 26.02.2008 um 17:06 Uhr:

>Es gibt wahrscheinlich auch noch kein einziges Exemplar ohne USB zu
>kaufen.

Falls das gegen meine Frage geht:
>Gibt es von den AVR XMEGA wirklich kein einziges Exemplar mit USB?

Von "kaufen" habe ich nichts geschrieben. "Gibt" bezieht sich auf 
angekündigte Exemplare oder Samples -- die es dann hoffentlich 
irgendwann auch zu kaufen geben wird.

Ich spalte ja manchmal auch gerne Haare, aber nicht in Nanopartikel.

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. (benedikt) schrieb am 26.02.2008 um 17:18 Uhr:

>USB und Ethernet kommen wahrscheinlich noch (laut Atmel Stand auf der
>Embedded)

Eine interessante, aber von Seiten Atmels leider sehr vage Aussage.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mich amüsiert halt die Begeisterung etwas, mit der sich viele auf alles 
stürzen was neu ist, bloss weil es neu ist und alles was neu ist 
unbedingt immer zwangsläufig viel besser sein muss als alles bekannte. 
Der HABEN MUSS!!!!! Effekt ;-)

PS: Bei Controllern ist man deutlich besser dran, wenn man nicht der 
Erstkunde ist, sondern anderen bei der Fehlersuche den Vortritt lässt.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja also der IS ja auch wirklich um einiges "besser" als die jetzigen 
Megas... ;) Und klar muss ich den haben hehe...

Autor: Oops (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Benedikt:

>den vergleichbaren ATmegas liegen, die dann zunehmend auslaufen.

Vermute ich richtig, das das auch eine Aussage von der Embedded war?
Haben die irgendeinen Zeitpunkt genannt? Oder wann welche Modelle 
auslaufen?

Ist ein bischen blöd, da ja dann alle Entwicklungen dafür irgendwann für 
die Katz' sind.

Gruss
Oops

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. wrote:

> Preislich sollten die ein kleinwenig über den vergleichbaren ATmegas
> liegen, die dann zunehmend auslaufen.

Wenn Atmel tatsächlich signalisiert haben sollte, dass die bestehenden 
Linien in wenigen Jahren eingestampft werden, dann wünsche ich Atmel 
eine gute Nacht. Denn damit würden sie sie allen vom Volumen her 
signifikanten Kunden signalisieren, dass man besser heute als morgen 
eine andere zeitlich stabilere Plattform suchen sollte, also sowohl um 
die alten als auch die neuen AVRs einen Bogen machen sollte.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oops wrote:

>>den vergleichbaren ATmegas liegen, die dann zunehmend auslaufen.
>
> Vermute ich richtig, das das auch eine Aussage von der Embedded war?

Ja.

> Haben die irgendeinen Zeitpunkt genannt? Oder wann welche Modelle
> auslaufen?

Nein. Die haben nur gesagt, dass die XMEGAs dann die normalen ATmegas 
etwas verdrängen sollen, die dann langsam zurückgehen. So habe ich das 
zumindest verstanden.
So wie Atmel aber bisher gefahren ist, wird es aber 1. lange dauern, und 
2.  irgendeinen Ersatz geben, der zumindest großteils kompatibel ist. So 
war es ja auch bisher bei den Classic AVRs.
Ich denke also nicht, dass Atmel in nächster Zeit die alten AVRs 
komplett aufgeben wird, langfristig dagegen schon (wie bei allen 
Hersteller werden die 5V Bauteile irgendwann ausgemustert, notfalls über 
einen steigenden Preis.)

Autor: Oops (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Benedikt

Verstehe. Dankeschön.
Werde vielleicht doch noch zur Embedded fahren und auch mal mit den 
Atmel-Leuten reden.

Gruss
Oops

Autor: D. W. (dave) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klar, ich hab auch den "Haben-Wollen-Effekt" bei mir festgestellt.

Für was braucht man bitte die Krypto-Engine? Ich könnte mir kein Produkt 
vorstellen, bei dem man ein XMEGA benutzen würde und größere Datenmengen 
zu verschlüsseln hätte.
MP3-Player: Der AVR wird wohl zu schwach sein MP3s alleine zu 
dekodieren.
Kleinere Geräte mit wenig Speicher: die können auch grad noch in 
Software en/dekodieren.
Festplatten-Controller mit AVR: trotzdem zu laaaangsam...

Habt ihr da ne Idee?

Autor: Joerg Wolfram (joergwolfram)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vieleich haben die sich das bei M$ abgeschaut und man kann dann nur noch 
zertifizierte Hardware mit DRM an die Ports anschliessen ;-)

Gruß Jörg

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. wrote:

> wie bei allen Hersteller werden die 5V Bauteile irgendwann
> ausgemustert, notfalls über einen steigenden Preis.)

Die Originalfabrikation vom ab 1971 produzierten NE555 wurde erst 2003 
eingestellt, und auch das nur weil die letzte zur Fertigung geeignete 
Fabrik abgebrannt war und beliebig viele Zweithersteller existierten.

Autor: FBI (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

laut Atmel Webseite sollen die ATxmega128A1 und ATxmega64A1 ab sofort 
verfügbar sein ("available now"). Preis: US$3.75/3.50 ("10k unit 
price").

Die Krypto-Engine soll wohl bis 2Mbps schaffen, Atmel selbst gibt als 
Anwendungen z.B. "toll road tags, wireless sensor nodes and ZigBee" an. 
Außerdem wurden AVRs ja auch bisher schon auf Smart-/Chip-Karten 
eingesetzt. Da ist eine Krypto-Engine sicher auch interessant.

CU

Autor: jörg (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

die Xmegas sind schon rictig gut bis 16mb externen ram.
leider fehlt wieder mal die doku wie man auch nur 1Byte extern 
anschließen soll.


kurzer auschnitt der aktuellen pdf des ATxmega256A1.


4.9 External Memory
XMEGA has up to 4 ports dedicated to External Memory, supporting 
external SRAM, SDRAM,
and memory mapped peripherals such as LCD displays or other memory 
mapped devices. For
details refer to the External Bus interface (EBI) description. The 
External Memory address space
will always start at the end of Internal SRAM.



gruß jörg

Autor: Oops (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gab's denn auf der Embedded schon Muster von ATxmega128A1 und 
ATxmega64A1?

Dieses AWEX-Modul mit einstellbarer Totzeit finde ich auch nützlich für 
Motorkontrolle usw.

Gruss
Oops

Autor: Willivonbienemaya .. (willivonbienemaya)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
FBI wrote:
> laut Atmel Webseite sollen die ATxmega128A1 und ATxmega64A1 ab sofort
> verfügbar sein ("available now"). Preis: US$3.75/3.50 ("10k unit
> price").

Ich war auch auf der Embedded World. Die Teile sind echt noch nicht 
erhältlich. Es sind nur erste Muster im TQFP100 für das STK600 existent.

Autor: Oops (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab nur mal kurz gegoogelt, konnte aber kein STK600 zu kaufen sehen.
Kennt jemand einen Laden in dem man das bekommt?

Gruss
Oops

Autor: Oops (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, hätte vielleicht ein neuer Thread sein sollen.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oops wrote:
> Gab's denn auf der Embedded schon Muster von ATxmega128A1 und
> ATxmega64A1?

Ja.
Ein STK600 war das glaube ich mit einem LCD drauf und ein paar Tastern 
und LEDs. Daneben ein zweites. Beide über TWI verbunden. Auf Tastendruck 
wurde eine codierte Message übertragen, dekodiert und die entsprechende 
LED angesteuert.

Dann war noch ein kleines Board da, das von einer SD Karte glaube ich, 
Wave Files über den internen DAC abspielte.

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich war heut auch auf der Embedded und da sagte man mir, bei den 
ATmegaXXX ist kein Auslaufen geplant, sondern die ATXmega werden 
ungefähr im selben Preissegment wie die jetzigen großen Megas sein und 
diese ein wenig im Preis nach unten drücken; Aussage war: Mehr Leistung 
zum gleichen Preis.

Gute Nacht
Wolfgang

Autor: Peter T... (peter_vals)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
cool. gerüchte gibt es ja schon lange. mit einer taktfrequenz von 32MHz 
wird die "rechnerische" leistung eigentlich in etwa verdoppelt. obwohl 
ich noch nie an der grenze eines avrs war finde ich das ziemlich 
interessant.

weiss jemand etwas genaueres über die programmierung? über die 
C-Programmierung gibt es nun eine doku auf der atmel site. Aber wie 
sieht es aus mit Assembler??? ich habe im datenblatt auch keine 
assemblerbefehle gefunden?!?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ATmega2560: 135 Befehle.
ATxmega A: 135 Befehle.
Beantwortet das deine Frage?

Autor: Peter T... (peter_vals)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
135 = 135

also in etwa das selbe!?!

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja. Bei dem Infomaterial das ich mitgenommen habe, steht: Pin und 
Softwarekompatibel zu den ATmegas.

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was mir noch gesagt wurde, ist:
1. angeblich ist die gnu-tool-chain schon fertig, soll demnächst 
veröffentlicht werden
2. AVR-Studio ist angeblich auch schon fertig, soll auch bald raus 
kommen
3. Atmel will einen eigenen Shop für die Entwicklungstools eingerichtet 
haben, nur da finde ich bisher nichts auf der Seite. Wäre stark, wenn's 
dort dann die Chips auch schon in kleinen Stückzahlen für ein paar Euro 
geben würde.

MfG
Wolfgang

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Mich amüsiert halt die Begeisterung etwas, mit der sich viele auf alles
> stürzen was neu ist, bloss weil es neu ist und alles was neu ist
> unbedingt immer zwangsläufig viel besser sein muss als alles bekannte.

Wer rastet, der rostet!

Autor: Anonymous (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Solange Atmel keine normalen DIL ICs anbietet werden die sich das Teil 
von meiner Seite aus in den A. schieben können.

Autor: Joachim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Solange Atmel keine normalen DIL ICs anbietet werden die sich das Teil
> von meiner Seite aus in den A. schieben können.

..sprach der Dinosaurier - und starb aus :)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anonymous wrote:

> Solange Atmel keine normalen DIL ICs anbietet werden die sich das Teil
> von meiner Seite aus in den A. schieben können.

Meinst du, ein anonymer Hintern interessiert irgendeinen Halbleiter-
Hersteller?

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Wolfgang:
>1. angeblich ist die gnu-tool-chain schon fertig, soll demnächst
>veröffentlicht werden


Wenn der Befehlssatz gleich ist, dann ist die toolchain natürlich 
fertig.
Hat sich ja nix geändert.
Nur die Startup- und Header-Files müssen ergänzt werden.

Autor: Anonymous (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jörg:
Naja, wenn Atmel die Hobbyisten weglaufen haben die auch ein Problem.

Autor: Marc Seiffert (eurofighter) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ anonymer Hintern

meinst du ? das wir paar Hobbybastler für Atmel das große Geschäft 
darstellen ? Die Aabsatzquoten durch Hobbybastler bewegen sich doch 
HÖCHSTENS im einstelligen %-Bereich, da überlegt sich die Fa. Atmel 
sicher 2 mal ob sie wirklich speziell für uns angepasste Produkte 
rausbringt. Vor allem wenn man bedenkt, das unter den Hobbybastlern 
wiederrum auch ein großteil mit SMD-Bauteilen sehr zufrieden ist, bzw. 
diese sogar präferiert (ich baue nur noch ab und an THT um alte Bauteile 
loszuwerden ;) )

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eben. Wieviele Hobbyisten können denn mittlerweile nicht schon SMT 
löten?
Doch nur eine Handvoll Stümper.
SMT ist doch viel praktischer. Umso schöner, wenn der anonyme Hobbyarsch 
die Atmels dann drangibt ;)

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc Seiffert wrote:
> Vor allem wenn man bedenkt, das unter den Hobbybastlern
> wiederrum auch ein großteil mit SMD-Bauteilen sehr zufrieden ist, bzw.
> diese sogar präferiert (ich baue nur noch ab und an THT um alte Bauteile
> loszuwerden ;) )

Eben... geht mir genauso. Solange die Pitches nicht so fein werden, dass 
man das Layout nicht mehr hinbekommt oder von grossen BGAs die Rede ist, 
die man nur mit Multilayer besiegen kann, ist es doch vollkommen OK. Ich 
komme mit QFP und sogar SSOP-Packages eigentlich wunderbar zurecht. Der 
Platzgewinn ist doch auch enorm.

Autor: Jojo S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
die Bastler und Studenten von heute sind die Ingenieuere von morgen, ich 
glaube nicht das Atmel keinen Wert auf diese Gruppe legt. Aber an SMD 
Bauform soll es doch nun wirklich nicht liegen, per Adpater oder als 
fertiges CPU-Modul kann man solche Prozessoren immer noch einsetzen. 
Gerade die Module sind interessant weil man da ja z.B. heute schon 
ARM+viel Ram+viel Flash draufbekommt in Grösse etwa eines DIP40 
Gehäuses.
Interessanter finde ich die (hoffentlich noch bald kommenden) Megas mit 
integriertem USB, Ethernet oder CAN. Gerade wo heute alles vernetzt wird 
braucht man einfache und billige Lösungen. Geht natürlich schon mit 
Mega+Enc28J60, aber eine integrierte ein-Chip Lösung wäre da schon 
smarter.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer am Werkzeug und am Lernen spart, sollte nicht über kleine 
IC-Bauformen herziehen, die noch dazu viel praktischer sind. Solange da 
immer noch Pins dran sind, ist die Welt doch in Ordnung.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mike wrote:

> Hat sich ja nix geändert.
> Nur die Startup- und Header-Files müssen ergänzt werden.

Naja, der Compiler leider auch.  Hat sich doch bisschen mehr geändert,
bspw. sind jetzt die IO- und MMIO-Adressen gleich (nicht mehr mit
Offset 0x20), weil man das Einblenden der CPU-Register in den RAM-
Adressraum aufgegeben hat.  Außerdem, wenn ich es recht gesehen habe,
können einige der Xmegas mehr als 64 KiB RAM adressieren.

Eric Weddington arbeitet da seit einiger Zeit dran, und Anatoly
Sokolov ist ebenfalls involviert.

Autor: Paul Baumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Doch nur eine Handvoll Stümper.
Es heißt SMD. Das zum Stümper.

Auch Du wirst einmal Schwierigkeiten bekommen, mit den SMD-Bauelementen
umzugehen, wenn Du ein gewisses Alter überschritten hast.

Paul

Autor: Johannes M. (johnny-m)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Paul Baumann wrote:
>>Doch nur eine Handvoll Stümper.
> Es heißt SMD. Das zum Stümper.
SMT ist der Oberbegriff (Surface Mount Technology), SMD bezeichnet die 
Bauteile an sich (Surface Mounted Device(s))...

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Der Platzgewinn ist doch auch enorm.

Ich sehe im privaten Umfeld eigentlich keinen so grossen
Platzgewinn. Dadurch das man nur schlecht zwischen zwei
Beinen routen kann verliert man auch wieder was.

Allerdings braucht man keine Loecher mehr in seine Platinen
zu bohren. Lustigerweise setze ich deshalb privat zu
100% SMD ein, und in der Firma bei kleinen Stueckzahlen noch
bedrahtet weil das von der Bestueckung besser ist.

Schoen ist es auch das mal schlichte Design auch komplett einseitig
hinbekommt, oder auf dem Bottom-Layer nur ein paar Leiterbahnen hat.
Da kann man die Platine auch schonmal einfach irgendwo dran kleben.

Im uebrigen, 32Mhz und externes Ram? Wir dringen da langsam in
Bereiche vor wo SMD wirklich dringenst empfohlen werden muss. .-)

Olaf

Autor: Marc Seiffert (eurofighter) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Olaf

also bei z.B. nem DIL20 auf nen SO20 ist tatsächlich nur ein kleiner 
Platzgewinn vorhanden...der Unterschied zwischen DIL28 und TQFP32(Mega8) 
ist dagegen enorm. Ich kann dir gerne layouts schicken die das 
einwandfrei Belegen ;) Ausserdem ist es arg Vorteilhaft, wenn man auf 
der Rückseite SMD-Bauteile hat und auf der Vorderseite nur die stecker 
u.ä. ;)

ansonnsten, manchmal wenns schnell gehen soll oder ich eh Platz ohne 
ende habe ist THT ja auch ganz praktisch, geht flott aufgebaut und ist 
weit leichter zu "debuggen"....auf nem THT-Board kann man praktisch 
alles nochmal neu verdrahten, auf nem SMT nicht...aber eigentlich sollte 
das layout ja eh Fehlerfrei sein wenn denn mal realisiert wird ;)

Gruß, Marc

Autor: Jadeclaw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und hier kommt der große Vorteil von THT zum Tragen --> 
Steckbretttauglich. Für den ganzen SMD-Kram braucht es dann doch wieder 
Adapterplatinen.

Gruß
Jadeclaw.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jadeclaw wrote:

> Und hier kommt der große Vorteil von THT zum Tragen -->
> Steckbretttauglich.

Gut gepaart mit dem großen Nachteil von Steckbrettern: ihrer
enormen Kapazität.

Wenn du mit den Xmegas basteln willst, wirst du kaum um sowas wie
einen STK600 herum kommen (und selbst dort haben sie sicher schon
Ärger mit Kapazitäten und Leitungslängen).

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Auch Du wirst einmal Schwierigkeiten bekommen, mit den SMD-Bauelementen
> umzugehen, wenn Du ein gewisses Alter überschritten hast.

Für die Augen gibt's Brillen und Lupen, in allen erdenklichen Formen. 
Die Feinmotorik ist reine Übungssache und Training.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Olaf wrote:
>> Der Platzgewinn ist doch auch enorm.
>
> Ich sehe im privaten Umfeld eigentlich keinen so grossen
> Platzgewinn. Dadurch das man nur schlecht zwischen zwei
> Beinen routen kann verliert man auch wieder was.

Willst Du mir sagen dass Du es mit einer professionell gefertigten 
Platine schaffen willst bei einem Pitch-Abstand eines SSOP oder TQFP 
eine Leiterbahn durchzurouten? Ich glaube es mal kaum ;)

Autor: Mike J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Unbekannter (Gast)
> Für die Augen gibt's Brillen und Lupen, in allen erdenklichen Formen.
> Die Feinmotorik ist reine Übungssache und Training.

Du kennst niemanden über 50.

Mag sein dass manche das noch mit 60 hinbekommen, aber der Großteil hat 
in dem Alter mit dem nah-sehen Probleme.
Die Hände sind dann auch nicht mehr so ruhig.

Wie kommst du darauf dass das nur etwas mit "Übung" zu tun haben soll?

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Du kennst niemanden über 50.
> Mag sein dass manche das noch mit 60 hinbekommen, aber der Großteil hat

Du meinst also in zwanzig Jahren kann ich mich dann zuruecklehnen und
Berufsunfaehigkeitsrente kassieren?
Na, da bin ich aber mal gespannt. :-)

Olaf

Autor: Jorge (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
He Mike lass den Wein und das Bier und alles geht (wieder).

Autor: Oliver Keller (ozel-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe auf der eingebetteten Welt gestern mitgehört, wie ein Atmeller 
zu den anderen meinte, dass er ja so glücklich wäre, weil die XMegas im 
Demoaufbau alle noch laufen... da darf sich jetzt jeder selber denken, 
ob nur allgemein die Software oder speziell die Xmega Chips gemeint 
waren. :-)

Ansonsten habe ich sie bezüglich DebugWire Doku gelöchert und leider 
eher peinliche Ausreden gehört. Das DebugWire Protokoll soll nach wie 
vor nicht veröffentlicht werden, weil es 1. nicht gut dokumentiert ist 
(LOL) und 2. es schon genug Probleme für den Endkunden im Zusammenhang 
mit den offiziellen DebugWire Tools (AVR Dragon und JTAG ICE mkII) gäbe, 
wegen fuse Umstellung per ISP vor und nach dem Debuggen (naja...). Und 
ausserdem sei Atmel ja trotzdem nicht am reinen Toolverkauf als 
Kerngeschäft interssiert... (öööh, hä? Wie passt das zu 1. und 2.?)

Ich hatte leider den Eindruck, dass den beiden Herren alles andere als 
bewusst war, dass die Bastler von Heute u.U. durchaus die 100k 
Bestellungen von Morgen mitbestimmen...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver Keller wrote:

> Ansonsten habe ich sie bezüglich DebugWire Doku gelöchert und leider
> eher peinliche Ausreden gehört.

Willst du denn ernsthaft einen AVR Dragon selbst nachbauen?

Gerade der Bereich DebugWIRE ist doch damit erschöpfend und
preiswert abgedeckt.

> Und
> ausserdem sei Atmel ja trotzdem nicht am reinen Toolverkauf als
> Kerngeschäft interssiert... (öööh, hä? Wie passt das zu 1. und 2.?)

Das passt schon.  Sie wollen halt die Tools nur nicht völlig für
lau pflegen und unterstützen.  Gewissermaßen bezahlst du mit einem
JTAG ICE mkII außer der Hardware einen kleinen Teil der
Entwicklungskosten und eine oder zwei Stunden Support, die du
damit im Laufe der Lebensdauer des ICE früher oder später ja doch
generieren wirst.

> Ich hatte leider den Eindruck, dass den beiden Herren alles andere als
> bewusst war, dass die Bastler von Heute u.U. durchaus die 100k
> Bestellungen von Morgen mitbestimmen...

Ja, und?  Bei den 100k-Bestellungen kauft dein Chef die 10 JTAG ICEs
aus der Portokasse.  Das Einzige, was ich sehe, das Sinn hat ist,
dort (gerade im Zusammenhang mit den Xmegas) zu nerven, dass man die
Teile künftig auch mit dem AVR Dragon debuggen kann.  Die wesentlichen
Industrieanwender werden ohnehin beim JTAG ICE bleiben.  Erstens
könnte man ganz offiziell den Endkundensupport für den Dragon auf
ein Minimum reduzieren (während JTAG ICE Kunden welchen bekommen),
zweitens macht der Dragon im rauhen Laborbetrieb keinen Spaß.  Allein
die Gefahr, dass er auf Grund des fehlenden Gehäuses irgendwo einen
Kurzschluss verursacht, sollte gut die paar Hunderter für ein richtiges
ICE ausmachen, nimm noch dazu die Zeit, die man mit dem Basteln der
Kabel verbringen darf -- eine Ingenieursstunde kostet ab EUR 50
aufwärts.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um allen Gerüchten vorzubeugen, ist es wohl das beste, die Teile zu 
testen. Bin mal auf die Samples gespannt. Wenn die Teile bestehen, 
werden wir sie auch zu Hunderten verbauen :-).

Autor: Oliver Keller (ozel-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
> Willst du denn ernsthaft einen AVR Dragon selbst nachbauen?

Ich finde die Vorstellung das schön simple DebugWire günstig zu nutzen, 
trotz AVR Dragon, immernoch reizvoll:
Ein DIY Debugger, der wirklich zum günstigen Preis der kleinen Atmel und 
ATtinys passt, und damit auch zu wirklich günstigen uC 
Einsteiger-Projekten wie arduino.cc (ab 20 euro pro board).

>> Ich hatte leider den Eindruck, dass den beiden Herren alles andere als
>> bewusst war, dass die Bastler von Heute u.U. durchaus die 100k
>> Bestellungen von Morgen mitbestimmen...
>
> Ja, und?  Bei den 100k-Bestellungen kauft dein Chef die 10 JTAG ICEs
> aus der Portokasse.

Genau und ich zahl jetzt und auch in Zukunft eben nicht 10 JTAG ICEs aus 
der Portokasse für den privaten Einsatz.

> Allein die Gefahr, dass er auf Grund des fehlenden Gehäuses irgendwo
> einen Kurzschluss verursacht, sollte gut die paar Hunderter für ein
> richtiges ICE ausmachen, nimm noch dazu die Zeit, die man mit dem Basteln
> der Kabel verbringen darf -- eine Ingenieursstunde kostet ab EUR 50
> aufwärts.

Klar, da stimme ich dir gern zu! Aber für die DIY Leute könnte man doch 
wenigstens sie Schnittstellen offenlegen. Gerade wenn man (Atmel) 
annsonsten doch so schön durch AVR-GCC etc. freie Tools unterstützt.
Naja, wenn mir mal ganz arg langweilig ist, werde ich dem DebugWire im 
Oszi zuschauen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oliver Keller wrote:

> Ich finde die Vorstellung das schön simple DebugWire günstig zu nutzen,
> trotz AVR Dragon, ...

> Ein DIY Debugger, der wirklich zum günstigen Preis der kleinen Atmel und
> ATtinys passt, ...

Ich zweifle, dass du das wirklich in irgendeiner Weise nennenswert
günstiger als mit dem Dragon hinbekommst.  Ich habe ungefähr eine
Vorstellung, was debugWIRE intern macht, das ist weit mehr an
Protokoll, als man je hätte in der simplen Mimik des alten JTAG
ICEs hinbekommen hätte.

> Klar, da stimme ich dir gern zu! Aber für die DIY Leute könnte man doch
> wenigstens sie Schnittstellen offenlegen. Gerade wenn man (Atmel)
> annsonsten doch so schön durch AVR-GCC etc. freie Tools unterstützt.

Das war doch auch ein langer Weg, bis sie gemerkt haben, wie viel ihnen
das an Reputation und damit letztlich auch Akzeptanz (und schließlich
Umsatz) bringt.

Autor: Jens (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Jörg:

Darf ich mal etwas provokant fragen woher Deine Vorstellung
bezüglich DebugWire stammt?

Jens

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
> Ich habe ungefähr eine Vorstellung, was debugWIRE intern macht

Könntest du das mal grob beschreiben (falls du das darfst), bzw. weißt 
du zufällig für was der Dragon den ganzen SRAM braucht ?

Autor: Egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Andreas Kaiser Also im Xmega256a1 Manual steht was von 139 Befehlen!

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt. Also kann Atmel zwar bis 3 zählen, aber im Dreistelligen haben 
sie Schwierigkeiten. Denn das Family-Manual zu "A" Serie sagt 135, die 
Datasheets 139.

Autor: ATXMEGA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Xmega
Xgiga
Xtera

:)

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ATXMEGA wrote:
> Xmega
> Xgiga
> Xtera
>
> :)
Ne, dann hätte die jetzt neuen schon ATgiga heißen müssen. Dann wohl 
eher XXmega, XXLmega. :)

Aber mal im ernst, wenn Atmel für einen angenommenen Nachfolger wieder 
die Taktzahl verdoppelt, könnten die dann 64 und 128 MHz...

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Zukunft wird es zeigen. Wenn die XMEGAs am Markt erhältlich sind, 
wird in ATMELs Küche sicher schon der nächste Turboproz gebastelt ;-) 
32-Bit DSP mit AVR-Steuercontroller in einem Chip wäre doch geil :-))

Autor: Oliver Keller (ozel-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. wrote:
> Jörg Wunsch wrote:
>> Ich habe ungefähr eine Vorstellung, was debugWIRE intern macht
>
> Könntest du das mal grob beschreiben (falls du das darfst), bzw. weißt
> du zufällig für was der Dragon den ganzen SRAM braucht ?

Ein paar Details würden mich jetzt auch bernnend interessieren...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. wrote:

>> Ich habe ungefähr eine Vorstellung, was debugWIRE intern macht

> Könntest du das mal grob beschreiben (falls du das darfst), bzw. weißt
> du zufällig für was der Dragon den ganzen SRAM braucht ?

Jens wrote:

> Darf ich mal etwas provokant fragen woher Deine Vorstellung
> bezüglich DebugWire stammt?

Nun, ich habe die Behandlung des JTAG ICE mkII (und damit auch des AVR
Dragon) zuerst in AVRDUDE und dann in AVaRICE eingebaut, zuerst JTAG
und später auch debugWIRE.  Dabei ist die Appnote AVR067 so wenig
aussagekräftig, dass das nicht ging, ohne auch den Support von Atmel
gelegentlich zu nerven.  Außerdem muss man auch für die Benutzung
wenigstens so einigermaßen die ,,Denkweise'' des ICE verstanden haben,
sonst kommt man da nicht weit.

Wie viel von der eigentlichen Arbeit bei debugWIRE dabei im ICE und
was im Zielprozessor realisiert ist, weiß ich detailliert natürlich
auch nicht, aber es würde mich absolut nicht wundern, wenn man (zur
Kostenersparnis) im Zielprozessor praktisch nichts außer der
Kommunikationsebene implementiert hätte.  Das heißt dann, dass viele
der Debug-Aktionen einzeln als CPU-Befehle in den Befehlsdekoder
injiziert und dort abgearbeitet werden.

Für den dicken RAM habe ich zwei Ideen (wahrscheinlich treffen beide
irgendwie zu).  Erstens benutzt AVR Studio eine Art "tag memory" im
ICE, mit der sich das ICE die Grenzen der Zeilennummern der
Hochsprache merkt.  Wenn man dann im AVR Studio eine Zeile in der
Hochsprache abarbeiten will, dann wird dies direkt an das ICE
weitergegeben, das so lange Befehle ausführen lässt, bis im tag memory
eine Adresse erreicht ist, die zu einer neuen Zeilennummer gehört.
Dieses tag memory gab's zwar auch schon beim alten JTAG ICE (dort
intern im ATmega16), aber da das mkII ja von vornherein für größere
CPUs (einschließlich AVR32 und Xmega) taugen sollte, braucht man da
natürlich entsprechend mehr.

Der zweite Grund dürfte sein, dass sich das ICE ja für jeden software
breakpoint die komplette originale Flash-ROM-Seite merken muss, damit
beim Erreichen des BREAKs dann diese Seite wieder in den Zielprozessor
zurück geschrieben werden kann.  Wenn man also eine hinreichend große
Anzahl an software BPs unterstützen können will (essenziell für
debugWIRE, das ja keine hardware BPs kennt wie JTAG), dann muss man
dafür ausreichend RAM vorhalten.

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Travel Rec. wrote:
> Die Zukunft wird es zeigen. Wenn die XMEGAs am Markt erhältlich sind,
> wird in ATMELs Küche sicher schon der nächste Turboproz gebastelt ;-)
> 32-Bit DSP mit AVR-Steuercontroller in einem Chip wäre doch geil :-))
Soetwas ähnliches hat Atmel doch schon lange mit einem FPGA im Angebot.
http://www.atmel.com/dyn/products/devices.asp?family_id=627
Schade nur, das die Programmiertools kostenlos zu sein scheinen.

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Mich amüsiert halt die Begeisterung etwas, mit der sich viele auf alles
> stürzen was neu ist, bloss weil es neu ist und alles was neu ist
> unbedingt immer zwangsläufig viel besser sein muss als alles bekannte.
> Der HABEN MUSS!!!!! Effekt ;-)

Gerade als Hobbybastler ist man aber immer auf der Suche nach neuen 
Herausforderungen und leistungsfähigeren Controllern. Plötzlich werden 
Dinge möglich, an die früher nicht zu denken war. Ich für meinen Teil 
werde mir die XMEGAs jedenfalls so bald als möglich mal ansehen.

Eine Sache verstehe ich nicht ganz: Warum wechselt man nicht auf eine 
16- oder gar 32-Bit Architektur? Speicheradressierung und arithmetische 
Operationen würden dadurch massiv beschleunigt. Ich sehe einzig und 
allein das Problem, dass der Die dann ein klein wenig grösser und somit 
teurer würde.

Autor: Gast123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja das gibts doch schon -> AVR32, ARM

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mr.chip wrote:

> Gerade als Hobbybastler ist man aber immer auf der Suche nach neuen
> Herausforderungen und leistungsfähigeren Controllern.

Geht mir durchaus auch so, allerdings gilt mein Interesse eher den 
Architekturen, ich muss nicht unbedingt jedes Teil in die Finger nehmen 
und irgendwo einlöten. Vor allem wenns nicht wirklich neuartig ist - was 
bitte ist an ATxmega neu wenn man andere Architekturen kennt und nicht 
nur die alten AVRs? In mancher Hinsicht sind sie praktischer als die 
alten, aber das wars auch schon.

Ich in den AVRs eher den Ansatz für kleinere als für grössere Probleme 
und keine Konkurrenz zu 32bit Architekturen. Entsprechend skeptisch bin 
daher bei der 24bit Adressierung. Kann man machen, aber muss man das 
unbedingt mit einem 8bitter machen?

Und was mich besondern enttäuscht hat: nach wie vor kein ROM im 
Datenadressraum, d.h. die Unterscheidung zwischen Zeigern auf variable 
Daten und solchen auf konstente Daten (Strings) bleibt erhalten. Bei 
kleinen Programmen stört mich das nicht, bei grossen hingegen sehr.

> Eine Sache verstehe ich nicht ganz: Warum wechselt man nicht auf eine
> 16- oder gar 32-Bit Architektur?

Weil man die schon hat. 32bit jedenfalls. 16bit lohnt heute eher nicht 
mehr, denn der mangelnden Adressierfähigkeit wird damit nicht wirklich 
abgeholfen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Kaiser wrote:

> Und was mich besondern enttäuscht hat: nach wie vor kein ROM im
> Datenadressraum

Es sollte wohl Harvard bleiben, weil das die Parallelisierung der
Buszugriffe erlaubt.  Und naja, willst du wirklich für die
Einsparung eines Takts unbedingt den ROM zur Hälfte vorbestimmt
in Daten und Befehle getrennt haben?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das geht auch mit Harvard. Ausgerechnet Microchip macht es vor, eine 
Firma die ja, was Rechnerarchitekturen angeht, nicht wirklich für 
Geistesblitze bekannt ist. Aber bei PIC30 habe sie mal was richtig 
gemacht: In der zweiten Hälfte des 64KB Datenadressraums ist ein Teil 
vom Code-Flash eingeblendet.

Das dies hinsichtlich des internen Ablaufs nicht ganz trivial ist, ist 
mir klar. Aber der Vorteil bei der Programmierung ist in meinen Augen 
sehr wesentlich.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mir wäre es lieber, es würde sich mal jemand aufraffen, dem GCC
Speichersegmente zu lehren...  Es gibt dafür einen Standardisierungs-
vorschlag im Rahmen eines "Embedded C"-Projekts.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Kaiser wrote:
> Das geht auch mit Harvard. Ausgerechnet Microchip macht es vor, eine
> Firma die ja, was Rechnerarchitekturen angeht, nicht wirklich für
> Geistesblitze bekannt ist. Aber bei PIC30 habe sie mal was richtig
> gemacht: In der zweiten Hälfte des 64KB Datenadressraums ist ein Teil
> vom Code-Flash eingeblendet.

Die habe auch kein externes Speicherinterface wie die AVRs. Daher hat 
der AVR  für solche Spielchen garkeinen Platz.

> Das dies hinsichtlich des internen Ablaufs nicht ganz trivial ist, ist
> mir klar. Aber der Vorteil bei der Programmierung ist in meinen Augen
> sehr wesentlich.

Naja, es mindestens genau einen Krampf das passende Segment 
einzublenden, vor allem: Was machst du wenn du eine Tabelle hast, die 
größer ist als 32kByte ? Auf einem AVR kein Problem, aber bei einem 
dsPIC ?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das wäre zweifellos ein Fortschritt, erspart mir aber nicht nicht 
entsprechende Attributierung der Pointer. Was bei eigenen auf dieser 
Plattform entstandenen Programmen noch erträglich ist. Aber bei 
Fremdprogrammen, wie beispielsweise TCP/IP-Stack oder Flash-Filesystem, 
entsteht erheblicher Aufwand, wenn deren Autoren eher in der von-Neumann 
Welt leben.

Bei uIP hatte ich deshalb einen eigenen Wrapper für "universal pointer" 
implementiert. Sowas liesse sich in GCC auch innerhalb der 
AVR-Adaptierung realisieren, auf Kosten von Laufzeitfunktionen für alle 
indirekten Zugriffe.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. wrote:

> Die habe auch kein externes Speicherinterface wie die AVRs. Daher hat
> der AVR  für solche Spielchen garkeinen Platz.

Wer externen Speicher anbindet, hat das Problem meist nicht, da darin 
wird sich noch oft ein Plätzchen für konstante Daten finden. Das 
Daten-ROM liesse sich dann ausblenden.

> Naja, es mindestens genau einen Krampf das passende Segment
> einzublenden, vor allem: Was machst du wenn du eine Tabelle hast, die
> größer ist als 32kByte ?

(E)LPM will ich ja nicht verbieten. Mir geht es nicht um Monsterdaten, 
sondern um die ganz alltäglichen Strings, Menutabellen usw. Für 
spezielle Monster ist spezieller Code kein Problem.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. wrote:

> Naja, es mindestens genau einen Krampf das passende Segment
> einzublenden

Wobei Microchip das entsprechende Paging im Compiler erst neuerdings 
macht, anfangs waren es  m.W. dort nur 32KB fix. Mir würden diese 32KB 
reichen, für Code im dreistelligen KB-Bereich ziehe ich ohnehin andere 
Lösungen vor.

Autor: Ralf LK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es sieht nach wichtigen Erweiterungen im Bereich ADC unnd vor allem DAC 
aus.
Ebenso gibt es nun eine Real-Time-Clock mit 32 kHz Basistakt

Was aber völlig verwirrt sind die vielen UART - Units (7 bzw. 8).

Mir ist es ein Rätsel, was das soll. Vielleicht hat irgendein OEM mal 
bei Atmel nach einer COU mit vielen UARTs gefragt und jene sind gleich 
in Bytestärke = 8 integriert worden.
Allenfalls kann man anfangen nun viele Controller zu vernetzen ...

Das Fehlen von USB oder/und LAN ist für ein modnernes Produkt aber 
happig. Es hätte ja sogar nur teilweise in Hardware genügt, dafür etwas 
Unterstützung durch Caches.
Schließlich kommen Designs mit 256kByte Flash und 16k RAM aus der 
Fertigung und sogar nur für 68-pol. Gehäuse gedacht.
Da wäre doch Kapazität für USB und LAN verfügbar gewesen ?!

Wirklich schade ist das Fehlen einer PLCC68 Variante, obwohl ja 68 
polige Bausteine angeboten werden.
Hier wird wieder auf Adapter zurück zu greifen sein, wobei hier die 
Pinbelegung aber einheitlich sein könnte.

Die großen DIL-Gehäuse sind natürlich überholt. Aber hier Atmel ja 
Abnehmer, die nun zusehens immer weniger Umsatz ergeben, während die 
neuen Lösungen nur bestimmte Kunden anwenden.

Insgesamt ist der Versuch von Atmel die 8 Bit Linie zu modernisieren 
kläglich ausgefallen. Die Konkurrenz mit viel ADC/DAC Funktionalität 
wurde eingeholt, aber nicht ein vielseitiges Produkt geschaffen.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ralf LK wrote:

> Wirklich schade ist das Fehlen einer PLCC68 Variante,

Diese Gehäuse sind anscheinend noch exotischer als DIP, der Verbreitung 
nach zu schliessen. Wenn man sich so umschaut, sind PLCCs fast nur dort 
zu finden, wo pinkompatible Chips ihre Vorgänger von vor 20 Jahren 
ersetzen, beispielsweise bei den 8051-Derivaten.

NXP hat vor ein paar Jahren den LPC2103 in PLCC44 angekündigt, schiebt 
das aber seither immer brav vor sich her - dabei wäre das mal eine 
schöne Mega32-Konkurrenz.

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mich hat an den jetzt verfügbaren Daten zum XMega verwundert, dass die 
TQFP Gehäuse immer noch mit 0,8 mm Pitch kommen.
Das hätte bei den kleineren DIE's auch ruhig kleiner werden können.

Dann ist das ja nur der Anfang, die Familie ist ja nicht einmal komplett 
vorgestellt - es fehlen zum Beispiel A2 und A5.
Wobei - sehr clever die dicksten Typen mit A1 zu benennen.

Und dann habe ich mich auf der Embedded am Stand eines Distributors über 
die XMega's unterhalten, die ersten aus der Volumen-Produktion werden 
wohl vielleicht sogar schon im März verfügbar werden.


Die neuen CAN/LIN AVR's finde ich fast schon interessanter als die 
XMega's.
Bloss das man an die "Automotive" Teile in kleinen Stückzahlen quasi 
nicht rankommt.

Und die AVR32 UC3B sollen zumindest als Muster zu bekommen sein.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rudolph R. wrote:

> Mich hat an den jetzt verfügbaren Daten zum XMega verwundert, dass die
> TQFP Gehäuse immer noch mit 0,8 mm Pitch kommen.

Ist halt ein Standardgehäuse.  Wer klein bauen will, wird doch ohnehin
auf QFN/BGA gehen, die QFPs sind doch eher für Prototypen (und Bastler)
bzw. Dinge wie den STK600 gedacht.

0,5-mm-Raster in ZIF-Fassungen ist grässlich.  Die Dinger haben eine
beständige Neigung, dass die Pins genau zwischen die Kontaktfedern
rutschen.

Autor: Uwe ... (uwegw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die A2 sind bei Spoerle gelistet (da sind die Dinger ja schon vor 
Monaten aufgetaucht). Sollen 80 Pins haben.

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
> Ist halt ein Standardgehäuse.

Ja, und gibt es eben auch mit kleinerem Pitch, die AVR32 z.B. haben 0,5 
mm.
Und deren DICE sind wahrscheinlich nicht kleiner als die der XMega.

> Wer klein bauen will, wird doch ohnehin
> auf QFN/BGA gehen, die QFPs sind doch eher für Prototypen (und Bastler)
> bzw. Dinge wie den STK600 gedacht.

Bei wenig Pins scheinen QFN und BGA nicht so geschickt zu sein.
Denn die machen das Layout komplexer, erfordern schnell vier Lagen und 
mehr.

Die Masse-Fläche unter dem QFN bewirkt doch auch, dass man quasi nicht 
mehr nach innen routen kann. Den Vorteil des kleineren Chip verschenkt 
man also je nach Layout durch eine grössere Freifläche um diesen.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Was aber völlig verwirrt sind die vielen UART - Units (7 bzw. 8).

Nicht so unlogisch die vielen UARTs. Diese können auch im Master-SPI 
Modus betrieben werden. Im Zuammenhang mit schnellem DMA Transfer macht 
ein SPI Modul mit mehreren Peripherie keinen Sinn. Man benötigt dann 
wirklich separate SPI Module. Zb. MMC/SD Karte und SPI-ADC/DACs können 
quasi parallel Daten transferieren, und das dann in großen Mengen über 
DMA. Ein einzigstes SPI-Modul müsste dann mit ChipSelects arbeiten und 
kann immer nur eines der externen Devices zu einem Zeitpunkt ansteuern.

Was unverständilcher ist ist der Punkt warum überhaupt noch das 
veraltete SPI Modul integriert wurde statt die USART-SPI-Module soweit 
aufzubohren das sie auch im Slavemodus betrieben werden können. 
Besonders weil die USART-SPI-Module eigentlich effizienter sind, sprich 
Baudrateerzeugung, Doublebuffering der Rx/Tx Register, differenziertes 
Interrupthandling etc.pp.

Eigentlich finde ich alle Verbesserung an fast jedem Modul der XMegas 
interessant und schon längst überfällig.

2x ADC-Module die alle ADC Channel des MUX im Sweep-Modus schnell 
sampeln können. Hat man zb. 8 Kanäle im ADC0 aktiviert und sampelt im 
Sweep Modus, dann benötigt der ADC insgesamt 10+8+2 ADC-Takte um alle 8 
Kanäle am MUX zu sampeln. Dh. der Sweepmodus sampelt alle aktiven ADC 
Kanäle interleaved und nicht wie bisher sequientiell einen nach dem 
anderen. Natürlich nicht zu vergessen die 2 Msps, die Gains usw.

Dann der DAC der auch als Input intern an den AC geroutet werden kann. 
Ein einstellbarer Window-Comparator ist mit den 2 AC dann ohne Probleme 
möglich, ohne externes Routing etc.pp.

Die Timer, alle haben jetzt von Hause aus einen variables TOP Register 
und damit ist die Einstellung der Frequenz der Counter uniform gelösst. 
Also nicht so wie bisher über Umwege über OCRxx Register die dann nicht 
mehr als Comparematch Register benutzbar sind. Zudem kann man sie 2x 
oder 4x mal schneller takten als den CPU Kern, wenn ich das richtig 
verstanden habe. Geht über die PLL und der nachgeschalteten 
Teilerkaskade.

Interessant sind auch die Input Capture Eigenschaften der Counter. Eine 
Messung von zb. 16 Takten eines Signales inklusive Dutycycle und 
Frequenz pro Takt ist jetzt vollautomatisch möglich, echt Klasse. Man 
konfiguriert einen Counter im Input Capture Modus, er misst beide 
Flanken des Signales, und speichert per DMA die gemessenen Werte gleich 
in einen vorkonfigurierten SRAM Buffer. Signalsampling made easy ;) Zb. 
für IR-Fernbedienungen wird das damit schon lächerlich einfach gemacht.
Naja, und endlich mal ausreichend viele Timer was den Softwaredruck 
reduziert, man muß nicht mehr so geizen und alles in einen Timer 
reinpfropfen und sich so Timingprobleme einhandeln. Über das Eventsystem 
stehen so auch 32 bit breite Timer zur Verfügung.

Und das Eventsystem ist gut überlegt. Im Zusammenhang mit dem Timern, 
deren PWM Modis und den Komparatoren könnte ich mir gut vorstellen das 
man damit einen Synchronmoter fast ohne Softwareeingriff und ISRs 
programnmmieren kann. Einfach über das Eventsystem verknüpfen.

Die Idee mit den virtuellen Ports finde ich als guten Kompromiss. Bisher 
musste man immer abwägen welche Ports/Pins noch in den Registerbereich 
gelegt werden bei denen man mit einfachen Opcodes drauf zugreifen kann. 
Das führte bei Vielpinnern dazu das alle Ports in diesem Registerbereich 
lagen und somit diesen wertvollen Bereich verbrauchten. Mit dem nun 
virtuellen Mapping entscheidet der Programmierer welche der Ports er in 
den virtuellen Bereich auslagern möchte. Dann kann er über diese 
virtuellen Registerbeich mit den Single-Opcodes die Bits schnell 
togglen, auslesen, setzen, löschen usw. das macht man natürlich nur mit 
denjenigen Ports bei denen man schnell Bits verändern möchte, also ohne 
RMW-Feature-Umweg in atomarer Weise.

Auch das Mapping des EEPROMs in den SRAM finde ich überlegt. Das 
vereinfacht den Zugriff auf den EEPROM erheblich.

Bleibt nur zu hoffen das alle Versprechungen auch in Hardware 
reibungsfrei laufen und es nicht erst Jahre dauert bis alle Fehlerchen 
beseitigt sind.
Eventuell könnte die Anzahl der DMA Kanäle ein bischen wenig sein.

Alles in allem ist zwar der Core noch ein 8Bit AVR aber der Rest ist für 
mich ein echter Fortschritt und das betrifft jedes Peripheriemodul.

Gruß Hagen

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgendwo hatte ich vor kurzem eine Übersicht gesehen, bei der der 
hauptsächliche Unterschied zwischen den Klassen A1 bis A5 aufgelistet 
ist. Hat da zufällig jemand die Adresse auch noch gefunden?

Wolfgang

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie ich sehe ist das TWI-Modul in den XMega auch nicht besser geworden, 
schade auch.
Wäre nett, wenn das Teil im Slave-Modus wenigstens Auto-ACK machen 
würde.

Die mit dieser Unit notwendige Interrupt-Funktion finde ich deutlich zu 
komplex, das sieht mir nach erheblich zu viel Software-Overhead aus.

Autor: John Small (linux_80)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ich bis jetzt in Sachen TWI rausgelesen habe,
hat sich aber was geändert,
es gibt den Smart-Mode, bei dem man mit dem Lesen des Datenregisters 
auch gleich ein (N)ACK senden kann, als Master oder Slave. Ob's ein ACK 
oder NACK wird muss man aber immer noch vorher angeben.

Man muss kein TWINT wie bei den aktuellen AVRs per Software setzen, das 
Schreiben ins Datenregister sendet gleich los und wertet (N)ACK aus.

Nur DMA-Anbindung gibts keine, im Vergleich zu USART oder SPI, das wärs 
noch gewesen ;-)

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe das TWI bisher nicht als Schwachstelle der Megas gesehen. Ob 
man den Status nun durchs Lesen vom Register weiterschaltet oder 
explizit, das halte ich nicht wirklich für wichtig, nicht bei den dabei 
üblichen Bitraten.

Wichtiger wäre es, mal ein SPI mit brauchbarer Slave-Funktion zu 
bringen. Wie Atmel sich das bei einem ungepufferten Datenregister 
vorstellt ist mir nämlich bislang nicht klar geworden.

Autor: Ralf LK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Alles in allem ist zwar der Core noch ein 8Bit AVR aber der Rest ist 
für
mich ein echter Fortschritt und das betrifft jedes Peripheriemodul.

Gruß Hagen"

Die Sache mit 8 Bit finde ich nicht schlimm.
Jenes Minimaldesign ergab ja auch noch geringen Leistungsbedarf der 
XMEGA-Reihe.
Die Ergänzungen wie 'virtual port' läßt (letzte) Schwächen entfallen

Vielleicht hat sich Atmel per 'Konkurrenz' AVR32 selbst Limits auferlegt 
- http://www.ineltek.com/de/products/AT_AVR32.php
Deren Daten bzgl. Takt, RAM, Flash und Anzahl PINs sind sehr nahe an der 
XMEGA Linie und wohl als weiterer Aufstieg gedacht.

Dinge wie LCD-Ansteuerung, I2C, AC97, SD-Interface, USB oder Ethernet 
sind natürlich auch Wünsche für 8 Bit.
Im Minimum hätte ich aber USB erwartet.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich frage mich schon ein wenig, wozu das ganze. Die Teile sind von 
den Spezifikationen her den ARMs sehr ähnlich. Anscheinend haben die im 
Prinzip die selben Anwender im Visier.

Etwas wirklich 'revolutionäres' wie beispielsweise richtig viel RAM 
findet man da ja auch nicht. Bei 16 kiByte ist Schluss.

Als Nachfolger der ATMega Controller wird das irgendwie nicht 
überzeugend, zumal DIP-Gehäuse noch fehlen. In vielen Anwendungen ist 
man froh darüber, wenn man ein Sofwareupdate einfach durch Wechseln des 
Chips durchführen kann. Das können auch noch viele Kunden selbst machen. 
Einen Schraubendreher hat jeder, ein JTAG-Interface haben leider nur 
wenige Rechner serienmäsig.

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

Bewertung
0 lesenswert
nicht lesenswert
Christian Berger wrote:
> Einen Schraubendreher hat jeder, ein JTAG-Interface haben leider nur
> wenige Rechner serienmäsig.

Dafür gibt es Booloader/self-Programming.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wie Atmel sich das bei einem ungepufferten Datenregister
> vorstellt ist mir nämlich bislang nicht klar geworden.

Mit DMA-Controller ist die Pufferung kein großes Problem mehr. Wenn 
ferner Prioritäten für die Interrupts vergeben werden können, auch 
nicht. Man muß dies Möglichkeiten dann aber auch nutzen.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Andreas Schwarz wrote:
> Christian Berger wrote:
>> Einen Schraubendreher hat jeder, ein JTAG-Interface haben leider nur
>> wenige Rechner serienmäsig.
>
> Dafür gibt es Booloader/self-Programming.

Theoretisch ja, aber selbst dann musst Du noch eine Datenverbindung vom 
Programmierrechner zum Gerät aufbauen. Es ist viel einfacher einfach 
einem Kunden einen DIP-Chip zuzuschicken und ihm zu sagen, dass er den 
einfach auswechseln soll. So werden schon seit Jahren Softwareupdates 
auf Telefonanlagen gemacht. Der große Vorteil ist auch, dass es ein 
Prozess ist, den der Kunde komplett versteht. Das schafft Vertrauen. 
Falls die neue Softwareversion nicht funktioniert, so steckt er halt den 
alten Chip ein.

Autor: Philipp Burch (philipp_burch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Berger wrote:
> Andreas Schwarz wrote:
>> Christian Berger wrote:
>>> Einen Schraubendreher hat jeder, ein JTAG-Interface haben leider nur
>>> wenige Rechner serienmäsig.
>>
>> Dafür gibt es Booloader/self-Programming.
>
> Theoretisch ja, aber selbst dann musst Du noch eine Datenverbindung vom
> Programmierrechner zum Gerät aufbauen. Es ist viel einfacher einfach
> einem Kunden einen DIP-Chip zuzuschicken und ihm zu sagen, dass er den
> einfach auswechseln soll. So werden schon seit Jahren Softwareupdates

Und dann verkehrt herum einbaut.

> auf Telefonanlagen gemacht. Der große Vorteil ist auch, dass es ein
> Prozess ist, den der Kunde komplett versteht. Das schafft Vertrauen.
> Falls die neue Softwareversion nicht funktioniert, so steckt er halt den
> alten Chip ein.

Ist bestimmt eine Lösung, doch da heute eh schon alles vernetzt ist, 
halte ich einen Bootloader durchaus für eine gute Variante.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Philipp Burch wrote:

> Und dann verkehrt herum einbaut.

Es gibt auch Kunden, die nicht ganz blöd sind. Nebenbei kannst Du 
denen dann ja sogar einen neuen Chip verkaufen


> Ist bestimmt eine Lösung, doch da heute eh schon alles vernetzt ist,
> halte ich einen Bootloader durchaus für eine gute Variante.

Oh ja, darauf freue ich mich schon, wenn ich mich mal die Firmware von 
Türklingeln per Internet austauschen kann. :)

Autor: Dietmar E (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Es ist viel einfacher einfach einem Kunden einen DIP-Chip zuzuschicken

Wieso Einfacher? Es ist im Gegenteil viel einfacher für alle Seiten, 
wenn der Kunde ein USB-Kabel ansteckt. Wer schickt denn heute noch ICs. 
Der Aufwand ist viel zu hoch: Bestellungen annehmen, IC kaufen, 
programmieren, Rechnungen schreiben, versenden, Garantie übernehmen. Und 
der Kunde muss lange warten, das Gerät öffnen (damit kann man es nicht 
versiegeln), bricht vieleicht noch ein Beinchen ab. Nö.

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dietmar E wrote:
> [...] wenn der Kunde ein USB-Kabel ansteckt.

An welchen Pins der XMEGAs befinden sich gleich noch die USB-Signale?
;)

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Dinge wie LCD-Ansteuerung, I2C, AC97, SD-Interface, USB oder Ethernet
>>sind natürlich auch Wünsche für 8 Bit.
>>Im Minimum hätte ich aber USB erwartet.

Das könnte noch kommen. Ich bin nämlich stutzig geworden. Es gibt den 
CPU_Clock=Peripherie_Clock. Diese werden durch 2 einstellbare Vorteiler 
gefüttert. Diese Vorteiler erzeugen zwei zusätzliche Clocks für 
Peripherie die 2x oder 4x schneller als die ALU getaktet werden können 
und das synchron zur ALU. Schön dachte ich, suchste doch mal diejenige 
Peripherie raus die mit diesen Takten arbeiten kann. Es gibt sie nicht. 
Ich habe kein einzigstes Modul gefunden das mit diesen beiden Takten 
arbeiten kann. Das legt den Verdacht nahe das diese beiden Taktquellen 
für zukünftige Erweiterungen vorgesehen sind die dann 2x oder 4x 
schneller getaktet werden können als die max. möglichen 32Mhz der 
Standardperipherie/ALU. Ich hatte nämlich gehofft das man zb. die 
Timer/Counter mit diesen beiden höheren Takten antreiben kann, is aber 
nich.

Auch gibt es so einige Verweise auf AppNotes die nicht vorhanden sind. 
Die Funktionsweise des Erweitereten Waveform Modules, der 
High-Resolution-Modules und des EIBs sind defakto undokumentiert.

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Die Ergänzungen wie 'virtual port' läßt (letzte) Schwächen entfallen

Du meinst "auffallen" oder ?

Ich finde die 4 virtuallen Ports im Addressbereich 0x0010 bis 0x0020 
garnicht als so schlechten Kompromis. Das Design der AVR-8Bitter ist nun 
mal so wie es ist und Atmel stand vor dem Problem wie man mehr als 4 
Ports pro Chip denoch so ansteuern kann das sie ohne RMW schnell 
manipuliert werden können. Wenn man zb. Ports A,B,C,D,E,F hat dann wird 
es in den seltensten Fälle vorkommen das man an all diesen Ports zum 
gleichen Zeitpunkt mal schnell Bits wackeln möchte. Also legt man sich 
die Ports als Resource so auf diese 4 virtuellen Ports wie man es 
benötigt um schnell die entsprechenden Pins ansprechen zu können, das 
ginge ja sogar dynamisch zur Laufzeit zu konfigurieren.

Durch diese "Beschränkung" bekommt man dem User-Register-Bereich 
geschenkt, Addresse 0x0000 bis 0x000F in dem man eigene Daten ablegen 
kann, zb. eben Bitfields die man dann mit schnellen atomaren Opcodes 
manipulieren kann.

Auch die zwei zusätzlichen FLASH Pages mit den Kalibrierungswerten, 
Chip-IDs und eigenen Daten finde ich gut. Per SPI und Anwendungssoftware 
programmierbar.

Gruß Hagen

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Berger wrote:

> So werden schon seit Jahren Softwareupdates
> auf Telefonanlagen gemacht.

Du übertreibst.  Meine alte Euracom hat zwar noch gesteckte ROMs (für
die ich leider nichmal mehr Images bekomme beim Lieferanten, ich darf
ihn noch für die ROMs mit löhnen, wenn ich einen Update haben will),
aber bereits das Nachfolgemodell hatte Flash-ROMs.

Wenn du schon unbedingt die Firmware physisch und zum Kunde-stöpselt-
selbst haben willst, dann währe wohl sowas wie eine SD-Karte
einigermaßen zeitgemäß.  Selbst die ist deutlich kleiner als ein
DIP-40.

Autor: Christian Berger (casandro) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dietmar E wrote:
>> Es ist viel einfacher einfach einem Kunden einen DIP-Chip zuzuschicken
>
> Wieso Einfacher? Es ist im Gegenteil viel einfacher für alle Seiten,
> wenn der Kunde ein USB-Kabel ansteckt. Wer schickt denn heute noch ICs.
> Der Aufwand ist viel zu hoch: Bestellungen annehmen, IC kaufen,
> programmieren, Rechnungen schreiben, versenden, Garantie übernehmen. Und
> der Kunde muss lange warten, das Gerät öffnen (damit kann man es nicht
> versiegeln), bricht vieleicht noch ein Beinchen ab. Nö.

OK, dann muss der also irgendwoher einen passenden funktionierenden 
Rechner finden. Dann muss der Kunde auch noch irgendwie das Programm zum 
Laufen bekommen. Und zu guter letzt muss er noch so nahe an das Gerät 
mit seinem Rechner herankommen, dass das USB-Kabel reicht.

Rechnung musst Du sowieso schreiben und verschicken. Und die 
Wahrscheinlichkeit, dass der Kunde beim Auswechseln einen 
unkorrigierbaren Fehler macht ist geringer als bei irgendwelchen 
Software-updates per USB.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hagen Re wrote:
> Ich hatte nämlich gehofft das man zb. die
> Timer/Counter mit diesen beiden höheren Takten antreiben kann, is aber
> nich.

Genau das soll möglich sein. Wurde mir auf der Embedded gesagt und wurde 
auch so vorgeführt.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider erkenne ich das aus den Datenblättern nicht so. Dort wird Clk_Per 
vom Timer benutzt und der ist identisch zum Clk_MCU.
Der Prescaler der Timer kann nicht auf Clk_Per2x oder Clk_Per4x 
eingestellt werden.

Es sei denn die Datenblätter verraten noch nicht alles.

Geil wäre es, denn den ICP oder PWM mit 128Mhz laufen zu lassen wäre 
nicht schlecht.

Gruß hagen

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zu der PLL würde ich sagen -> siehe Tiny45.

Autor: Dietmar E (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dann muss der Kunde auch noch irgendwie das Programm zum
Laufen bekommen.

Was für eine schreckliche Vorstellung. Der dumme Kunde und der 
Mausklick. Zwei Welten. Dann doch lieber den Kunden mit Schraubendreher 
die Leiterbahnen massakrieren lassen.

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. wrote:
> Hagen Re wrote:
>> Ich hatte nämlich gehofft das man zb. die
>> Timer/Counter mit diesen beiden höheren Takten antreiben kann, is aber
>> nich.
>
> Genau das soll möglich sein. Wurde mir auf der Embedded gesagt und wurde
> auch so vorgeführt.

Haben sich die Leutz darüber ausgelassen, bei wieviel MHz da dann Schluß 
ist?

Hagen Re wrote:
> Es sei denn die Datenblätter verraten noch nicht alles.
Die Datenblätter verraten noch so einiges nicht, z.B. Stromverbräuche, 
Anschlußeigenschaften, Stabilität und Toleranzen von ADC/DAC etc.

Gruß
Jadeclaw.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jadeclaw Dinosaur wrote:

> Haben sich die Leutz darüber ausgelassen, bei wieviel MHz da dann Schluß
> ist?

32MHz CPU Takt, 128MHz Peripherie. Wie hoch man die übertakten kann, 
keine Ahnung.

Autor: Volker-01 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich finde vor allem interesant, das die neuen Chips durchweg auf der 
picopower-Technologie aufsetzen. Daher erwarte ich mir eine sehr geringe 
Energieaufnahme für die batteriebetriebenen Anwendungen. Nachteilig bei 
den STK600 wird warscheinlich der etwas höhere Preis sein, da ein 
spezieller Wechselsockel für die Controller drauf ist und für jeden 
Controllertyp ein spezielles Connection/Wiring-Board benötigt wird. 
Werde nächste Woche mal die ersten Tests mit einem STK600 machen können. 
Mal sehen, was die Controller so alles drauf haben.

Gruß, Volker

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hagen Re wrote:
>>>Dinge wie LCD-Ansteuerung, I2C, AC97, SD-Interface, USB oder Ethernet
>>>sind natürlich auch Wünsche für 8 Bit.
>>>Im Minimum hätte ich aber USB erwartet.
>
> Das könnte noch kommen. Ich bin nämlich stutzig geworden. Es gibt den
> CPU_Clock=Peripherie_Clock. Diese werden durch 2 einstellbare Vorteiler
> gefüttert. Diese Vorteiler erzeugen zwei zusätzliche Clocks für
> Peripherie die 2x oder 4x schneller als die ALU getaktet werden können
> und das synchron zur ALU.
>

Bis jetzt hat der USB auf den ATmegas aber eher nur alleine einen 
Nutzen. Da die PLL nur einige wenige ganzahlige Vielfache aus der 
BasisClock, also dem Quarz, machen kann, kann man sich aussuchen, ob man 
USB oder UART haben muss. Es gibt keine Einstellung in der man den UART 
mit 0% Toleranz betreiben kann und den USB ebenfalls verwenden kann.

Ich hoffe daher schwer, dass ATMEL in die X-Serie auch einen internen 
Oszillator einbaut, der dann per PLL für den USB genutzt werden kann und 
es erlaubt einen UART durch ein externes Quarz mit gerader Baudrate zu 
betreiben. Oder aber sie bohren den 32kHz Oszillator so auf, dass man 
mit seinem Clock auch andere Peripherie betreiben kann. Dann kann man 
dort das passende Quarz für die UARTs anschließen.

Naja, warum eigentlich, am PC gibt es den UART eh nicht mehr, also warum 
soll die Peripherie ihn behalten... War eine Schnittstelle, von der wir 
uns nun nach 20? 30? 50? Jahren verabschieden müssen. Ist einfach zu 
genormt, definiert, einfach, ausgereift, unverschlüsselt, von jedem zu 
leicht implementierbar....

Gruß, Ulrich

Autor: Malte __ (malte) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jadeclaw Dinosaur wrote:
> Hagen Re wrote:
>> Es sei denn die Datenblätter verraten noch nicht alles.
> Die Datenblätter verraten noch so einiges nicht, z.B. Stromverbräuche,
> Anschlußeigenschaften, Stabilität und Toleranzen von ADC/DAC etc.
>
Auch die genauen Prozessorbefehle finde ich noch nirgends. Ich wüsste 
gerne was es mit der Aussage einer 8/16 Bit CPU auf sich hat. Die ATMEGA 
hatten ja schon MOVW, ADIW und SBIW. Die Sache mit dem tmp Register 
scheint jedenfalls beibehalten worden zu sein. Wäre schön gewesen wenn 
es hier die Möglichkeit gegeben hätte die 16 Bit I/O Register in einem 
Schritt in die Register kopieren zu können (ohne das man Beinflussungen 
durch Interrupts beachten muss).

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das Thema ist doch geklärt. Es ist ein ATmega, 8Bit. Die 16 Bit sind 
quasi Werbung mit dem Hintergrund das man über den EBI ja bis zu 16Mb an 
Speicher dranhängen kann. Die 16Bit haben nichts mit der MCU zu tun 
allerhöchstens mit dem externen Speicherinterface und eventuell mit der 
Breite der Timer etc.pp.

Die Aussage ist auch klar ersichtlich -> XMega kann 1 zu 1 bestehende 
ATMega Projekte übernehmen mit den gewohnten Compilern.

Gruß Hagen

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>Ich hoffe daher schwer, dass ATMEL in die X-Serie auch einen internen
>>Oszillator einbaut, der dann per PLL für den USB genutzt werden kann und

schätze das du da lange warten kannst. Deine Forderung ist eine 
Forderung nach zwei komplett getrennten und nicht synchronen 
Taktdomains, das wird meiner Meinung garantiert nicht kommen, da dies 
für einen 8 Bitter einfach zu viel Logik zur Synchronisation mit der ALU 
benötigt. Wenn dann wird es so aussehen das der XMega mit USB 
ausgestattet wird. Dieses USB wird dann über einen der drei Takte 
(synchron zueinander) Clk_Per, Clk_Per2 oder Clk_Per4 erfolgen. Dabei 
muß dann der Controller mit einem externen Takt laufen der exakt die 
geforderten 48Mhz für den USB einhält. Also zb. 12Mhz Quartz, PLL auf x4 
und davon abgeleitet ein MCU Takt mit Teiler 1,2,4,8,16.

Wie gesagt, der PLL Takt kann durch zwei einstellbare Teiler auf 3 
verschiedene zueinander synchrone Takte runtergeteilt werden. Da ich in 
den datenblättern bisher kein einzigstes Peripheriemodul gefunden habe 
das die beiden höheren Takte benutzt, diese Takte also ungenutzt 
scheinen, ist die Wahrscheinlichkeit hoch das man sie für spätere 
Erweiterungen vorgesehen hat. Vorausgesetzt die Datenblätter enthalten 
das was man später im Silizium verkauft.

Gruß Hagen

Autor: Kai Franke (kai-) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Werde nächste Woche mal die ersten Tests mit einem STK600 machen können.
>> Mal sehen, was die Controller so alles drauf haben.

zwei Fragen:
Wo hast du das STK600 her und wo die Controller? Kann man die Controller 
schon sampeln?

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Haben die XMEGAS nicht einen fractional baud rate generator, womit der 
hickhack mit den baudratenquarzen eh ein ende hat?

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich empfehle mal, sich das XMega-Manual zu ziehen:
http://www.atmel.com/dyn/resources/prod_documents/...
und mal in die USART-Sektion ab Seite 223 zu schauen.
Dort ist das mit dem fractional baud rate generator erklärt.
Inklusive Formelsatz auf Seite 226.

Kurzerklärung für die, die kein Englisch können:
Der fractional baud rate generator funktioniert dergestalt,
daß einzelne Takte zusätzlich eingefügt werden,
um den Abtastpunkt wieder auf Bitmitte zu bringen.
Nach außen hin sieht es so aus, als ob da ein
Jitter auf dem Takt drauf ist, dies ist jedoch vertretbarer
als ein höherer konstanter Fehler.
Ganz ohne Baudratenquarz kommt man allerdings auch hier nicht aus,
da bei sehr hohen Baudraten der Teilerfaktor nicht beliebig
verkleinerbar ist. Im normalen Bereich (< 40kBaud)
sieht es aber anders aus, da sollte jetzt alles gehen,
was man in der Bastelkiste findet.

Gruß
Jadeclaw.

Autor: Rudolph R. (rudolph)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ein Glück, dass es FT232RL gibt.

Autor: Bensch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Es ist viel einfacher einfach
einem Kunden einen DIP-Chip zuzuschicken und ihm zu sagen, dass er den
einfach auswechseln soll. So werden schon seit Jahren Softwareupdates
auf Telefonanlagen gemacht.

Nein, so WURDEN Updates gemacht, die neuen haben ISP Flashs (siehe 
Euracom).

Wir haben vor etwa 2 Jahren unsere Boards modifiziert, um sie per 
Software-Update warten zu können. Da die Anlagen weltweit im Einastz 
sind, haben sich die Kosten drastisch verringert. Der Kunde (in der 
Regel absoluter Laie) hat sowieso nie ein EPROM in die Finger gekriegt, 
das hat immer der Servicepartner vor Ort gewechselt. Jetzt zieht er sich 
einfach den File vom Netz und geht mit dem Schlepptop zum Kunden.
Da die Programmspeicher einen nicht vom Service löschbaren Bootblock 
haben, gibt es auch keine zerschossenen Speicher oder uPs mehr. 
Bausteine wurden schon öfter beschädigt, umgebogene Beinchen (die der 
Service nicht sieht), Falschpolung, statische Entladung usw.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ulrich P. wrote:
> Bis jetzt hat der USB auf den ATmegas aber eher nur alleine einen
> Nutzen. Da die PLL nur einige wenige ganzahlige Vielfache aus der
> BasisClock, also dem Quarz, machen kann, kann man sich aussuchen, ob man
> USB oder UART haben muss. Es gibt keine Einstellung in der man den UART
> mit 0% Toleranz betreiben kann und den USB ebenfalls verwenden kann.

Ich lese im PDF ewas von "High Resolution Baud Rate Generator", also 
eventuell wird man jetzt auch ohne Baudratenquarz was reißen können.

Autor: Arc Net (arc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Als Nachfolger der ATMega Controller wird das irgendwie nicht
> überzeugend, zumal DIP-Gehäuse noch fehlen.

DIP-Gehäuse sind heutzutage absolut irrelevant. Zu groß, zu teuer, dazu 
u.U. noch Probleme aufgrund der Induktivität der Anschlüsse (z.B. Ground 
Bounce).
Mich wundert eher, das Atmel, im Gegensatz zu div. anderen Herstellern, 
die kleineren TQFPs nicht mit 0.5 mm Pitch anbietet (u.U. Vorteile beim 
Layout gegenüber QFN).

> In vielen Anwendungen ist man froh darüber, wenn man ein Sofwareupdate
> einfach durch Wechseln des Chips durchführen kann. Das können auch noch
> viele Kunden selbst machen.

Wenn das Gerät schon eine irgendwie geartete Schnittstelle nach draußen 
hat, dann hat der Kunde bzw. der Hersteller das auch (meistens) so 
eingerichtet, dass er diese nutzen kann.

> OK, dann muss der also irgendwoher einen passenden funktionierenden
> Rechner finden. Dann muss der Kunde auch noch irgendwie das Programm zum
> Laufen bekommen. Und zu guter letzt muss er noch so nahe an das Gerät
> mit seinem Rechner herankommen, dass das USB-Kabel reicht.

Und zum Austausch des Controllers, nimmt der Kunde dann die Anlage, in 
der das Gerät steckt, außer Betrieb, baut alles ab, nimmt das Gerät 
auseinandern, tauscht den Controller aus (der nicht selten eingelötet 
sein muss) und riskiert das andere ESD-empfindliche Bauteile den 
Eingriff nicht überleben usw.?

> Rechnung musst Du sowieso schreiben und verschicken. Und die
> Wahrscheinlichkeit, dass der Kunde beim Auswechseln einen
> unkorrigierbaren Fehler macht ist geringer als bei irgendwelchen
> Software-updates per USB.

Rechnungen für Firmware-Updates? Solange das keine gravierenden 
Änderungen sind (die der Kunde unbedingt haben wollte), haben diese 
kostenlos zu sein...
Zur Fehleranfälligkeit an sich: Das hängt, neben der Software, eben auch 
stark vom Controller ab (z.B. ob bestimmte Flash-Bereiche sicher vor 
einem Überschreiben geschützt werden können, ob die Spannungsversorgung 
vernünftig überwacht werden kann bzw. wird etc.).

> Ich hoffe daher schwer, dass ATMEL in die X-Serie auch einen internen
> Oszillator einbaut, der dann per PLL für den USB genutzt werden kann und
> es erlaubt einen UART durch ein externes Quarz mit gerader Baudrate zu
> betreiben.

Jein bzw. theoretisch ja, es gibt intern einen 2 MHz Osz. und 32 MHz 
Osz, die sich automatisch mit einem externen Takt (32 kHz TOSC) 
abgleichen können:
Full speed USB braucht 48 MHz +- 0.25 %, was sich auch mit passender 
Genauigkeit mit 32768 Hz abgleichen lässt (0.1 %), Clock-Jitter sollte 
auch die Spezifikation erfüllen (zumindest geht das z.B. bei Freescale 
oder Cyan 1)). Bleibt nur noch aus 48/24/16 MHz einen passenden 
UART-Takt zu erzeugen. Das geht bei 16 MHz und 24 MHz mit einem Fehler 
kleiner 1 % z.B. für 230400, 115200, 57600, 38400 etc. (bei 16 MHz auch 
460800 und 921600).

> Oder aber sie bohren den 32kHz Oszillator so auf, dass man
> mit seinem Clock auch andere Peripherie betreiben kann. Dann kann man
> dort das passende Quarz für die UARTs anschließen.

Nein, der Peripherietakt ist vom CPU-Takt abhängig. Ausnahme ist nur der 
RTC.

1) http://www.freescale.com/files/32bit/doc/app_note/AN2539.pdf

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net wrote:
>> Als Nachfolger der ATMega Controller wird das irgendwie nicht
>> überzeugend, zumal DIP-Gehäuse noch fehlen.
>
> DIP-Gehäuse sind heutzutage absolut irrelevant. Zu groß, zu teuer, dazu
> u.U. noch Probleme aufgrund der Induktivität der Anschlüsse (z.B. Ground
> Bounce).

Das ist einerseits verständlich. Andererseits wundert mich dagegen z.B. 
Microchip, die selbst die neuen 33er dsPICs mit 40MIPs als DIP anbieten.

Autor: Ralf LK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DIP oder PLCC

Es war ja auch auffallend, dass selbst der rel. neue ATMega644 noch als 
DIP 40 kam.

Dies widerspricht einer Grundanhame, das außer Amateueren eh keiner noch 
ohne SMD arbeitet.

Wobei ich den Sinn von DIP heute nicht mehr verstehe.
Es hat vs. PLCC nur den Vorteil direkt einlötbar zu sein.
Dafür ist PLCC deutlich kompakter und per PLCC68 könnte man auch 
anspruchsvolle Designs noch so anbieten.

Bliebe nur noch die Frage ob die ADC/DAC in 12 Bit ggf. durch DIP / PLCC 
Probleme bekommen.

PLCC68 könnte auch auf ganz wenige Produktreihen begrenzt werden.
Nur SMD hingegen bedeutet, dass die Einstiegsbarriere groß ist und 
letztlich dann gleich ARM verwendet werden kann.
Am Ende gibts dann vielleicht einmal einen XMega in DIP 40 als 
Schreckreaktion von Atmel zu mäßiger Akzeptanz der Kunden ...
Das ist aber dann wohl höhre Wirtschaftslehre ...

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es wird halt zur Folge haben, dass Universal-Kits wie der STK500 
schwierig werden. Der STK500 hat ja fast alles bis 40 Pins drauf, und 
das zu einen sehr vernünftigen Preis. Was preislich bei QFPs rauskommt 
sieht man an den STK5xx-Piggibacks für Mega128, Mega256 usw. Da geht der 
Löwenanteil der Herstellungskosten für die Fassung drauf, 3 solche 
Dinger auf einem Basisboard dürfte zu teuer werden.

Autor: Paul Baumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Es war ja auch auffallend, dass selbst der rel. neue ATMega644 noch als
>DIP 40 kam.

Das ist ein Zeichen dafür, daß man mit der Konkurrenz mithalten will.
Hoffentlich bleibt das so, daß es, wenn auch nicht alle, so doch ein
paar Typen weiterhin in DIL gibt.

MfG Paul

Autor: Volker-01 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@kai-

ich hab Kontakt zu einer Firma, die seit ein paar Wochen ein STK600 
auf'm Tisch haben, da sie ihn für ein neues Projekt einsetzen wollen. Da 
kann ich mir dieses jetzt, nach deren Tests in den letzten Wochen, mal 
für ein paar Tage ausleihen. Erhoffe mir auf jeden Fall ein paar neue 
Erkenntnisse über den Strombedarf und die Leistungsfähigkeit der 
Controller. Zur Zeit haben die nur den mit dem Board gelieferten 
Controller zur Verfügung. Ob die sonst schon Sampelbar sind, weis ich 
auch noch net.

Gruß, Volker

Autor: derwarze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wobei ich den Sinn von DIP heute nicht mehr verstehe.

Der hauptsächliche Grund ist darin zu suchen das viele Konsumegeräte mit 
billigsten LP-Material ausgestattet werden und da vielbeinige IS's nicht 
montiert werden können und da DIP-Gehäuse mitunter sinnvoll sind.
SMD's mit geringen Pinabstannd erfordern FR4 Material welches teuerer 
ist als simples Hartpapier.
Kein Hersteller baut extra für Bastler oder Eval-Boards 
DIP-Gehäuse(dafür gibt es Adapterplatinen ist ha auch beim STK600 und 
teilweise bein STK500 so gelöst).
Im übrigen find ich das sich SMD oft besser und schneller verarbeiten 
und Auswechseln lassen als klotzige 40Pinner in DIP. (hab vor kurzem die 
50 überschritten und die Feinmotorik mach noch locker mit)

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net wrote:
> Mich wundert eher, das Atmel, im Gegensatz zu div. anderen Herstellern,
> die kleineren TQFPs nicht mit 0.5 mm Pitch anbietet (u.U. Vorteile beim
> Layout gegenüber QFN).

Vielleicht, weil sie so kulant gegenueber uns armen Bastlern sind und 
wissen, dass man 0.5mm-Pitch nur noch schlecht selber aetzen kann? Und 
soviel an Platz gewinnt man gerade bei den kleineren Packages dadurch 
auch nicht.

Autor: vorbeigeschlendert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OT:
wenn der 'Hagen Re' noch einmal 'einzigste' schreib dreh ich durch...

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
:-) Das will ich sehen!

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so hat jeder seine Macken ;) aber stimmt, es liest sich grässlich

Gruß Hagen

Autor: Quatschkopf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> wenn der 'Hagen Re' noch einmal 'einzigste' schreib dreh ich durch...

Is doch in Ordnung. ;-)

Im Niederrheinischen(Kölsche) ist der Superlativ von 'einzig':

einzig -> einzigste -> allereinzigste -> allereinzigste überhaupt

Diese Definition stammt, glaub ich, von Konrad Beikircher.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Arc Net wrote:
> Jein bzw. theoretisch ja, es gibt intern einen 2 MHz Osz. und 32 MHz
> Osz, die sich automatisch mit einem externen Takt (32 kHz TOSC)
> abgleichen können:
> Full speed USB braucht 48 MHz +- 0.25 %, was sich auch mit passender
> Genauigkeit mit 32768 Hz abgleichen lässt (0.1 %), Clock-Jitter sollte
> auch die Spezifikation erfüllen (zumindest geht das z.B. bei Freescale
> oder Cyan 1)). Bleibt nur noch aus 48/24/16 MHz einen passenden
> UART-Takt zu erzeugen. Das geht bei 16 MHz und 24 MHz mit einem Fehler
> kleiner 1 % z.B. für 230400, 115200, 57600, 38400 etc. (bei 16 MHz auch
> 460800 und 921600).
>
>> Oder aber sie bohren den 32kHz Oszillator so auf, dass man
>> mit seinem Clock auch andere Peripherie betreiben kann. Dann kann man
>> dort das passende Quarz für die UARTs anschließen.

Es gibt einen Fractional Baud Rate Clock Generator. Habe ich oben 
schonmal erwähnt, damit ist die Diskussion eigentlich hinfällig, da so 
alle üblichen Baudraten mit kleinem Fehler erzeugt werden können. (Seite 
225 im Manual)

Autor: Richard Feynman (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
137

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für den XMega gibt es zwei Datenblätter, ein Manual und eine 
detaillierte Peripherie-Beschreibung.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Travel Rec. wrote:
> Für den XMega gibt es zwei Datenblätter, ein Manual und eine
> detaillierte Peripherie-Beschreibung.

Markiert als "Preliminary"

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael G. wrote:

> Markiert als "Preliminary"

Das scheint bei Atmel normal zu sein.

Auch bei Modellen, die schon seit einiger Zeit allgemein verfügbar sind, 
sind die Datenblätter teilweise noch als "Preliminary" gekennzeichnet.

Autor: Mike (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Auch bei Modellen, die schon seit einiger Zeit allgemein verfügbar sind,
>sind die Datenblätter teilweise noch als "Preliminary" gekennzeichnet.


Das verstehe ich auch nicht.
Ist bei vielen Herstellern so.
Wollen die sich vor Regress-Forderungen schützen oder warum machen die 
das?

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht verschlingt die Produktion so viel Manpower, daß für 
ausgiebige Tests und Datenblattschreiberei keine Zeit bleibt ;-)

Autor: Willivonbienemaya .. (willivonbienemaya)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Travel Rec. wrote:
> Vielleicht verschlingt die Produktion so viel Manpower, daß für
> ausgiebige Tests und Datenblattschreiberei keine Zeit bleibt ;-)

OT: Keine Zeit ist doch immer nur ne Ausrede für kein Geld ;-)

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Echt? ;-)

Autor: Ernst Ribbay (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bei mir ist keine Zeit eigentlich immer die Ausrede für keine Lust ... 
;-)

Ob es denen bei Atmel auch so geht ? Ich könnte mir etwas schöneres 
vorstellen, als alle Datenblätter zu "warten" und immer aktuell zu 
halten.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich könnte mir etwas schöneres
>vorstellen, als alle Datenblätter zu "warten" und immer aktuell zu
>halten.

Das sind aber Arbeitsplätze.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Andere Frage:
Kann man die XATMEGA eigentlich noch per SPI programmieren?

Ich habe im Datenblatt nichts darüber gefunden.
Es wird die JTAG-Schnittstelle beschrieben, dann noch eine andere 
2-Wire-Schnittstelle, aber keine SPI.

Falls es nicht mehr möglich sein sollte, diese Prozessoren per SPI zu 
programmieren, dann wären diese so hoch gepriesenen Prozessoren für mich 
nicht zu gebrauchen, den die Tatsache, dass die ATMEGA-Familie über SPI 
programmierbar ist, hat für meine Projekte gewisse Vorzüge, die ich bei 
anderen Prozessoren nicht habe.


Tschüss
Martin

Autor: Egon (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also bei den Angaben auf der Atmel Webseite zu den Tools für die Xmegs 
steht immer noch: "In-System Programming:  AVRISP mkII In-System 
Programmer" ...

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind per ISP, JTAG und PDI programmierbar.

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Martin wrote:

> Falls es nicht mehr möglich sein sollte, diese Prozessoren per SPI
> zu programmieren, dann wären diese so hoch gepriesenen Prozessoren
> für mich nicht zu gebrauchen, den die Tatsache, dass die
> ATMEGA-Familie über SPI programmierbar ist, hat für meine Projekte
> gewisse Vorzüge, die ich bei anderen Prozessoren nicht habe.

Welche Nachteile siehst Du denn bei PDI im Vergleich zu SPI?

Gut, man braucht einen neuen Adapter, aber in der praktischen
Anwendung dürfte PDI noch einfacher zu handhaben sein als SPI,
z.B. weil man nur noch einen drei- oder vierpoligen Stecker dafür
braucht und weil die Programmierschnittstelle am Controller keine
"normalen" Portpins belegt.


Egon wrote:

> Also bei den Angaben auf der Atmel Webseite zu den Tools für die
> Xmegs steht immer noch: "In-System Programming: AVRISP mkII
> In-System Programmer" ...

Ich nehme an, daß man dem AVRISP mkII per Firmware-Update beibringen
kann, sich mit den XMEGAs über PDI zu unterhalten.


Travel Rec. wrote:

> Sind per ISP, JTAG und PDI programmierbar.

Quelle?

"ISP" sagt erstmal nur, daß sie im eingebauten Zustand programmierbar
sind, aber nicht über welche Schnittstelle. Ich nehme aber mal an, Du
meintest SPI.

In den Datenblättern der XMEGAs konnte ich bisher keinen Anhaltspunkt
dafür finden, daß sie neben JTAG und PDI auch über SPI programmierbar
sind.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Halt, ich muß mich korrigieren: laut bestehendem Datensatz sind die 
XMEGAs nur über PDI (was eine bidirektionale ISP-Schnittstelle 
darstellt, in Verbindung mit dem RESET-pin) und über JTAG programmiert 
werden. Kein ISP im altbekannten Sinn, also inkompatibel zu STK500, 
AVR_ISP und bisheriger AVR_Dragon-Firmware.

Autor: Dan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja solange die AVRs nicht an den Stromverbrauch eines MSP430 kommmen 
werden die bei uns nicht mehr eingesetzt.....da hilt die "Mogelpackung" 
Picopower auch nicht viel....

Autor: Michael J. (jogibaer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Travel Rec. wrote:
> Halt, ich muß mich korrigieren: laut bestehendem Datensatz sind die
> XMEGAs nur über PDI (was eine bidirektionale ISP-Schnittstelle
> darstellt, in Verbindung mit dem RESET-pin) und über JTAG programmiert
> werden. Kein ISP im altbekannten Sinn, also inkompatibel zu STK500,
> AVR_ISP und bisheriger AVR_Dragon-Firmware.

Hallo,

ist das Protokoll wenigstens offen, so daß man sein Programmiergerät
modifizieren kann ?


Jogibär

Autor: R. Max (rmax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Jogwich wrote:

> ist das Protokoll wenigstens offen, so daß man sein Programmiergerät
> modifizieren kann ?

Wirf mal einen Blick in die Datenblätter, da findest Du alles.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Theoretisch. Praktisch eher nicht, zumindest für Normalkunden. Zumindest
>wurde mir das am Atmel Stand auf der Embedded World gesagt.
>Preislich sollten die ein kleinwenig über den vergleichbaren ATmegas
>liegen, die dann zunehmend auslaufen.

Hatte gestern Vertreterbesuch ...
Mir wurde versichert, das die ATMegas nicht auslaufen werden.
Hab auch erste 2 Samples, mal sehn ...

>Erhältlich sollen die ab Mitte 2008 sein. Ich rechne aber eher mal mit
>Ende 2008.

Mass production soll in Juni starten.

Autor: Joachim (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Welchen Typ gibt es als erstes bzw. als Muster?

Joachim

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Joachim wrote:

> Welchen Typ gibt es als erstes bzw. als Muster?

Das dürfte mit größter Wahrscheinlichkeit der ATxmega128A1 sein.

Autor: Christian U. (z0m3ie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
genau.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die XMEGA's sind zwar immer noch nicht lieferbar, aber digikey hat die 
ersten zu recht interessanten Preisen ins Programm aufgenommen. 
Erfahrungsgemäß werden sie wohl ab September zu kaufen sein.

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Interessant ist wohl leicht untertrieben, für einen normalen 
ATMega128-16AU möchte Digikey €13,50, den entsprechenden XMega128 gibt's 
für nichtmal die Hälfte: € 5,22. Wenn sich dieses Verhältnis auch bei 
anderen Lieferanten in dieser Art fortsetzen sollte, sehe ich für so 
einige ATMegas schwarz.

Gruß
Jadeclaw.

Autor: Maximus86 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo wollte hier nur kurz wiedergeben was Reichelt dazu sagt:

"Sehr geehrter Herr xxx,

wir bedanken uns für Ihre Anregung.
Leider ist die ATxmega-Serie noch nicht in ausreichenden Stückzahlen
verfügbar. Sobald sich die Liefersituation geändert hat, werden wir die
Typen selbstverständlich über unseren Online-Shop anbieten.




Mit freundlichen Grüßen

reichelt elektronik "

Also dauert das noch etwas bis man hier in DE die neuen Atxmega's kaufen 
kann.

Mfg

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jadeclaw Dinosaur wrote:
> Wenn sich dieses Verhältnis auch bei
> anderen Lieferanten in dieser Art fortsetzen sollte, sehe ich für so
> einige ATMegas schwarz.

Ob das vielleicht Atmels Absicht ist? ;-)

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
CSD-electronics wird die XMegas auch bald haben, sicher günstiger, als 
Angelika.

Autor: Dr. Scratch (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
War kan ich ein ATXmega kaufen???????????///

Autor: Maria (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was nützt der beste Controller wenn die Hardware zum Debuggen für privat 
unbezahlbar ist.

Ich bin auf Zilog ZNEO umgestiegen. 128kB Flash, 4kB RAM. 13 Register a 
32-Bit.

Im PLCC68 per Fassung auf Lochrasterkarte. Eine 2x3-polige Stiftleiste 
plus ein Widerstand bilden den Anschluss für das 20Euro 
USB-Programmier/Debug-Kabel.

Programmieren (C, ASM) und Debuggen kann man mit dem kostenlosen Zilog 
Programm ZDS II.
Das ist zwar ein lausiges, fehlerträchtiges Programm aber ohne 
Beschränkungen und wenn man die Absturzstellen kennt ist gutes Arbeiten 
möglich. Mit Dingen wie mak-Files braucht man sich nicht rumschlagen. 
Das wird über die IDE eingestellt.

100kB Flash sind in 40 Sekunden geladen. 10kB in 8 Sekunden.

Autor: Willivonbienemaya .. (willivonbienemaya)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Maria wrote:
> Ich bin auf Zilog ZNEO umgestiegen. 128kB Flash, 4kB RAM. 13 Register a
> 32-Bit.
>
> Im PLCC68 per Fassung auf Lochrasterkarte. Eine 2x3-polige Stiftleiste
> plus ein Widerstand bilden den Anschluss für das 20Euro
> USB-Programmier/Debug-Kabel.

Ich benutze zur Zeit dsPic33FJ128XX802.
128 kB Flash
16 kB RAM
40 MIPS
CAN,...

DIP28 Gehäuse.


Trotzdem wärs Interessant wenn man mal wüsste wanns die XMegas zu kaufen 
gibt.

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Maria:
Habe das Ganze mal verglichen --> mit einem normalen ATMega1280.
Vorteil ZNEO: PLCC-Gehäuse (wegen der lochrastertauglichen Sockel); 
IrDA-Encoder; OpAmp; DMA.
Nachteile ZNEO: Absturzfreudige IDE(deine Aussage); Timer langsam(max. 
1/4 CPUtakt); Fehlendes EEProm.

Vorteile ATMega1280: Mehr Timer, die auch schneller sind(1/2 CPU-Takt);
mehr SRAM; EEPRom; mehr ADC-Eingänge; mehr PWM-Kanäle; stabile IDE(auch 
ohne Make-File-Fummeleien, GCC wird automatisch gefunden); kompatibles 
Upgrade möglich, wenn der Speicher nicht reicht(ATMega2560); kein 
Spezialkabel/Spezialprogrammierer notwendig, man kann alles selbst 
bauen; Externes Speicherinterface auch bei der 'kleinen' Version 1281; 
Problemlos bei Endverbraucherlieferanten erhältlich.

Nachteile ATMega1280: Kein PLCC-Gehäuse, einlöten wird fummelig, wg. 
TQFP-Gehäuse;, nur 16MHz CPU-Takt; kein DMA.

Noch Fragen?

Gruß
Jadeclaw.

Autor: Joe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Nachteile ATMega1280: Kein PLCC-Gehäuse, einlöten wird fummelig, wg.
>TQFP-Gehäuse;, nur 16MHz CPU-Takt; kein DMA.

Zumindest die beiden letzten Nachteile werden mit dem XMega gelöst:
max. 32Mhz CPU Takt
DMA
+ Das neue Event System welches einige Aufgaben wie z.B. triggern eines 
DMA Transfers bzw. einer AD Wandlung automatisiert in Hardware 
durchführt und keine CPU mehr belastet wird.
Dazu finde ich die Crypto Engine für AES/DES Ver/Entschlüsselung 
nützlich sowie das EBI.

Autor: Maria (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich will den ZNEO wirklich nicht in den Himmel jubeln.

Man kann ihn aber nicht mit einem ATmega vergleichen. Durch die 32-Bit 
Register mit Hardware Mul/Div liegt er in der Geschwindigkeit weit 
darüber. Man hat ja nicht nur 8-Bit Daten/Adressen.

Gleitkommazahlen bremsen den ZNEO viel weniger aus und auch die 
Kodegröße explodiert nicht wie beim ATmega.

Zur Korrektur und Erweiterung, der ZNEO hat:
-  einen separaten 6 Kanal PWM Timer
-  drei normale 16-Bit Timer mit PWM.
-  12 ADC Eingänge
-  4 DMA-Kanäle mit direkter Verbindung zu den meisten Einheiten.
-  Flash, RAM und Register sind ein Adressbereich. Keine Umstände beim 
Lesen von Konstanten aus dem Flash.

Worauf ich aber hinaus wollte – Der ZNEO liegt nahe dem Niveau des 
ATxmega und Debuggen kann ich ihn für 20 Euro. Was kostet die 
äquivalente Hardware für den ATxmega? Mehrere 100 Euro.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Was kostet die
>äquivalente Hardware für den ATxmega? Mehrere 100 Euro.#

Nicht ganz. Support für den AVR-ISP mkII ist angekündigt. Programmieren 
kann man dann für 40 EUR. Debuggen wird eventuell mit dem Dragon möglich 
sein. Ist noch nicht ganz ´raus.

Autor: Wolfgang Birner (logox2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im SP1 zum AVR-Studio (Beta) sind die Files zum Programmieren der XMegas 
mit dem mkII schon drin, siehe:
http://www.atmel.no/beta_ware/

mfg
wolfgang

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.