Ausgehend vom Beispiel Virtuelle Ports im XMEGA-Tutorial von Florian Grotz habe ich eine Ansteurung meines GLCD-Displays durch einen XMEGA128A1 wesentlich beschleunigt. Dabei habe ich bemerkt, dass der Compiler virtuelle Port-Zugriffe nicht immer optimal übersetzt, deshalb habe ich dafür asm-Anweisungen aus der lss-Datei verwendet. Näheres siehe die angehängte Datei
Wenn du schon am optimieren bist kannst du dir ja auch mal ansehen was der Compiler jeweils aus
1 | ch = (dw >> 8); |
und
1 | ch = ((dw & 0xFF00) >> 8); |
macht ;-)
Mein Gott, immer diese C- Probleme... Setzt Euch auf den Hosenboden und lernt ASM! Schneller,kompakter und 1/10 Schreibaufwand.
Herbert schrieb: > Mein Gott, immer diese C- Probleme... Setzt Euch auf den Hosenboden und > lernt ASM! Schneller,kompakter und 1/10 Schreibaufwand. dafür kaum Portierbar und unübersichtlicher, nein, danke
Christian B. schrieb: > dafür kaum Portierbar und unübersichtlicher, nein, danke In der Regel schreibt man für ein konkretes System- portierbaren Code braucht es dazu nicht. Und Code-Übersichtlichkeit ist wohl eher eine Sache sinnvoller Kommentierung denn der verwendeten Programmiersprache.
Herbert schrieb: > Christian B. schrieb: >> dafür kaum Portierbar und unübersichtlicher, nein, danke > > In der Regel schreibt man für ein konkretes System- portierbaren Code > braucht es dazu nicht. Und Code-Übersichtlichkeit ist wohl eher eine > Sache sinnvoller Kommentierung denn der verwendeten Programmiersprache. So ein Dünnflitsch. Gerade noch das Gegenbeispiel gehabt: Die ByteBuffer Bibliothek in der Codesammlung. Wie soll man sowas portabel in ASM implementieren?
Wozu hast du eigene inline Assembler gemacht? Du kannst auch das in AVR-GCC eingebaute nehmen:
1 | VPORT0.OUT |= _BV(7); |
Das nutzt SBI genauso wie das
1 | VPORT0.OUT &= ~(_BV(7)); |
CBI zum Rücksetzen benutzt.
Timmo H. schrieb: > Das nutzt SBI genauso wie das VPORT0.OUT &= ~(_BV(7)); Was sind das nur für furchtbare Konstruktionen? Schrecklich. Mein Gott nehmt doch SBI und am besten gleich alles in Asm und gut ist.
Herbert schrieb: > Timmo H. schrieb: >> Das nutzt SBI genauso wie das VPORT0.OUT &= ~(_BV(7)); > > Was sind das nur für furchtbare Konstruktionen? Schrecklich. Mein Gott > nehmt doch SBI und am besten gleich alles in Asm und gut ist. Es sind die gleichen Anweisungen, die man in Assembler auch hat? VPORT0.OUT ist ein #define um den Registerzugriff einfacher zu gestalten, & und ~ sind binäre Verknüpfungen, das _BV(x) Zeug ist das gleiche wie (1<<x) also einfach nur ein Linksshift um x. Und ja, das _BV ist auch nicht mein Geschmack, aber stattdessen kann man auch einfach eine Bitmaske in Hexadezimal angeben, wenn man darauf steht. VPORT0.OUT &= ~0x10;
Simon K. schrieb: > & und ~ sind binäre Verknüpfungen, das _BV(x) Zeug ist das > gleiche wie (1<<x) also einfach nur ein Linksshift um x. > Ja genau. Früher gabs dafür das sbi und cbi Macro, was aber jetzt deprecated ist. Das BV mag ich ansich auch nicht, hatte es nur direkt aus der Doku kopiert (http://www.nongnu.org/avr-libc/user-manual/group__avr__sfr.html), und zuerst angenommen, dass es notwenig ist damit der Compiler erkennt sbi bzw. cbi zu verwenden, geht aber in der Tat auch ohne.
auf XMega hat man doch auch noch die OUTSET und OUTCLR Register, oder gibts die für die vports nicht? Ich find das die einfachste und eleganteste Methode.
Die Set und Clear register braucht man bei den Virtuellen Ports nicht, da mann auf sie mit SBI, CBI, AND, OR, ... direkt zugreifen kann. Also innerhalb eines Taktes eine Bitmanipulation durchführen kann. Werte sind auch schneller in die Virtuellen Ports geschrieben, da man mit IN und OUT anstatt LD und ST arbeiten kann.
Bitte 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.