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

[MagicWSmoke]

Aber Interesse kann man ja haben.

Ja, klar.

...dir generell den Aufwand machst, ist im Übrigen hoch anzurechnen.

Danke, ganz uneigennützig bin ich aber auch nicht, das mach' ich gern wenn ich's als Knobelaufgabe betrachte.
Das Schreiben von Assembler in 'ner separate .S-Datei ist im Übrigen um Einiges angenehmer als Inline ASM.

Hatte noch 'ne andere ISR Version gebaut, bei der immer pro ISR-Aufruf eine komplette der 20 Zeilen ausgegeben wurde, die war noch schneller und hätte es auf maximal 115Hz gebracht. Aber sie hätte die Programmausführung recht lange unterbrochen und damit wäre das für UART-Kommunikation ein Problem gewesen.

Die angehängte Version gibt immer nur eine Scanzeile von 12 aus, hat deswegen mehr Overhead und schafft's auf max 103Hz.

[ePyx]

Danke, ganz uneigennützig bin ich aber auch nicht, das mach' ich gern wenn ich's als Knobelaufgabe betrachte.

Das ist aber sehr schlimm.

Das Schreiben von Assembler in 'ner separate .S-Datei ist im Übrigen um Einiges angenehmer als Inline ASM.

Kann ich mir gut vorstellen. Bisher hab ich mich noch nicht wirklich damit auseinandersetzen müssen. Entweder waren die Sachen in C oder in ASM lösbar. Mischen bzw. Optimieren musste ich da bisher nicht allzu viel. Daher ist halt auch interessant.

[MisterMou]

Soo,
endlich hatte ich mal wieder etwas Zeit...
Inzwischen nutze ich ein anderes Display, bei dem "M" manuell geschaltet werden muss. Das heißt, jedes Frame wechselt M zwischen high und low. (1.Frame high | 2.Frame low | ...)
Das Display flimmert weniger bei niedrigen Frequenzen. Es lässt sich bei 57Hz problemlos betreiben, das andere musste mit mindestens 70Hz gefahren werden.
Außerdem besitzt dieses eine LED Hintergrundbeleuchtung. Allerdings steigt die Kontrastspannung von -18V auf +23V, aber für mein Labornetzteil ist das kein Problem.
Der Kontrast ist auch etwas schlechter.
Der große Bonus ist der Touchscreen
Sonst bleibt alles beim Alten.

Zur Zeit habe ich Probleme, dass die Schrift nicht sauber gezeichnet wird. Einige Pixel sind an der falschen Stelle, aber bei dem selben Zeichen immer wieder gleich falsch. Das sieht so aus als würde das Array falsch gespeichert werden.
Und dann passt auch mal wieder alles, einfach so. Ich gebe aber meinem Rechner die Schuld, der ist zur Zeit etwas zickig.

Die IRQ Sache ist ne tolle Idee, aber Timer0 unterstützt doch gar keinen Compare-Interrupt, sondern nur einen Overflow-Interrupt.
Ich sage auch mal "Ja"

edit: Der Rechner ist es nicht, mein großer ist der selben Meinung O.o

[MagicWSmoke]

Die IRQ Sache ist ne tolle Idee, aber Timer0 unterstützt doch gar keinen Compare-Interrupt, sondern nur einen Overflow-Interrupt.
Ich sage auch mal "Ja"

Irgendwie bin ich da auf den Mega16 gekommen
Lässt sich aber einfach auf Preload des Timers umbauen, werd's morgen mal ändern und dann einstellen.

[MagicWSmoke]

Anbei die geänderte Version für den ATMega8, bei dem nun Timer0 vorgeladen wird.
Es handelt sich aber noch um ungetesteten Code für das ursprüngliche Display, sollte also erst getestet werden ob's auf dem überhaupt hinhaut, sowohl von der prinzipiellen Code-Funktion, als auch mit der Ausgabe jeweils 1 Linie pro ISR-Aufruf.

Sobald das dort läuft, kannst Du die Änderung

jedes Frame wechselt M zwischen high und low. (1.Frame high | 2.Frame low | ...)

selbst in der .S vornehmen, oder C-Beispielcode einstellen, dann schau' ich's mir an.

Leider musste meine Kalkulation für den Zähler-Topwert über das #define in der .h über Bord gehen. Der GCC hatte kein Problem damit, aber der GNU Assembler war nicht dazu zu bewegen die Rechnung aufzulösen.
top_val muss also nun selbst ausgerechnet werden, ist für 75Hz bereits erledigt, bei dieser Wiederholrate sind noch ungefähr 27% der Prozessorleistung für anderen Code verfügbar.

[MisterMou]

Danke für die ganze Arbeit.
Inzwischen überfordert mich Dein Code komplett
Er funktioniert trotzdem tadellos.
Er lässt sich auch am neuen Display testen, allerdings verblasst das Bild nach ein paar Sekunden, daran ist aber M schuld.
Soweit ich das mitbekommen hab, ändert M die Polarität der Kristalle und hält so den Kontrast aufrecht, deswegen der ständige Wechsel.
Die Ansteuerung ist sehr einfach. Nach jedem Frame wird gewechselt.

PORTD=~PORTD;

Ich habe dafür noch den übrigen Port genommen um den original Code nicht ändern zu müssen. M hängt an Pin D0.

Meine Pixelfehler waren ein gelegentlicher Kurzschluss zwischen D1 und D2...

[MagicWSmoke]

Danke für die ganze Arbeit.

Bitte. Ich fand's natürlich interessant, auch wenn die einfach zu versorgenden Displays nicht mehr erhältlich sind.

Inzwischen überfordert mich Dein Code komplett

Um es in eine .S auszulagern, war der Umbau komplett auf Assembler notwendig.

Er funktioniert trotzdem tadellos.

Prima.

Die Ansteuerung ist sehr einfach. Nach jedem Frame wird gewechselt.

Ich hatte mich nicht mit der eigentlichen Funktion des Displays auseinandergesetzt, sondern nur Deinen Beispielcode umgesetzt.
D.h., wenn Du einen funktionierenden Code einstellst, an dem ich sehe wann genau M kommen muss, dann ist's für mich am einfachsten danach meinen Code zu ändern.
Sind auf dem Kontrollport PORTB noch Pins verfügbar ?