KS108-Display: Befehl von Bascom nach Assembler

[m_herr]

Hallo,

ich bin ein Bascom-Jünger der einfachsten Art, darum habe ich leider auch keinerlei Assembler-Erfahrung, was sich jetzt etwas rächt...

In Bascom gibt es den GrafikBefehl

Line(a, b) -(c, d), 1
welcher ganz unspektakulär eine Line vom Anfangspunkt (a, b) zum Endpunkt (c,d) zeichnet. Und je nach Parameter entweder als sichtbar (1..wie in dem Beispiel) oder unsichtbar (0)....

Nun habe ich aber festgestellt, daß dieser Befehl recht langsam ausgeführt wird, gerade das Löschen dauert länger, die Linie ist also nicht gleich gelöscht, sondern schimmert noch etwas nach...

Meine Frage ist nun, wie ich diesen Line-Befehl in assembler nachbilden kann, dann sollte das ja auf dem Bildschirm etwas flüssiger laufen, oder?

Vielen Dank.

[linux_80]

Hallo,

die Bascom-Befehle sind alle in Assembler hinterlegt, das es langsam geht, könnte auch damit zusammenhängen, daß es für den AVR doch sehr aufwendig ist, die Punkte einer zB. diagonalen Linie zu berechnen.

Du kannst Dir ja mal eine Hex-Datei mit enthaltenem Line-Befehl-Programm disassemblieren, und im AVR-Studio angucken...

[Besserwessi]

Wenn das löschen wesentlich länger als das Zeichnen dauert, könnte das auch eine Beschränkung des LC-Displays sein. Die berechnung an sich sollte auch der AVR schnell machen können, nur der muß die Daten auch noch mehr oder weniger schnell zum LCD rüberschicken, und und zum Teil auch noch vorher auslesen. MIt Assembler wird man da wahrscheinlich nicht viel beschleunigen können, es sei denn die haben beim BASCOM einen groben schnitzer drin.

[m_herr]

nur wie kommt es, daß bei youtube zb. die grafik-videos (einfache linien, würfel etc) per atmel wesentlich flüssiger laufen?
ich glaube kaum, daß es da eine Display-Beschrenkung gibt. Der Atmel rechnet mit 8mhz. Das sollte doch nicht zu langsam sein, da mit 4MHZ die Grafik noch genau so "verschliert" aussieht.

[bax]

Ein Großteil der Zeit wird darin begründet sein, daß das Basic vermutlich so arbeiten wird, das es für jeden Punkt erst das entsprechende Byte aus dem Display liest, den Punkt setzt und das Byte zurückschreibt.
Hab meine erste Displayansteuerung auch so realisiert, und es war trotz Assembler recht langsam.
Für ein 64x128 Display nehm ich jetzt einen Mega32 (2k SRAM), und halte darin 1024byte als Grafikspeicher frei. Die Grafikbefehle schreiben also nur in den SRAM. Im Hintergrund laß ich per Interupt-Timing den SRAM zum Display schicken. So lassen sich sehr schnelle Bildaufbauten erreichen.

Rajko

[m_herr]

Mh, könntest du irgendwie mir das genauer erklären, oder ist das zu geheim?

[bax]

Nein, geheim ist es auf keinen Fall, aber ich weiß nicht so recht, wo ich dann anfangen soll.

Du kannst Dich z.B. hier damit vertraut machen, was es bedeutet, einen einzelnen Punkt auf einem GLCD zu setzen: http://www.geocities.com/dinceraydin/djgfxlcdsim/djgfxlcdsim.html
Dann kannst Du in etwa abschätzen, wieviele Befehle dann für eine Linie zwischen AVR und GLCD ausgetauscht werden müssen.

Rajko

[m_herr]

Also ich sehe da nur c-scripts.....

[bax]

Du siehst doch unter dem Display die 13 Knöpfchen, die symbolisieren 13 Ports des AVR. Nun kannst Du im Datenblatt des KS0108 nachlesen, wie Du den Controller ansprechen mußt. So setzt Du die 13 Knöpfchen, und das Display zeigt vielleicht mal einen Punkt an ;)

Beispiel zum nachmachen, Bitfolgen genauso eingeben:
1. Displayhälfte einschalten:

Daten: 00111111 Steuerleitungen: 00001
Befehl "aktivieren": E auf 1 und wieder auf 0

2. "Zeile" (Page) 3
Daten: 10111011 Steuerleitungen: 00001
Befehl "aktivieren": E auf 1 und wieder auf 0

3. "Spalte" (Y) 63
Daten: 01111111 Steuerleitungen: 00001
Befehl "aktivieren": E auf 1 und wieder auf 0

4. Punkt setzen
Daten: 10000000 Steuerleitungen: 00101
Daten schreiben: E auf 1 und wieder auf 0

Jetzt sollte in der Mitte des Displays ein Punkt erscheinen.

Das sollte als Lesson one erstmal reichen ;-)

Rajko