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?
Das Phänomen kenn ich. Einfach den Verstärker abschalten und es ist weg.
Der hier gibt es seinem Xplain etwas heftiger, nicht nur ein Rechteck: http://www.youtube.com/watch?v=EJ-6T3Kugt8
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
Na ja die zeitrelevanten Sachen sind schon in Assembler. Aber weil es schnell geht, habe ich den Rest in Basic gemacht.
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?
Kleine Merker: Zum XmegaDuino-Projekt http://code.google.com/p/xmegaduino/ gibt es einige brauchbare Libraries http://code.google.com/p/xmlibraries/downloads/list
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.
Hallo, hier könnt Ihr den C64 SID-Emulator auf eurem XPLAIN laufen lassen: http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=123 Ist sozusagen ein kleiner Synthesizer ... Viel Spaß, chris
> 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?
> Eigentlich hilft nur ein JTAG-Programmer am Anfang. > Ging es bei Dir ohne? ja, ohne Probleme http://www.xplainer.org/index.php?option=com_content&view=article&id=5:installing-lufa&catid=2:how-to&Itemid=2 mit dieser Anleitung.
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
@Klaus, Script Kiddi: ihr initialisiert den SDRAM beide mit CLK_PER2 mit 32MHz obwohl der mit 64MHz laufen würde: Gruß Hagen
1 | // EBI
|
2 | PORTH.DIR = 0xFF; |
3 | PORTK.DIR = 0xFF; |
4 | PORTJ.DIR = 0xF0; |
5 | |
6 | // Taktsystem konfigurieren
|
7 | // - 32MHz CLK_CPU, 64MHz CLK_PERx2, 128MHz CLK_PERx4
|
8 | // - 32MHz RC-Osc füttert PLL
|
9 | // - 2MHz+32MHz Osc eingeschaltet
|
10 | // - 32KHz RTC Quartz eingeschaltet im Low Power Mode
|
11 | // - beide DFLLs eingeschaltet
|
12 | |
13 | // externen 32KHz Quarz im Lowpower Modus einschalten
|
14 | OSC.XOSCCTRL = OSC_X32KLPM_bm | OSC_XOSCSEL_32KHz_gc; |
15 | // PLL Source = 32MHz interner RC-Osc / 4 * 16 = 128 MHz
|
16 | OSC.PLLCTRL = OSC_PLLSRC_RC32M_gc | (16 << OSC_PLLFAC_gp); |
17 | // CLK-Prescaler A/1 B/2 C/2 -> 128MHz -> 64MHz -> 32MHz
|
18 | CCPWrite(&CLK.PSCTRL, CLK_PSADIV_1_gc | CLK_PSBCDIV_2_2_gc); |
19 | // 32MHz, 2MHz, ext. 32KHz RTC und PLL aktivieren
|
20 | OSC.CTRL = OSC_RC32MEN_bm | OSC_RC2MEN_bm | OSC_XOSCEN_bm | OSC_PLLEN_bm; |
21 | while ((OSC.STATUS & (OSC_RC32MRDY_bm | OSC_RC2MRDY_bm | OSC_XOSCRDY_bm | OSC_PLLRDY_bm)) != |
22 | (OSC_RC32MRDY_bm | OSC_RC2MRDY_bm | OSC_XOSCRDY_bm | OSC_PLLRDY_bm)) ; |
23 | // PLL nun als Systemclock auswählen
|
24 | CCPWrite(&CLK.CTRL, CLK_SCLKSEL_PLL_gc); |
25 | // DFLL Kalibration vom 2MHz und 32MHz RC-Osc mit externem 32KHz Uhrenquarz
|
26 | OSC.DFLLCTRL = OSC_RC32MCREF_bm | OSC_RC2MCREF_bm; |
27 | DFLLRC2M.CTRL = DFLL_ENABLE_bm; |
28 | DFLLRC32M.CTRL = DFLL_ENABLE_bm; |
29 | // nun CLK Einstellungen schützen
|
30 | CCPWrite(&CLK.LOCK, CLK_LOCK_bm); |
31 | |
32 | // CLK_PER = CLK_CPU an PE7 ausgeben
|
33 | PORTE.DIR = 0x80; |
34 | PORTCFG.CLKEVOUT = PORTCFG_CLKOUT_PE7_gc; |
35 | |
36 | // RTC einschalten mit 1KHz Takt aus externem Uhrenquarz
|
37 | CLK.RTCCTRL = CLK_RTCSRC_TOSC_gc | CLK_RTCEN_bm; |
38 | while (RTC.STATUS & RTC_SYNCBUSY_bm) ; |
39 | RTC.INTCTRL = RTC_OVFINTLVL_LO_gc | RTC_COMPINTLVL_OFF_gc; |
40 | RTC.PER = 0; |
41 | RTC.CTRL = RTC_PRESCALER_DIV1024_gc; |
42 | |
43 | // externen SDRAM 8MByte konfigurieren
|
44 | EBI.CTRL = EBI_SDDATAW_4BIT_gc | EBI_IFMODE_3PORT_gc; |
45 | EBI.SDRAMCTRLA = EBI_SDROW_bm | EBI_SDCOL_10BIT_gc; |
46 | EBI.SDRAMCTRLB = EBI_MRDLY_2CLK_gc | EBI_ROWCYCDLY_1CLK_gc | EBI_RPDLY_3CLK_gc; |
47 | EBI.SDRAMCTRLC = EBI_WRDLY_2CLK_gc | EBI_ESRDLY_5CLK_gc | EBI_ROWCOLDLY_1CLK_gc; |
48 | EBI.REFRESH = 1000; // max. 1023, max. 15.625us, 1/64MHz*1000=15.625us * 4096 = 64ms |
49 | EBI.INITDLY = 6400; // max. 16383, min. 100us, 1/64MHz*6400=100us |
50 | EBI.CS3.CTRLA = EBI_CS_ASPACE_8MB_gc | EBI_CS_MODE_SDRAM_gc; |
51 | EBI.CS3.CTRLB = EBI_CS_SDMODE_NORMAL_gc; |
52 | EBI.CS3.BASEADDR = SDRAM_ADDR >> 8; |
53 | while (!(EBI.CS3.CTRLB & EBI_CS_SDINITDONE_bm)); |
54 | |
55 | PMIC.CTRL = PMIC_LOLVLEN_bm | PMIC_MEDLVLEN_bm | PMIC_HILVLEN_bm; |
56 | |
57 | sei(); |
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_t SDRAM_Test_DMA(void) { |
2 | |
3 | uint8_t flags; |
4 | uint8_t buffer[512]; |
5 | for (uint16_t i = 0; i < 512; i++) { |
6 | buffer[i] = i; |
7 | }
|
8 | |
9 | // kopiere buffer per DMA in SDRAM, 512 * 128 * 128 = 8MByte
|
10 | DMA.CTRL = DMA_ENABLE_bm; |
11 | DMA.CH0.SRCADDR0 = (((uint32_t)&buffer) >> 0*8 ) & 0xFF; |
12 | DMA.CH0.SRCADDR1 = (((uint32_t)&buffer) >> 1*8 ) & 0xFF; |
13 | DMA.CH0.SRCADDR2 = (((uint32_t)&buffer) >> 2*8 ) & 0xFF; |
14 | DMA.CH0.DESTADDR0 = (((uint32_t)SDRAM_ADDR) >> 0*8 ) & 0xFF; |
15 | DMA.CH0.DESTADDR1 = (((uint32_t)SDRAM_ADDR) >> 1*8 ) & 0xFF; |
16 | DMA.CH0.DESTADDR2 = (((uint32_t)SDRAM_ADDR) >> 2*8 ) & 0xFF; |
17 | DMA.CH0.ADDRCTRL = DMA_CH_SRCRELOAD_BLOCK_gc | DMA_CH_SRCDIR_INC_gc | DMA_CH_DESTRELOAD_NONE_gc | DMA_CH_DESTDIR_INC_gc; |
18 | DMA.CH0.TRFCNT = 512; |
19 | |
20 | for (uint8_t i = 0; i < 128; i++) { |
21 | DMA.CH0.CTRLA |= DMA_CH_ENABLE_bm; |
22 | DMA.CH0.REPCNT = 128; |
23 | DMA.CH0.CTRLA |= DMA_CH_REPEAT_bm | DMA_CH_BURSTLEN_8BYTE_gc | DMA_CH_TRFREQ_bm; |
24 | do { |
25 | flags = DMA.CH0.CTRLB & (DMA_CH_ERRIF_bm | DMA_CH_TRNIF_bm); |
26 | } while (flags == 0); |
27 | DMA.CH0.CTRLB |= DMA_CH_ERRIF_bm | DMA_CH_TRNIF_bm; |
28 | if (flags & DMA_CH_ERRIF_bm) return 1; |
29 | }
|
30 | |
31 | uint8_t* bufrd = 0; |
32 | uint8_t* bufwr = &buffer[0]; |
33 | |
34 | DMA.CH0.SRCADDR0 = (((uint32_t)SDRAM_ADDR) >> 0*8 ) & 0xFF; |
35 | DMA.CH0.SRCADDR1 = (((uint32_t)SDRAM_ADDR) >> 1*8 ) & 0xFF; |
36 | DMA.CH0.SRCADDR2 = (((uint32_t)SDRAM_ADDR) >> 2*8 ) & 0xFF; |
37 | DMA.CH0.ADDRCTRL = DMA_CH_SRCRELOAD_NONE_gc | DMA_CH_SRCDIR_INC_gc | DMA_CH_DESTRELOAD_NONE_gc | DMA_CH_DESTDIR_INC_gc; |
38 | DMA.CH0.TRFCNT = 256; |
39 | |
40 | for (uint16_t j = 0; j < 32768; j++) { |
41 | DMA.CH0.DESTADDR0 = (((uint32_t)bufwr) >> 0*8 ) & 0xFF; |
42 | DMA.CH0.DESTADDR1 = (((uint32_t)bufwr) >> 1*8 ) & 0xFF; |
43 | DMA.CH0.DESTADDR2 = (((uint32_t)bufwr) >> 2*8 ) & 0xFF; |
44 | DMA.CH0.CTRLA |= DMA_CH_ENABLE_bm; |
45 | DMA.CH0.CTRLA |= DMA_CH_BURSTLEN_8BYTE_gc | DMA_CH_TRFREQ_bm; |
46 | |
47 | if (bufrd) { |
48 | uint8_t i = 0; |
49 | while (1) { |
50 | if (bufrd[i] != i) { |
51 | return 2; |
52 | }
|
53 | if (++i == 0) break; |
54 | }
|
55 | } else { |
56 | bufrd = &buffer[256]; |
57 | }
|
58 | |
59 | do { |
60 | flags = DMA.CH0.CTRLB & (DMA_CH_ERRIF_bm | DMA_CH_TRNIF_bm); |
61 | } while (flags == 0); |
62 | DMA.CH0.CTRLB |= DMA_CH_ERRIF_bm | DMA_CH_TRNIF_bm; |
63 | if (flags & DMA_CH_ERRIF_bm) return 3; |
64 | |
65 | uint8_t* buftmp = bufrd; |
66 | bufrd = bufwr; |
67 | bufwr = buftmp; |
68 | }
|
69 | |
70 | return 0; |
71 | }
|
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
Hier gibt es eine ausführliche Auflistung von XMEGA-Treibern: http://asf.atmel.no/xmega/drivers/readme.html
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.
sie stören sogar und man ist mit den, hm düftigeren und ungewohnten Datenblättern besser bedient.
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
Angehängte Dateien:
-
logikAnalyzer.png
26 KB
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.
Hier ein erster Port von UBasic-AVR auf das Xplain-Board: http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=123&p=519
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
Hallo Flo, gut gemachte Anleitung, hätte ich früher gebrauchen können. Gruß, chris
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
> uBasic ..... Jetzt gibt es ein kleines Update: Lautsprecher, LEDs und ADC werden angesprochen : http://www.hobby-roboter.de/forum/viewtopic.php?f=4&t=123&p=519 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"
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)...
Edit : Ich bin grad auf die idee gekommen nen neuen thread aufzumachen (nachdem ich die rulez gelsen hatte): Beitrag "Problem mit dragon und xplain"
Aus den Release Notes für AVRStudion 4.18 SP3 (http://www.atmel.no/beta_ware/avrstudio418/b716/releasenotes.txt) > 11404 - AVRDragon should only work with the A4 and newer xmega devices"
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_content&view=article&id=5:installing-lufa&catid=2:how-to&Itemid=2 Gruß Joe
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
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.