Gibt es noch Optimierungspotential? (Mega8 an 320x240 GLCD Textmodus)

[MisterMou]

Bis jetzt hattest Du nur statischen Text.

Ich seh aber wie träge das Display ist, der Wechsel eins Zeichens dauert mehrere Frames.
Ich kann Dich aber beruhigen, man sieht keine Probleme, zumindest bei meinem Code. Deiner ist ja fixer, da sollte es weniger Probleme werden.

Wahrscheinlich optimiert er Dir da irgendetwas weg. Bedeutet das, die höheren Optimierungsstufen funktionieren ?

Genau, beides.

Da Dein Ziel eine möglichst kurze Ausführungszeit ist, ist ein Einfachfrauflos halt sehr zufällig im Ergebnis.

Das ist mir bewusst, aber ich habe kaum Erfahrung. Also erst einmal zum Laufen bringen, dann optimieren. Ich kann ja nicht zaubern

[MagicWSmoke]

Das ist dann das Henne-Ei Paradoxon, wenn Du nicht Assembler lesen kannst, siehst Du nicht, wie der Compiler bestimmte Anweisungen in C umsetzt, das Du deswegen benutzt um Assembler zu vermeiden

[MisterMou]

Da geb ich Dir Recht
Ich finde ASM einfach so unbequem, aber wo keine Rechenleistung ist, muss man eben durch Optimierung nachhelfen, mir bleibt da wohl nichts übrig...

Das Ersetzen von (mFlag<<M) durch mFlag bringt so gut wie nichts.
mFlag wird dabei vorher schon 0x08 oder 0x00 gesetzt.

[MagicWSmoke]

Du hast halt das Problem dass aus 2 schnöden Takten, oft genug durchlaufen, schnell mal 1000 werden.
Ich fand den erzeugten ASM-Block zum Steuern der Bits unnötig kompliziert, hab' mich allerdings nicht um andere Lösungen umgesehen.

Mir wär's allerdings zu dumm mit dem C-Code rumtüfteln zu müssen, nur damit der Compiler das von mir Gewünschte zusammenbaut. Hatte ich am Anfang des Projekts auch versucht, nur um zu erkennen, was da alles an kreativ Unbrauchbarem rauskommt.

Dann sag' ich's doch gleich in Assembler, vor allem da der Umfang der Sache recht überschaubar ist.

[MagicWSmoke]

Hab' mir nochmal angesehen, warum Dein Code so langsam ist. Hier:

...dass aus 2 schnöden Takten, oft genug durchlaufen, schnell mal 1000 werden.

hatte ich bereits richtig geraten. Auch wenn ich die (mFlag<<M) Geschichte nicht gut finde, weil er da in einer Schleife schiebt, was völlig unnötig ist, da vermeidbar, so wird dieser Teil nicht oft durchlaufen.

Das Problem macht dies hier:

    mov    r25,r21
    ldi    r24,k00
    subi    r24,k00
    sbci    r25,kFF

Denn das wird 40 mal pro ISR eingebaut und ist das Resultat aus:

: "r" (&font[charRow][0]), "r" (tempChar) \

So etwas kannst Du vermeiden, indem Du zu Beginn der ISR die globale Variable in eine lokale kopierst und am Ende wieder zurück. Damit erlaubst Du dem Compiler zu optimieren, d.h. diese lokale Variable in einem Prozessorregister zu halten.

    #define char_put() \
...
                        : "r" (&font[l_charRow][0]), "r" (tempChar) \
...
       }
    
    ISR(TIMER0_OVF_vect)
    {
      unsigned char l_charRow = charRow;
...
        if(l_charRow==CHAR_HEIGTH)
...
            l_charRow=0;
...
        l_charRow++;
          charRow = l_charRow;
    }

Spart pro ISR-Lauf ca. 160 Takte, macht dann bei 12 x 20 x 75 = ~2900000 Takte

[MisterMou]

So etwas kannst Du vermeiden, indem Du zu Beginn der ISR die globale Variable in eine lokale kopierst und am Ende wieder zurück. Damit erlaubst Du dem Compiler zu optimieren, d.h. diese lokale Variable in einem Prozessorregister zu halten.

Um solche Infos geht es mir, danke. Das hatte ich bis jetzt nirgendwo gelesen (vllt. auch überlesen), dabei ist es doch so wichtig für ein schnelles Programm...
Bin damit auf eine Auslastung von 70% bei 75Hz gefallen, da fehlt nicht mehr viel zur ASM Version
Bei 50Hz sind es 47% Auslastung.

Aktueller Stand:

[MagicWSmoke]

Um solche Infos geht es mir, danke.

Dachte ich mir

Das hatte ich bis jetzt nirgendwo gelesen (vllt. auch überlesen), dabei ist es doch so wichtig für ein schnelles Programm...

http://www.mikrocontroller.net/artic...tile-Variablen

Bin damit auf eine Auslastung von 70% bei 75Hz gefallen, da fehlt nicht mehr viel zur ASM Version

70% halt' ich für ein Gerücht, die Assembler-ISR hatte im Schnitt um die 650 Takte, daraus ergibt sich 73% Last, die C-Version mit 680 Takten hat dann um die 76 %.

[MisterMou]

Dann muss mein Oszi lügen. Nagut die "Messung" ist nicht optimal
Bild hier  

Für Dich sind ja tatsächlich keine 120Hz wichtig, sondern was an Rechenleistung noch über bleibt, es ist mehr als ein Viertel. Also äquivalent einem mit 4MHz betriebenen µC und damit lässt sich ja immer noch Einiges anfangen.

Bei Dir klang das neulich noch nach weniger als 66%

edit: Jaja, ich hab mich verrechnet, sind 75%

[MagicWSmoke]

Dann muss mein Oszi lügen. Nagut die "Messung" ist nicht optimal

Wie so oft sitzt der Teufel im Detail, Deine Messung lässt Sichern und Wiederherstellen der Prozessorregister unberücksichtigt.

Bei Dir klang das neulich noch nach weniger als 66%

Nach meinem Zitat stehen 4MHz von 16MHz zur Verfügung, 4/16tel sind 25%, entsprechend 75% Last.

Die Rechnung: (([Durchschnittliche Takte pro ISR] * 12 * 20 * Bildwiederholrate) / Quarzfrequenz)*100 = Prozessorlast in Prozent.
Bei Deiner C-Version hast Du jetzt ungefähr 680 Takte von ISR-Einsprung bis Rückkehr in den unterbrochenen Code.

[MisterMou]

Fail...
Bei mir sind 4 von 16 eben ein Drittel

Wie so oft sitzt der Teufel im Detail, Deine Messung lässt Sichern und Wiederherstellen der Prozessorregister unberücksichtigt.

Achso. Das Sichern wird nicht gemessen, das glaub ich Dir sofort. Aber die Wiederherstellung geschieht doch noch wenn D0 low ist.
D0 wird doch erst wieder in der main() high geschaltet.