Hallo Zusammen,
seit kurzem habe ich ein das XPLAIN Board von Atmel mit dem XMega
darauf.
Im Moment bin ich gerade dabei, meine ersten Programme darauf zu
schreiben.
http://www.atmel.com/dyn/products/tools_card.asp?tool_id=4506&source=xplain_page
Bei Reichelt gibt es das Board für knapp 40Euro.
Hat jemand schon Erfahrung mit dem Board?
Ich würde gerne einige meiner Code-Beispiele hier posten und hoffe auf
einen regen Austausch.
Gruß,
Klaus
Klaus schrieb:
> Bei Reichelt gibt es das Board für knapp 40Euro.
40 sind zu teuer, der Preis liegt momentan bei 30-35 Euro z.B.
http://www.watterott.com/de/Atmel-AVRXPLAIN
Klaus schrieb:
> Hat jemand schon Erfahrung mit dem Board?
einfach die suchfunktion benutzen, da gibt es schon einige Beiträge und
Code Beispiel etc.
Gruß
Martin
Das XPLAIN-Board hat einen Lautsprecher eingebaut.
Um diesen zu testen, habe ich ein kleines Programm geschrieben, welches
einen Rechhteck auf den DAC-Kanal 0 ausgibt.
Den Verstärker auf dem Baord muss man extra einschalten. Bei mir ergibt
sich ein relativ großes Rauschen des Lautsprechers, wenn ich die
Amplitude des DAC auf 0 drehe ( bzw. den Mittelwert von 2048 ).
Wie ist das auf eurem Board?
Bascom geht auch? Ist ja interessant. Hätte ich nicht gedacht. Beim
XPLAIN ist es ja ein wenig das Problem, die ganzen Treiber in C zu
schreiben.
Leider bin ich jetzt nicht so der Bascom-Freak, deshalb kann ich Dein
Programm nicht ausprobieren.
Kann man mit Bascom ein Hex-File erstellen? Wenn ja könntest Du es ja
mal posten, dann kann ich das Programm ausprobieren.
Gruß,
Klaus
Hallo Reader,
Dein Programm funktioniert. Ich habe einfach Hypererminal verwendet und
eine WAV-Datei mit der Option "Übertragung->Textdatei senden"
übertragen.
Erstaunlich, dass das funktioniert, am Ende der Übertragung meldet das
Terminal Lied n zurück.
Du hast ein LCD an den XPLAIN angeschlossen, gibt es einen Schaltplan
dafür?
Eine Sache fällt mir bei der Rückmeldung des XPLAIN auf: das Terminal
zeigt oft falsche Zeichen. Ich habe selbst ein Programm in C für die
serielle Schnittstelle geschrieben, dort habe ich den selben Effekt. Wie
ich in Deinem Programmcode sehe, verweist du auf das LUFA-Projekt. Gibt
es einen Grund dafür? Ich dachte, in der Grundkonfiguration des XPLAIN
ist der USBATMEGA schon mit einer seriellen Bridge ausgestattet.
Kleiner Nachtrag: nur die wav-Datei type.wav von windows-XP funktiniert
korrekt. Andere WAV-Files geben eine ziemliche Rauschkullise ab.
Vermutlich liegt das am Format, oder? 8 bit mono?
Hallo Klaus,
> Du hast ein LCD an den XPLAIN angeschlossen, gibt es einen Schaltplan
dafür?
Nein, den gibt es nicht.
Ich habe einfach ein GLCD genommen, welches mit 3,3V noch funktioniert
und einen ATMega dazwischen gehängt, der die seriellen Befehle an das
GLCD überträgt.
> Wie ich in Deinem Programmcode sehe, verweist du auf das LUFA-Projekt.> Gibt es einen Grund dafür?
Nur wegen der Doppelfunktion programmieren und Terminal über USB.
> Vermutlich liegt das am Format, oder? 8 bit mono?
Ich habe eine trial Version "Wav Sample Rate Converter" genommen und MP3
in WAV convertiert. (8 Bit, mono, 11,025kHz)
Die Trial ist zwar begrenzt auf 1 Minute, aber zum testen hat es
gereicht.
Die Links habe ich mir angesehen.
Leider sind die Examples für Dataflash sehr mager.
Mich hätte z.B. die programmtechnische Umsetzung interessiert.
Zitat Datenblatt AT45DB642D
> • Two SRAM Data Buffers (1024/1056 Bytes)> – Allows Receiving of Data while Reprogramming the Flash Array
>> Wie ich in Deinem Programmcode sehe, verweist du auf das LUFA-Projekt.>> Gibt es einen Grund dafür?>Nur wegen der Doppelfunktion programmieren und Terminal über USB.
Es war ganz gut, dass Du die Firmware des USBAtmega gleich ersetzt hast.
Bei mir gab es bei der seriellen Übertragung ziemlich viele Fehler.
Nachdem ich die neue Lufa-Software aufgespielt habe, sind diese Fehler
fast ganz verschwunden. Außerdem wird jetzt das XPLAIN-Board auch als
MKII Programmierer erkannt, sodass ich den XMEGA ohne JTAG programmieren
kann. Laut Beschreibung hätte das ja schon ab Werk funktionieren sollen.
Ohne diese Funktion sind ja die Leute, die keinen JTAG-Programmierer wie
z.B. den AVR-Dragon haben, aufgeschmissen.
Mein XPLAIN habe ich vor ca.2 Wochen bei Reichelt bestellt. Es ist ein
REV2 Board. Laut der Doku von Atmel sollte es schon REV4 geben.
Vielleicht lag es daran. Wobei der Fehler allerdings auch nicht bei
Reichelt zu suchen ist, da die das XPLAIN wohl auch erst neu bezogen
haben.
> Laut Beschreibung hätte das ja schon ab Werk funktionieren sollen.
wie kommst du da drauf ?
AVR1907:
> 3.4 Programming the XMEGA through the USB gateway> Programming of the ATxmega128A1 through the USB is not supported in the> preliminary release.> Mein XPLAIN habe ich vor ca.2 Wochen bei Reichelt bestellt. Es ist ein> REV2 Board. Laut der Doku von Atmel sollte es schon REV4 geben.
zwischen Rev2 und Rev4 wurden laut AVR1907 nur einige Widerstände
ausgetauscht.
>> Laut Beschreibung hätte das ja schon ab Werk funktionieren sollen.>wie kommst du da drauf ?
AVR1921: Reprogramming the XPLAN AT90USB1287 and ATxmega128A1 firmware
Abschnitt 2.2: OK, da steht, dass man die Firmware des AT90USB1287 mit
Flip verändern kann, hat aber bei mir nicht funktioniert. Selbiges habe
ich auch schon in anderen Foren gelesen. Eigentlich hilft nur ein
JTAG-Programmer am Anfang.
Ging es bei Dir ohne?
Gute Anleitung, danke. Ich finde hilfreich, wenn sich in diesem Thread
nützliche Links sammeln, dann hat man alles an einem Platz.
Eine interessante Anwendung für das XPLAIN wäre die Ansteuerung eines
VGA Monitors. Hier gibt's schon eine Diskussion dazu:
Beitrag "xmega/xplain vga signal"
Hallo Zusammen,
mittlerweile bin ich dabei, das große 8MB RAM des XPLAIN anzusteuern.
Dazu habe ich einen Speichertest geschrieben, der einzelne Bytes
schreibt, zurück liest und auf die serielle Schnittstelle ausgibt ( die
Lufa-Bridge sollte installiert sein, sonst gibt es zu viele Fehler bei
der Anzeige ).
Einzelne Bytes zu schreiben und zu lesen funktioniert. Im Testprogramm
wird auch ein Block von 1MByte geschrieben und dann ein Block von 1MByte
gelesen ( seltsamerweise nur mit ca. 160KByte/Sec ).
Könnt Ihr euren Speicher mal testen und das Ergebnis mitteilen?
Klaus
Klaus schrieb:> Könnt Ihr euren Speicher mal testen und das Ergebnis mitteilen?
Kann leider deinen Code nicht test, weil mein Xplain das zeitliche
gesegnet hat. Ich habe mich aber auch mal mit der SD-Ram-Problematik
vertraut gemacht und gemerkt, dass man mit blockweisem Zugriff via
Assembler enormen Performancegewinn hat. Außerdem kann man via Assembler
den ganzen RAM addressieren. Hab den Code mal angehängt. Momentan testet
er den Ram auf Fehler. Es sind Assembler-Routinen zum lesen und
schreiben einzelner Bytes vorhanden, sowie Testen eines ganzer
64kB-Blöcke vorhanden. Die können aus C heraus aufgerufen werden.
Vorsich beim Zugriff! Der SD-RAM fängt erst bei Adresse 0x4000 an.
Gruß Skript Kiddy
Mit nachfolgendem Code teste ich den SDRAM per DMA. Wichtig ist dabei
erstmal den SDRAM komplett mit einem Muster zu füllen udn dann erst
wieder auszulesen. Eventuell noch dazwischen eine Zeitspanne lang zu
warten. Nur so stellt man sicher das das Umschalten der Bänke/Columns
auch getestet wird zwischen Schreiben und Lesen und das das Refresh
funktioniert.
Gruß Hagen
PS: auf meinem Biard benötigt man für die 8MByte schreiben, lesen und
überprüfen weniegr als 5 Sekunden.
1
uint8_tSDRAM_Test_DMA(void){
2
3
uint8_tflags;
4
uint8_tbuffer[512];
5
for(uint16_ti=0;i<512;i++){
6
buffer[i]=i;
7
}
8
9
// kopiere buffer per DMA in SDRAM, 512 * 128 * 128 = 8MByte
Hey, vielen Dank für eure Antworten. Ich habe schon befürchtet, es
beschäftigt sich keiner mit dem XPLAIN.
Ich hoffe, dass wir es in diesem Thread schaffen können, die
Basisbibliottheken für die Peripherie zusammen zu bekommen.
>Kann leider deinen Code nicht test, weil mein Xplain das zeitliche>gesegnet hat.
Oh schade, kaufst Du Dir ein Neues?
Ich habe auf mein XPLAIN den LUFA PDI-Programmer geflasht, funktioniert
super mit AVR-Studio uns ist schneller als JTAG.
Heute wollte ich aber trotzdem JTAG mit dem AVR-Dragon benutzen, weil
man dann parallel dazu die USB Schnittstelle als Seriel-Bridge verwenden
kann. Seltsamerweise ging es nicht mehr. Stellt der PDI-Programmer da
was ab?
der xmega is schon nett
aber im zuge der ganzen möglichkeiten ist der auch deutlich komplexer
geworden
ein Cortex M3 bietet das auch und ist genau so komplex ..
hat aber ne ganze ecke mehr rechenleistung
warum also auf einen 8bitter setzen wenn man einen 32bitter haben kann
der bei viel speicher sogar noch effizienter läuft
und nicht wirklich teurer ist ... siehe preise STM32F103 / LPC17xx usw
zudem sind die ARMs einfacher zu programmieren .. bzw gibt es adapter
die ex günstiger gibt als den PDI ...
damit hat sich Atmel iwie ein EI gelegt ... schade
der xmega ist in MEINEN augen eine totgeburt
er kam unglücklicherweise zu spät und im zuge des Cortex M3 herraus
2-3 jahre früher und er wäre viel verbreiteter
wenn die ersten libs mal ofiziell sind kommen vieleicht ein paar mehr
leute ..
ich selbst jedoch werde 8bitter bei kleinen sachen udn darüber gleich
einen cortex einsetzen ...
mitlerweile sind sogar Cortex M3 128k-256k günstiger zu haben als mega64
/ mega128 .... das gibt zu denken
nichts desto trotz ... viel spass mit den Xmega ...
schade drum .. die sind echt gut .. kamen leider zu spät
Klaus schrieb:> Oh schade, kaufst Du Dir ein Neues?
Natürlich! Ist schon unterwegs.
> Stellt der PDI-Programmer da> was ab?
Man kann mit einem Jumper einstellen, was man halt benutzen möchte
(AVRISP oder UART-Bridge). Das weißt du sicher. Die Auswahl wird beim
Starten des AT90USB1287 übernommen und kann während das Board mit
Spannung versorgt wird nicht geändert werden. Den Jumper kannst du zwar
im Betrieb umstecken, aber erst nach dem der AT90USB resettet wurde,
wird in den jeweiligen anderen Modus gewechselt. Bei mir hat das immer
mit der XPLAIN-Bridge von LUFA auf diese Weise funktioniert.
Beitrag "Re: xmega128 Xplain - Wie programmieren?"
Hast du auch die LUFA XPLAIN-Bridge oder blos eine ARVISP MKII firmware
drauf?
Hagen Re schrieb:> @Klaus, Script Kiddi:>> ihr initialisiert den SDRAM beide mit CLK_PER2 mit 32MHz obwohl der mit> 64MHz laufen würde:
Danke guter Tip. Werd ich mich mal genauer mit beschäftigen, wenn mein
neues XPLAIN da ist.
>Hast du auch die LUFA XPLAIN-Bridge oder blos eine ARVISP MKII firmware>drauf?
Beides. Ich nehme mal an, dass es die AVRISP MKII firmware gar nicht
ohne bridge gibt.
Ich habe mein Speichertestprogramm noch mal laufen lassen. Es ergibt
sich ein etwas seltsames Verhalten:
Beim ersten Durchlauf, wenn einzelne Bytes geschrieben und gelesen
werden, funktioniert alles.
Wenn aber der Test für 1MB schreiben und dann 1MB lesen durchgelaufen
ist, ergeben sich bei der Wiederholung des Byte-Test seltsame Fehler:
Zuerst sieht es so aus, als wenn nur noch die höherwertigen Bits richtig
gelesen werden. Beim wiederholten auslesen steht kommt dann aber nur
noch Müll.
Hat jemand von euch eine Erklärung dafür?
Moin,
schön das die Anzahl XPLAIN User steigt.
hier noch ein paar Anregungen, falls noch nicht gefunden:
Beitrag "48KB SDRam für gcc auf xplain"Beitrag "xmega + SDRAM + LIBC > 64K?"Beitrag "xMega EEPROM Memory-mapped"Klaus schrieb:> Ich hoffe, dass wir es in diesem Thread schaffen können, die> Basisbibliottheken für die Peripherie zusammen zu bekommen.
@Klaus
Wenn Interesse besteht, habe ich noch ein kleines Framework rund um das
XPLAIN. Dieses ist im April entstanden als Ich mit einem Klotz am Bein
im KKH lag. Könnte den Aufbau einer Bibliothek unterstützen. Wenn Du das
Teil haben möchtest meine Mail Adresse befindet sich, verpackt, in einem
der obigen links.
MfG
Hallo Sauger,
danke für Deine Beiträge. Ich habe die Initialisierungsroutine für das
SDRAM aus Deinem Beitrag "48K-SDRAM" in das obige Example übernommen.
Mein Ziel ist es, möglichst einfach Treiberfunktionen für das XPLAIN zu
haben ( so ähnlich wie im obigen Beispiel mit "writeFarSDRAM" ). Solche
Funktionen sind zwar langsamer als speziell angepasste Routinen, sind
aber eine große Erleichterung für den Einstieg.
Im Moment fehlen mir noch die Funktionen
initADC()
uint16_t readADC(uint8_t, channel);
Hast Du da vielleicht schon etwas?
Gruß,
Klaus
Hallo Sauger,
heute habe ich mich mit Deinen Xeeprom Routinen beschäftigt. Wow,
ungewöhnlicher Programmierstiel. Solche Konstrukte wie
void _attribute_ ((naked, section(".init0"))) XplainIO (void)
sind mir gänzlich unbekannt. Da kam ich beim meinen bisherigen
Programmen immer drum rum.
Warum hast Du eigentlich alle Funktionen in xeeprom.h gepackt?
Normalerweise hat man ja ein getrenntes C-File und nur die Definitionen
einer.h Datei werden in den anderen Files eingebunden. Falls man das
anderst macht, gibt es ja einen multiple definition error.
Dein oben gepostetes Beispiel lässt sich nicht kompilieren, da fehlen
einige Definitionen.
Die allgemeine Struktur Deines Beispielprogramms ist ansonsten so wie
ich es mir wünsche: einfach und übersichtlich.
Gruß,
Klaus
Moin,
ADC, nein brauchte Ich bislang nicht :-)
Klaus schrieb:> Warum hast Du eigentlich alle Funktionen in xeeprom.h gepackt?
static inline uint8_t EEpromReadByte(void *Src)
"inline" heißt das Zauberwort. GCC setzt den Code dann direkt ein und
macht keinen Funktionsaufruf. ReadByte wird so zu einem einfachen "LDS
r,Addr".
Klaus schrieb:> Falls man das anderst macht,
...
war nicht anders gedacht :-)
>Dein oben gepostetes Beispiel lässt sich nicht kompilieren, da fehlen>einige Definitionen.
welche?
Klaus schrieb:> Hier gibt es eine ausführliche Auflistung von XMEGA-Treibern:
nein. Das sind keine Treiber sondern Beispiele, die die Richtung zeigen
sollen. Sie sind nicht für den produktiven Einsatz gedacht.
MfG
Klaus schrieb:> Hier gibt es eine ausführliche Auflistung von XMEGA-Treibern:>> http://asf.atmel.no/xmega/drivers/readme.html
Dieses selbsternannte Framework ist eher lästig bei Eigenentwicklungen,
da sich Atmel ziemlich mit den Makefiles und Verzeichnissen verzettelt
hat. Aus irgendeinem Grund werden auch noch unterschiedliche MCUs (8-Bit
Xmegas und 32-Bit AT32UC3s) gemeinsam verwurstet.
Mehr als mal in den Quelltext dieser sogenannten "Treiber" reinschauen,
um dann selber was Vernünftiges zu schreiben, lohnt nicht.
Hallo Alle,
hier ein DEMO-Programm für den ADC des XPLAIN Boards.
Das Ziel war einen Treiber für den AD-Wandler zu schreiben, der so
einfach wie möglich funktioniert.
Viel Spaß damit,
Klaus
Hier habe ich ein Beispielprojekt für einen LogikAnalysator gefunden:
Beitrag "Logic Analyser mit Pollin CPLD Board"
Ich habe die Software auf 9600 Baud angepasst, jetzt geht's auch mit dem
XPLAIN.
Im Moment ist das Ganze noch etwas rudimentär. Es gibt nur eine
SamplingRate und den Speicher habe ich mal auf 128Byte begrenzt.
Aber wer's ausprobieren will: es funktioniert grundsätzlich, die
gesampelten Signale am XPLAIN Port D werden als Signalverlauf angezeigt.
Die Java-Software hat einen I2C Analysator eingebaut. Wenn man die
Speichergröße erhöht, könnte sich das XPLAIN tatsächlich als LA eignen.
Florian Grotz schrieb:> Hier mal einige Beispiele in C für den Xmega und Xplain.> http://www.stromflo.de/dokuwiki/doku.php?id=xmega-c-tutorial>> Gruß Flo
Gefällt mir im Wesentlichen, aber ich habe dazu ein paar Kritikpunkte
bzw. Anregungen.
Ein wichtige Sache vermisse ich im Kapitel 1.2.2.
Die "Bit Group Masks" und deren Verwendung im Beispiel für die Gruppen
Konfigurationen, wie im Code Listing 3-12 der Appnote AVR1000
beschrieben.
Siehe Kapitel 3.4.2 und 3.5 der o.g. Appnote.
Wer den Kommentar zum Listing 3-12 der Appnote gelesen hat wird
erkennen, dass Beispiel für _gc nur unter ganz bestimmten
Vorraussetzungen funktionieren wird. Lieber kein Beispiel als ein
Schlechtes, oder im schlimmsten Fall sogar Falsches.
Zudem wird gleich im folgenden Beispiel für die Einstellung von 32Mhz
(Kapitel 2.1) das oben gesagte wieder völlig ignoriert und numerische
Werte verwendet statt der _bm und _gc Makros.
Und wenn schon auf Veröffentlichungsrechte hingewiesen wird, sollten
auch Literaturverweise (z.B. Appnote AVR1000) nicht fehlen.
Gruß
Werner
Hallo Leute,
ich habe hier nun eine Menge zum Xplain Board mit dem Xmega gelesen.
Leider werde ich aus manchen Dingen einfach nicht schlau.
Ich würde gerne über einen Kanal ADC-Wandlung machen und in mein SDRAM
schreiben. Später lese ich die Werte wieder aus und verwende sie für
einen Algorithmus. Wichtig für mich, dass die ADC-Wandlung und das
Schreiben in den SDRAM so schnell es geht funktioniert.
Hat das vllt schon jemand gemacht? Oder ist das überhaupt möglich???
Falls jemand einen Bsp-Code hat...
Gruß Joe
Ich hab auch ein Xplain-Board (seit Samstag) und gleich ein problem ...
Ich kann den Xmega128a1 der drauf ist einfach nicht per AVR-Dragon
Programmieren (er liest nichmal die fuses)...
wenn cih im avr-Studio (4.18 SP3) auf irgendwas geh was Verbindung
braucht kommt ein fehler: erst fragt er nach ob ich mit externem reset
nochmal versuchen will (k.A. warum) und egal ob ich nein oder ja nehm
kommt dann ein "Jtag mode error"...
weis vlt. jemand was da los ist ?
PS: Ich hab den jtag stecker nicht falschrum oder an dem falsche header
aufgesteckt...
PPS: Den AT90USB1287 kann ich ganz normal lesen (schreiben trau ich mich
nich)...
Mal ne Frage: Wenn ich dieses LUFA-Dingen einsetze um das xplain Board
wie einen Programmer anzusprechen, gibt es dann einen Weg zurück?
Ich frage deshalb, weil ich in Kürze einen AVR-JTAG-ICE bekomme, und als
Greenhorn einfach keine Ahnung davon habe, ob das die Funktion des
JTAG-ICE beeinträchtigen würde?
Oder sehe ich das richtig, dass die JTAG Schnittstelle sich gar nicht um
die LUFA-Bridge schert, und ich damit sowieso auf dem xplain-board
rumrödeln kann, wie ich will?
Ich bin zwar auch nur ein Anfänger in den Dingen, aber ich hatte genauso
wie du, erst das LUFA Projekt drauf und mir dann den Jtag ICE mkII
geholt. Das LUFA Projekt hat natürlich keine Einfluss auf die
Programmierung des XMEGA. Das LUFA-Projekt flasht lediglich den AT....
(USB-Baustein), hat also mit dem XMEGA nichts zu tun.
Gruß Joe
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