Hi,
Ich verstehe dann aber immer noch nicht wie er das Programm dann schneller abarbeitet, bleibt doch die Anzahl der Befehle und die tatsächliche Taktfrequenz die gleiche
Bascom berechnet die Wartezeiten für's Display aus deiner Angabe der Taktfrequenz. Wenn du keine extra Library verwendest, muss RW auf GND liegen. Dadurch kannst du aber das Busy Flag des Displays nicht auslesen.
Um sicherzugehen, daß das Display bereit für neue Daten ist, legt Bascom eben eine kleine Pause ein.
Diese ist allerdings so lange gewählt, daß es 100%ig auch immer mit jedem Display geht.
Die meisten Displays sind aber schneller mit dem Verarbeiten der Daten fertig.
Wenn du Bascom jetzt eine niedrigere Quarzfrequenz vorlügst, macht der Compiler die Wartezeiten eben kürzer.
Bei den Displays, die ich so verwende, geht's bis auf ein viertel der Wartezeit einwandfrei.
Wenn du also eine niedrigere Taktfrequenz angibst, werden auch die Wartezeiten kürzer.
Das daß natürlich keine saubere Lösung ist, ist klar.
Es ändern sich ja auch alle anderen Zeiten.
Der UART läuft dann auch anderer Datenrate, alle wait Befehle stimmen dann nicht mehr etc.
Man muss da schon höllisch aufpassen

Beispiel:
$crystal = 4000000 ' Bei Quarz 16 MHz
Baud = 4800 'Baudrate ist 19200 BPS
waitms = 400 'Wartezeit ist 100ms

Besser wäre es, das Busy Flag abzufragen zb. mit der lcd4busy.lib.
Damit sollte die Displayausgabe schneller gehen.

Gruß
Christopher