Hallo Dies hier ist mein erstes Testprogramm mit dem Xmega128A1. Meine Entwicklungsumgebung ist die Experimentierplatine hier aus diesem Forum von Michael G. Sinn des Progrämmchens ist die PORTS A..D in der alt gewohnten Weise (wie im ATmega/ATtiny) anzusprechen. Hoffentlich hilft es anderen Ensteigern in der Welt der Xmegas weiter. Wer ebenfalls kleine Testprogramme für die Nutzung der Periferie des Xmega's in ASSEMBLER (und ich meine nur in ASM!!!) hat, kann sie gerne hierher posten. Steffen H.
Schön. Allerdings ist das Nutzen der Virtual Ports keine Pflicht. Die GPIOs lassen sich auch direkt, ohne Virtual Port ansteuern. Nicht, dass sich da einer verhaspelt ;)
Ja schon, aber halt nicht mehr wie wir es bei den ATmega oder ATtiny kennen. Die Befehle sbi, cbi, in und out gehen ja nur im den oberen 64 Registern, oder täusch ich mich da?
Ach so :D So weit bin ich in dem Assembler Kram nicht drin. Ja, kann gut sein!
Mag sein, aber wozu braucht man gerade bei den IO Ports noch sbi & co? Es gibt dafür extra tolle Register
Die 'sbi' und 'cbi' - Befehle sind schneller; 'sbis' und 'sbic' ebenfalls. Das macht sich besonders bei Software-Schnittstellen gut.
Es sollte ja auch für diejenigen sein die schon mit den Megas oder Tinys gearbeitet haben, um einen schnelleren Einstieg in die Welt der Xmegas zu bekommen. Ich persönlich hatte jedenfalls so meine Probleme mit den vielen Registern der I/O Ports (jeder Port mit 21 Stück an der Zahl). @Markus Welche tollen Register sollen das sein? Wie kann man denn sonst so einfach ein einzelnes Bit im Port ändern? Ohne Frage hat man mit dem Xmega wahnsinnig viele Möglichkeiten. Kann aber auch manchmal sehr verwirren. Super finde ich auch das Tongeln der Pins..
Steffen H. schrieb: > @Markus > Welche tollen Register sollen das sein? Wie kann man denn sonst so > einfach ein einzelnes Bit im Port ändern? OUTSET, OUTCLR, OUTTGL. Gleiches gibts auch für DDR. Hab ich schonmal drüber geschrieben. http://blog.elektronik-projekt.de/2009/08/xmega-weitere-eindrucke-der-atxmega32a4/ So lange man nur einzelne Bits zu setzten hat hat man vielleicht keinen Vorteil. Aber sobald man zwei Bits setzen will spart man Befehle
Das Speichern in die Register mittels 'sts' braucht trotzdem 2 Taktzyklen, 'sbi' und 'cbi' nur einen.
Für einzelne Bits geb ich dir Recht. Bei 2 Bits ist Gleichstand. Alles darüber verlieren die virtuellen Register
Also mit sbi oder cbi kann ich auch mehrere Bits mittels "|" Operator gleichzeitig setzen. z.B. sbi PORTB, Bit1 | Bit3 | Bit6
Steffen H. schrieb: > Also mit sbi oder cbi kann ich auch mehrere Bits mittels "|" Operator > gleichzeitig setzen. > > z.B. > sbi PORTB, Bit1 | Bit3 | Bit6 Würde mich interessieren, wie das gehen soll. Bei dem sbi Befehl sind im Opcode nur 3 Bit für die Bitposition reserviert. Wenn der Assembler sowas erlaubt macht er sicher eine entsprechende Anzahl an Befehlen daraus. Aber sbi kann immer nur EIN Bit setzen
Das geht höchstens mit sbr, was nur ein Alias für ori ist.
Asche auf mein Haupt! Ihr habt Recht. Das geht wirklich nur mir sbr / cbr.
Ich habe nun mal den Drehimpulsgeber mittels des internen Quadraturencoders im Xmega ausprobiert. Funktioniert prima.. Im Anhang das Test-Programm zur AT XMega128A1 Experimentierplatine von Michael G. Mfg Steffen
Hallo Asm Freunde :-) Die Funktionen aus der AppNote wurden von C nach Asm. portiert. “AVR1003 Using the XMEGA Clock System” Kann leider kein C , deswege der Aufwand. Gruß gtf
So, hab die PLL mal getestet. Das Ergebnis ist ernüchternd. Laut Datasheet kann man ja angeblich bis auf 200Mhz gehen. Ich bekomm sie gerade mal bis auf 48Mhz.. Hat schon mal jemand mehr als 48Mhz rausholen können?
Angehängte Dateien:
-
TFT_XMega1.jpg
100 KB -
TFT_XMega2.jpg
260 KB
Hab es geschafft ein 320x240 16bit TFT anzusteuern. Das TFT kommt ohne
Vsync und Hsync aus. Daten laufen im Format 16bit Farbwert (555) über
PortC und PortE direkt ans Display. Event_Ch0 steuert den Zugriff auf
das SDRAM welches am EBI im 3PORT-Mode hängt und die Pixeldaten liefert.
Der Event_Ch0 wird aus DCLK und DTMG gebildet. Dazu hab ich ein NAND
(74LVC00) mit 1A->DCLK und 1B->DTMG paralell angeschlossen. Der Ausgang
des Gatters geht an PortD.2
Falls diesen Beitrag Benedikt liest, hat er sicherlich noch einige
Verbesserungsvorschläge. Am liebsten hätt ich die Datenleitungen des
TFT´s natürlich lieber am EBI hängen. Allerdings hab ich noch keine
Ahnung WIE!?
Als Testboard verwende ich das von Michael G. (Nur falls jemand
überlegt, wie denn nun der SDRAM angeschlossen ist)
TFT-Steuerleitungen: TFT-Daten: (NAND-Eingänge) (NAND-Ausgang)
DCLK-> an PortD.0 PORT_C Port_E 1A->PortD.0 1Y->PortD.2
DTGM->PortD.4 0->R1 0->G4 1B->PortD.4
1->R2 1->G5
2->R3 2->B1
3->R4 3->B2
4->R5 4->B3
5->G1 5->B4
6->G2 6->B5
7->G3 7->NC
Gruß
Steffen H.
Hab ich doch ganz das Codebeispiel vergessen ;) Zusätzlich hab ich auch noch einen BMP Converter mit in das Archiv gepackt mit dem man 24bit bmp Bilder in 16bit RGB (565) c-Code oder 16bit RGB (555) c-code erstellen kann. So, nun aber..
Steffen H. schrieb: > So, hab die PLL mal getestet. Das Ergebnis ist ernüchternd. Laut > Datasheet kann man ja angeblich bis auf 200Mhz gehen. Ich bekomm sie > gerade mal bis auf 48Mhz.. > > Hat schon mal jemand mehr als 48Mhz rausholen können? Die PLL kann 200Mhz, die CPU aber nicht. Da mußt Du dann einen Preschaler hinter die PLL schalten, daß Du unter 40MHz bleibst. Über 40MHz wird ein XMega instabil, abhängig von Spannung und Temperatur.
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.