XMEGA/ AVR-EXPLAIN code examples und Diskussion

[Klaus (Gast)]

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?t...

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

[Martin e. C. (eduardo)]

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

[Klaus (Gast)]

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?

[Oliver Ju. (skriptkiddy)]

Das Phänomen kenn ich. Einfach den Verstärker abschalten und es ist weg.

[Hannes Jaeger (pnuebergang)]

Der hier gibt es seinem Xplain etwas heftiger, nicht nur ein Rechteck:

Youtube-Video "Xplain - my demo for Dac on Xmega -  Atmel.AVI"

[Reader (Gast)]

hier mal eine Sound Anwendung in BASCOM

[Klaus (Gast)]

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

[Reader (Gast)]

Na ja die zeitrelevanten Sachen sind schon in Assembler.
Aber weil es schnell geht, habe ich den Rest in Basic gemacht.

[Klaus (Gast)]

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.

[Klaus (Gast)]

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?

[Klaus (Gast)]

Kleine Merker: Zum XmegaDuino-Projekt
http://code.google.com/p/xmegaduino/

gibt es einige brauchbare Libraries
http://code.google.com/p/xmlibraries/downloads/list

[Reader (Gast)]

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

[Klaus (Gast)]

>> 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.

[chris (Gast)]

Hallo,

hier könnt Ihr den C64 SID-Emulator auf eurem XPLAIN laufen lassen:

http://www.hobby-roboter.de/forum/viewtopic.php?f=...

Ist sozusagen ein kleiner Synthesizer ...

Viel Spaß,
chris

[Reader (Gast)]

> 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.

[Klaus (Gast)]

>> 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?

[Reader (Gast)]

> Eigentlich hilft nur ein JTAG-Programmer am Anfang.
> Ging es bei Dir ohne?

ja, ohne Probleme

http://www.xplainer.org/index.php?option=com_conte...

mit dieser Anleitung.

[Klaus (Gast)]

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"

[Klaus (Gast)]

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

[Oliver Ju. (skriptkiddy)]

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

[Hagen Re (hagen)]

@Klaus, Script Kiddi:

ihr initialisiert den SDRAM beide mit CLK_PER2 mit 32MHz obwohl der mit 
64MHz laufen würde:

Gruß Hagen

// EBI PORTH.DIR = 0xFF; PORTK.DIR = 0xFF; PORTJ.DIR = 0xF0; // Taktsystem konfigurieren // - 32MHz CLK_CPU, 64MHz CLK_PERx2, 128MHz CLK_PERx4 // - 32MHz RC-Osc füttert PLL // - 2MHz+32MHz Osc eingeschaltet // - 32KHz RTC Quartz eingeschaltet im Low Power Mode // - beide DFLLs eingeschaltet // externen 32KHz Quarz im Lowpower Modus einschalten OSC.XOSCCTRL = OSC_X32KLPM_bm | OSC_XOSCSEL_32KHz_gc; // PLL Source = 32MHz interner RC-Osc / 4 * 16 = 128 MHz OSC.PLLCTRL = OSC_PLLSRC_RC32M_gc | (16 << OSC_PLLFAC_gp); // CLK-Prescaler A/1 B/2 C/2 -> 128MHz -> 64MHz -> 32MHz CCPWrite(&CLK.PSCTRL, CLK_PSADIV_1_gc | CLK_PSBCDIV_2_2_gc); // 32MHz, 2MHz, ext. 32KHz RTC und PLL aktivieren OSC.CTRL = OSC_RC32MEN_bm | OSC_RC2MEN_bm | OSC_XOSCEN_bm | OSC_PLLEN_bm; while ((OSC.STATUS & (OSC_RC32MRDY_bm | OSC_RC2MRDY_bm | OSC_XOSCRDY_bm | OSC_PLLRDY_bm)) != (OSC_RC32MRDY_bm | OSC_RC2MRDY_bm | OSC_XOSCRDY_bm | OSC_PLLRDY_bm)) ; // PLL nun als Systemclock auswählen CCPWrite(&CLK.CTRL, CLK_SCLKSEL_PLL_gc); // DFLL Kalibration vom 2MHz und 32MHz RC-Osc mit externem 32KHz Uhrenquarz OSC.DFLLCTRL = OSC_RC32MCREF_bm | OSC_RC2MCREF_bm; DFLLRC2M.CTRL = DFLL_ENABLE_bm; DFLLRC32M.CTRL = DFLL_ENABLE_bm; // nun CLK Einstellungen schützen CCPWrite(&CLK.LOCK, CLK_LOCK_bm); // CLK_PER = CLK_CPU an PE7 ausgeben PORTE.DIR = 0x80; PORTCFG.CLKEVOUT = PORTCFG_CLKOUT_PE7_gc; // RTC einschalten mit 1KHz Takt aus externem Uhrenquarz CLK.RTCCTRL = CLK_RTCSRC_TOSC_gc | CLK_RTCEN_bm; while (RTC.STATUS & RTC_SYNCBUSY_bm) ; RTC.INTCTRL = RTC_OVFINTLVL_LO_gc | RTC_COMPINTLVL_OFF_gc; RTC.PER = 0; RTC.CTRL = RTC_PRESCALER_DIV1024_gc; // externen SDRAM 8MByte konfigurieren EBI.CTRL = EBI_SDDATAW_4BIT_gc | EBI_IFMODE_3PORT_gc; EBI.SDRAMCTRLA = EBI_SDROW_bm | EBI_SDCOL_10BIT_gc; EBI.SDRAMCTRLB = EBI_MRDLY_2CLK_gc | EBI_ROWCYCDLY_1CLK_gc | EBI_RPDLY_3CLK_gc; EBI.SDRAMCTRLC = EBI_WRDLY_2CLK_gc | EBI_ESRDLY_5CLK_gc | EBI_ROWCOLDLY_1CLK_gc; EBI.REFRESH = 1000; // max. 1023, max. 15.625us, 1/64MHz*1000=15.625us * 4096 = 64ms EBI.INITDLY = 6400; // max. 16383, min. 100us, 1/64MHz*6400=100us EBI.CS3.CTRLA = EBI_CS_ASPACE_8MB_gc | EBI_CS_MODE_SDRAM_gc; EBI.CS3.CTRLB = EBI_CS_SDMODE_NORMAL_gc; EBI.CS3.BASEADDR = SDRAM_ADDR >> 8; while (!(EBI.CS3.CTRLB & EBI_CS_SDINITDONE_bm)); PMIC.CTRL = PMIC_LOLVLEN_bm | PMIC_MEDLVLEN_bm | PMIC_HILVLEN_bm; sei();

