Hallo liebe Leser, da ich gerade mit dem XMEGA16_E5 werkele, wollte ich kurz mitteilen, was mir aufgefallen ist, bevor sich jemand wundert. Da die Familie noch recht neu ist, kann es sein, dass noch mehr Errata hinzukommen, als bisher im Datenblatt aufgenommen sind. Fehler: - Das Löschen der Applikationssektion verursacht auch ein Löschen der Bootsektion und umgekehrt. Dies gilt sowohl für Self-Programming (mittels Bootloader) als auch für das Programmieren über PDI. Weiterhin sollte man das Datenblatt/Manual genau studieren, da es wohl auch einige Unterschiede zu den bisherigen AVR-Cores gibt. So ist es zum Beispiel nicht mehr möglich, den Bootloader weiterlaufen zu lassen, während gerade eine Seite im Applikationsflash geschrieben wird. Die CPU wird für die gesamte Schreibzeit von ~4ms angehalten. Hat man also einen kontinuierlichen Update-Datenstrom von beispielsweise einem Terminal-Programm, so werden die eintrudelnden Bytes für 4ms nach jeder Flashpage nicht abgeholt. Daher braucht man entweder eine sehr niedrige Baudrate oder aber eine bidirektionale Schnittstelle mit Bestätigung, dass das nächste Byte kommen kann. Für meine Begriffe ein ziemlicher Rückschritt. Abgesehen davon gefällt mir der Controller gut!
Knut Ballhause schrieb: > Das Löschen der Applikationssektion verursacht auch ein Löschen der > Bootsektion und umgekehrt. Dies gilt sowohl für Self-Programming > (mittels Bootloader) als auch für das Programmieren über PDI. Das scheint dann wohl in der Tat ein Bug im NVMC zu sein. Als Workaround schlage ich das pagewise loeschen in einer FOR-Schleife vor. (So wie man es zu Zeiten gemacht hat, als es keinen separaten Erase-Befehl fuer die RWW gab.) MfG
Ja, darauf bin ich auch schon gekommen. Das läuft problemlos, dauert aber deutlich länger ;-)
Gast
#3546781
Kein undokumentiertes Feature aber auch ein wichtiger Unterschied des E5 zu allen anderen AVR Tiny/Mega/Xmega-Typen: Die Timer-Overflow Interruptflags werden NICHT mehr automatisch mit dem Aufruf des Interrupts zurückgesetzt, das muß nun (leider) manuell geschehen (1->Bitposition).
Gast
#3546847
Stephan B. schrieb: > Als Workaround schlage ich das pagewise loeschen in einer FOR-Schleife > vor. Ich schlage als Workaround vor, einfach einen besseren Controller zu verwenden. Die XMegas sind einfach voller Fehler.
Paul schrieb: > Ich schlage als Workaround vor, einfach einen besseren Controller zu > verwenden. Die XMegas sind einfach voller Fehler. Ersten ist das dann ein Patch und kein Workaround. Zweitens sind die XMegas eigentlich ganz nett. ...und... Drittens haben die meisten Ersterscheinungen von ICs einige Bugs drinnen. Wer AVR mag wird XMega nicht hassen. MfG
Gast
#3546991
Stephan B. schrieb: > Ersten ist das dann ein Patch und kein Workaround. Sehr klug! Oh mann... > > Zweitens sind die XMegas eigentlich ganz nett. > Nein. Dieser Halbleiter ist nicht nett. Sondern schlicht und einfach ein Exkrement in Silizium. > ...und... > > Drittens haben die meisten Ersterscheinungen von ICs einige Bugs > drinnen. Ja. Besonders die XMegas. > > Wer AVR mag wird XMega nicht hassen. Stimmt auch nicht. Ich mag die alten AVRs.
Hallo Paul Naja, was soll ich die XMegas verteidigen - ich bin ja schliesslich nicht (oder gehoere zu) Atmel. Ich hoffe nur, das die Mehrheit das anders als du sieht. Paul schrieb: >> Wer AVR mag wird XMega nicht hassen. > > Stimmt auch nicht. Ich mag die alten AVRs. Ich habe deshalb bewusst nicht "lieben" geschrieben ;-) Lass uns beim Thema des Threads bleiben und die XMega gut/boese Diskussion hier beenden. MfG
Gast
#3547125
Paul schrieb: > Die XMegas sind einfach voller Fehler. Spätestens seit den aktuellen USB-Typen ist das schlicht falsch.
@ Moby: Das mit den Overflow-Flags ist ein guter Tip! Paul schrieb: > Ich schlage als Workaround vor, einfach einen besseren Controller zu > verwenden. Die XMegas sind einfach voller Fehler. Ja, guck Dir mal die Errata eines vergleichbaren MSP430 oder Cortex M0-Controllers an. Dann reden wir weiter ;-)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.