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":http://www.mikrocontroller.net/articles/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":http://www.atmel.com/products/AVR/default_xmega.asp und im "ATxmega Manual":http://www.atmel.com/dyn/resources/prod_documents/doc8077.pdf.
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
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.
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.
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
Gibt es von den AVR XMEGA wirklich kein einziges Exemplar mit USB? Wäre wirklich schade. Gruß Stefan Salewski
Es gibt wahrscheinlich auch noch kein einziges Exemplar ohne USB zu kaufen.
Und, dass es kein Ethernet gibt, stört mich auch noch ein wenig ;)
Andreas Kaiser wrote: > Es gibt wahrscheinlich auch noch kein einziges Exemplar ohne USB zu > kaufen. DIE aussage musst du mir erstmal erklären !
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.
USB und Ethernet kommen warscheinlich noch (laut Atmel Stand auf der Embedded)
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.
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.
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.
Naja also der IS ja auch wirklich um einiges "besser" als die jetzigen Megas... ;) Und klar muss ich den haben hehe...
@ 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
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.
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.)
@ Benedikt Verstehe. Dankeschön. Werde vielleicht doch noch zur Embedded fahren und auch mal mit den Atmel-Leuten reden. Gruss Oops
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?
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
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.
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
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
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
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.
Hab nur mal kurz gegoogelt, konnte aber kein STK600 zu kaufen sehen. Kennt jemand einen Laden in dem man das bekommt? Gruss Oops
Sorry, hätte vielleicht ein neuer Thread sein sollen.
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.
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
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?!?
ATmega2560: 135 Befehle. ATxmega A: 135 Befehle. Beantwortet das deine Frage?
Ja. Bei dem Infomaterial das ich mitgenommen habe, steht: Pin und Softwarekompatibel zu den ATmegas.
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
> 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!
Solange Atmel keine normalen DIL ICs anbietet werden die sich das Teil von meiner Seite aus in den A. schieben können.
> 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 :)
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?
@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.
@Jörg: Naja, wenn Atmel die Hobbyisten weglaufen haben die auch ein Problem.
@ 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 ;) )
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 ;)
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.
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.
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.
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.
>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
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))...
> 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
@ 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
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.
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).
> 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.
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 ;)
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?
> 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
He Mike lass den Wein und das Bier und alles geht (wieder).
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...
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.
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 :-).
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.
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.
@ Jörg: Darf ich mal etwas provokant fragen woher Deine Vorstellung bezüglich DebugWire stammt? Jens
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 ?
@Andreas Kaiser Also im Xmega256a1 Manual steht was von 139 Befehlen!
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.
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...
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 :-))
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...
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.
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.
> 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.
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.
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?
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.
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.
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 ?
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.
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.
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.
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.
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.
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.
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.
Die A2 sind bei Spoerle gelistet (da sind die Dinger ja schon vor Monaten aufgetaucht). Sollen 80 Pins haben.
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.
>> 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
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
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.
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 ;-)
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.
"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.
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.
Christian Berger wrote: > Einen Schraubendreher hat jeder, ein JTAG-Interface haben leider nur > wenige Rechner serienmäsig. Dafür gibt es Booloader/self-Programming.
> 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.
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.
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.
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. :)
> 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ö.
Dietmar E wrote:
> [...] wenn der Kunde ein USB-Kabel ansteckt.
An welchen Pins der XMEGAs befinden sich gleich noch die USB-Signale?
;)
>>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
>>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
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.
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.
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.
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
> 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.
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.
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.
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
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
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).
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
>>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
>> 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?
Haben die XMEGAS nicht einen fractional baud rate generator, womit der hickhack mit den baudratenquarzen eh ein ende hat?
Ich empfehle mal, sich das XMega-Manual zu ziehen: http://www.atmel.com/dyn/resources/prod_documents/doc8077.pdf 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.
> 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.
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.
> 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
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.
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 ...
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.
>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
@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
> 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)
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.
OT: wenn der 'Hagen Re' noch einmal 'einzigste' schreib dreh ich durch...
:-) Das will ich sehen!
so hat jeder seine Macken ;) aber stimmt, es liest sich grässlich Gruß Hagen
> 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.
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)
Für den XMega gibt es zwei Datenblätter, ein Manual und eine detaillierte Peripherie-Beschreibung.
Travel Rec. wrote: > Für den XMega gibt es zwei Datenblätter, ein Manual und eine > detaillierte Peripherie-Beschreibung. Markiert als "Preliminary"
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.
>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?
Vielleicht verschlingt die Produktion so viel Manpower, daß für ausgiebige Tests und Datenblattschreiberei keine Zeit bleibt ;-)
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 ;-)
Echt? ;-)
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.
>Ich könnte mir etwas schöneres >vorstellen, als alle Datenblätter zu "warten" und immer aktuell zu >halten. Das sind aber Arbeitsplätze.
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
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" ...
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.
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.
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....
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
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.
>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.
Welchen Typ gibt es als erstes bzw. als Muster? Joachim
Joachim wrote:
> Welchen Typ gibt es als erstes bzw. als Muster?
Das dürfte mit größter Wahrscheinlichkeit der ATxmega128A1 sein.
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.
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.
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
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? ;-)
CSD-electronics wird die XMegas auch bald haben, sicher günstiger, als Angelika.
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.
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.
@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.
>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.
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.
>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.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.