[Hagen Re (hagen)]

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.

uint8_t SDRAM_Test_DMA(void) { uint8_t flags; uint8_t buffer[512]; for (uint16_t i = 0; i < 512; i++) { buffer[i] = i; } // kopiere buffer per DMA in SDRAM, 512 * 128 * 128 = 8MByte DMA.CTRL = DMA_ENABLE_bm; DMA.CH0.SRCADDR0 = (((uint32_t)&buffer) >> 0*8 ) & 0xFF; DMA.CH0.SRCADDR1 = (((uint32_t)&buffer) >> 1*8 ) & 0xFF; DMA.CH0.SRCADDR2 = (((uint32_t)&buffer) >> 2*8 ) & 0xFF; DMA.CH0.DESTADDR0 = (((uint32_t)SDRAM_ADDR) >> 0*8 ) & 0xFF; DMA.CH0.DESTADDR1 = (((uint32_t)SDRAM_ADDR) >> 1*8 ) & 0xFF; DMA.CH0.DESTADDR2 = (((uint32_t)SDRAM_ADDR) >> 2*8 ) & 0xFF; DMA.CH0.ADDRCTRL = DMA_CH_SRCRELOAD_BLOCK_gc | DMA_CH_SRCDIR_INC_gc | DMA_CH_DESTRELOAD_NONE_gc | DMA_CH_DESTDIR_INC_gc; DMA.CH0.TRFCNT = 512; for (uint8_t i = 0; i < 128; i++) { DMA.CH0.CTRLA |= DMA_CH_ENABLE_bm; DMA.CH0.REPCNT = 128; DMA.CH0.CTRLA |= DMA_CH_REPEAT_bm | DMA_CH_BURSTLEN_8BYTE_gc | DMA_CH_TRFREQ_bm; do { flags = DMA.CH0.CTRLB & (DMA_CH_ERRIF_bm | DMA_CH_TRNIF_bm); } while (flags == 0); DMA.CH0.CTRLB |= DMA_CH_ERRIF_bm | DMA_CH_TRNIF_bm; if (flags & DMA_CH_ERRIF_bm) return 1; } uint8_t* bufrd = 0; uint8_t* bufwr = &buffer[0]; DMA.CH0.SRCADDR0 = (((uint32_t)SDRAM_ADDR) >> 0*8 ) & 0xFF; DMA.CH0.SRCADDR1 = (((uint32_t)SDRAM_ADDR) >> 1*8 ) & 0xFF; DMA.CH0.SRCADDR2 = (((uint32_t)SDRAM_ADDR) >> 2*8 ) & 0xFF; DMA.CH0.ADDRCTRL = DMA_CH_SRCRELOAD_NONE_gc | DMA_CH_SRCDIR_INC_gc | DMA_CH_DESTRELOAD_NONE_gc | DMA_CH_DESTDIR_INC_gc; DMA.CH0.TRFCNT = 256; for (uint16_t j = 0; j < 32768; j++) { DMA.CH0.DESTADDR0 = (((uint32_t)bufwr) >> 0*8 ) & 0xFF; DMA.CH0.DESTADDR1 = (((uint32_t)bufwr) >> 1*8 ) & 0xFF; DMA.CH0.DESTADDR2 = (((uint32_t)bufwr) >> 2*8 ) & 0xFF; DMA.CH0.CTRLA |= DMA_CH_ENABLE_bm; DMA.CH0.CTRLA |= DMA_CH_BURSTLEN_8BYTE_gc | DMA_CH_TRFREQ_bm; if (bufrd) { uint8_t i = 0; while (1) { if (bufrd[i] != i) { return 2; } if (++i == 0) break; } } else { bufrd = &buffer[256]; } do { flags = DMA.CH0.CTRLB & (DMA_CH_ERRIF_bm | DMA_CH_TRNIF_bm); } while (flags == 0); DMA.CH0.CTRLB |= DMA_CH_ERRIF_bm | DMA_CH_TRNIF_bm; if (flags & DMA_CH_ERRIF_bm) return 3; uint8_t* buftmp = bufrd; bufrd = bufwr; bufwr = buftmp; } return 0; }

[Klaus (Gast)]

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?

[roflkartoffel (Gast)]

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

[Oliver Ju. (skriptkiddy)]

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.

[Klaus (Gast)]

>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?

[Sauger (Gast)]

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

[Klaus (Gast)]

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

[Klaus (Gast)]

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

[Klaus (Gast)]

Hier gibt es eine ausführliche Auflistung von XMEGA-Treibern:

http://asf.atmel.no/xmega/drivers/readme.html

[Sauger (Gast)]

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

[Hannes Jaeger (pnuebergang)]

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.

[Hagen Re (hagen)]

sie stören sogar und man ist mit den, hm düftigeren und ungewohnten 
Datenblättern besser bedient.

[Klaus (Gast)]

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

[Klaus (Gast)]

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.

[Klaus (Gast)]

Gute Webseite, wie man das XPLAIN in Assembler programmiert:

http://ax-hpage.de/xplain.html

[chris (Gast)]

Hier ein erster Port von UBasic-AVR auf das Xplain-Board:

http://www.hobby-roboter.de/forum/viewtopic.php?f=...

[Florian G. (stromflo)]

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

[chris (Gast)]

Hallo Flo,

gut gemachte Anleitung, hätte ich früher gebrauchen können.

Gruß,
chris

[Werner B. (werner-b)]

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

[chris (Gast)]

> uBasic .....

Jetzt gibt es ein kleines Update: Lautsprecher, LEDs und ADC werden 
angesprochen :
http://www.hobby-roboter.de/forum/viewtopic.php?f=...

Ist aber eine ziemlich experimentelle Sachen. Wer will, kann es weiter 
entwickeln. Hauptsächlich fehlt ein Editor.

Hauptthread uBasic: Beitrag "Basic-Interpreter auf einem AVR"

[Joe F. (joe1234)]

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

[Max (Gast)]

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)...

[Max (Gast)]

Edit :
Ich bin grad auf die idee gekommen nen neuen thread aufzumachen (nachdem 
ich die rulez gelsen hatte):
Beitrag "Problem mit dragon und xplain"

[Werner B. (werner-b)]

Aus den Release Notes für AVRStudion 4.18 SP3
(http://www.atmel.no/beta_ware/avrstudio418/b716/re...)

> 11404 - AVRDragon should only work with the A4 and newer xmega devices"

[Joe F. (joe1234)]

Versuche einfach mal AVR Studio 4.18 SP2. Ich denke dann geht's.
Oder Nutze dieses LUFA Projekt. Damit geht es bei mir auch.
Link:
http://www.xplainer.org/index.php?option=com_conte...


Gruß Joe

[E. Hermanns (emax)]

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?

[Joe F. (joe1234)]

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