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

[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%