wie im µs Berich effizient warten

Hansjörg schrieb:
> Bei jedem Zeichen das ich an das Display sende sind 45us zu warten.
> Das ist schon relativ viel Zeit in der man nichts tut.
> Oder sehe ich das falsch.
> Wenn ich zb einen String mit 10 Zeichen an das Display schicke muss ich
> 10mal 45us warten. Mit Interrupt Flag muss ich mir aber auch merken wo
> ich gerade beim Senden war.
> Das ist auch nicht gerade das gelbe vom Ei.....
du müsstest alles was ans Display gehen soll in einen Puffer packen und 
dann in jedem Interrupt ein Byte ausgeben. Ob die Initialisierung des 
Puffers und die INTs die 45μs aufwiegen müsste man mal ausrechnen. Wenn 
immer nur ein Byte raus muss könnte man das auch per DMA machen.

Sascha

Moin,

Es gibt so eine Zeitspanne im Bereich zwischen ein paar NOPs (µsec) und 
"vernuenftiger" IRQ Haeufigkeit (~ msec), da isses einfach kagge bei 
einer CPU mit warten. Ist halt so. Sollte man vermeiden. Also z.b. ein 
anderes Display einsetzen ;-/

Gruss
WK

Das klingt nach einer Aufgabe für einen Timer getriggerten DMA.
Die STM32 haben genug Timer, da lässt sich mal der eine oder andere für 
Spezialaufgaben nutzen.

Buffer füllen -> SPI+Timer+DMA einstellen -> nach einem DMA Done IRQ 
kann der nächste Buffer gesendet werden.

Hansjörg schrieb:
> Wenn ich zb einen String mit 10 Zeichen an das Display schicke muss ich
> 10mal 45us warten. Mit Interrupt Flag muss ich mir aber auch merken wo
> ich gerade beim Senden war.

DMA. Initialisierung mit Timer.

Hansjörg schrieb:
> Hi,
> beim Atmel habe ich einmach _delay_us() verwendet aber beim STM32 finde
> ich schade wenn der Gute mit 72Mhz rennt und im Code gewartet wird.

Die Forderung war "Warten ohne nichts zu tun", da wäre ein _delay_us() 
auch falsch ;)

Zum Thema selbst: Ich würde da auch richtig DMA und Timer gehen wenns so 
wichtig ist nicht nichts zu tun.

Korrekt macht man das so, daß man nicht nach einem Befehl wartet, bis 
das Display damit fertig ist, sondern indem man vor dem Senden eines 
Befehls prüft, ob das Display den vorigen Befehl fertig hat. Die 
sinnvollste Variante dafür ist die Auswertung des BUSY Flags.

Denn damit fängt man nicht nur Variationen des Display-Taktes ab (das 
ist ja nur ein simpler RC-Oszillator) sondern auch Variationen in der 
Ausführungszeit. Das Datenblatt nennt die maximale Ausführungszeit. Es 
kann durchaus auch schneller gehen.

Dummerweise kann man das BUSY Flag unter Verwendung des SPI Interface 
nicht abfragen. Deswegen wäre die erste Frage: muß es wirklich SPI sein?

Falls doch, dann kann man einen Timer dazu verwenden, die 
Ausführungszeit des Display-Controllers zu simulieren. Man setzt dafür 
einen Timer auf, der vom gesetzten Wert in µs-Intervallen auf 0 zählt. 
Nachdem man einen Befehl an das LCD sendet, setzt man den Timer auf die 
Ausführungszeit des Befehls (den Maximalwert aus dem Datenblatt). Immer 
bevor man einen (weiteren) Befehl absetzt, schaut man, ob der Timer 
schon auf 0 steht und wenn nicht, wartet man halt darauf.

SPI...

Bei einem LCD- Display mit 3*16 Zeichen ist es natürlich extrem 
sinnvoll, beim Schreiben auch noch die allerletzte Mikrosekunde 
einzusparen...

Einfach per Timer die Zeiten aus dem Datenblatt abwarten, und fertig.

Oliver

Klar, DMA mit Timer kann man alles machen.

Aber mal anders herum gefragt:
Wäre es so schlimm wenn nur z.B. jede ms ein Zeichen zum Display 
gesendet wird?
Mehr wie 100 Zeichen wirst du wahrscheinlich nicht haben auf dem 
Display.
Und selbst wenn wären es dann noch 10Hz Aktualisierungsrate.

Ich würde mir also überlegen ob ich einen ms Interrupt anlege. In dem 
kannst du dann alles mögliche machen. Von Taster abfragen, LEDs bedienen 
oder eben auch ein neues Zeichen zum Display senden. Dann wartet der 
Controller effektiv garnicht und du hast die restliche Zeit für 
Echtzeit-Geschichten frei.

Man legt einen Puffer an für alle Zeichen des Text-LCD.
Ein Timerinterrupt 1ms gibt dann immer ein Zeichen aus bzw. das Byte zur 
Zeilenumschaltung.

Hier mal ein Beispiel für den AVR:
Beitrag "Formatierte Zahlenausgabe in C"

Wolfgang schrieb:
> Axel S. schrieb:
>> Korrekt macht man das so, daß man nicht nach einem Befehl wartet, bis
>> das Display damit fertig ist, sondern indem man vor dem Senden eines
>> Befehls prüft, ob das Display den vorigen Befehl fertig hat.
>
> Dann verbringt man vor dem Senden die Zeit mit "gucken ob fertig" und
> hat damit auch nicht richtig etwas gewonnen, weil irgendeine andere
> Aufgabe sich immer um "Busy-Gucken" kümmern muss.

Ich habe ganz bewußt nichts konkretes dazu geschrieben, wie dieses 
"Warten" aussehen sollte. Denn das hängt ganz und gar davon ab, was das 
Programm sonst noch so treibt. Man könnte das auszugebende Zeichen 
widrigenfalls ja in einen Puffer schreiben. Und sich beim Ablauf des 
Timers per Interrupt informieren lassen. Eine ISR aufsetzen, die den 
Puffer leert. Oder gleich den ganzen Weg gehen und FIFO Pufferung für 
das Display implementieren.

Aber im Zweifelsfall muß man zwischen den einzelnen Zeichen, die aufs 
Display gemalt werden, ja ohnehin noch andere Sachen tun. Und sei es 
nur, daß man die nächste Ziffer aus einer mehrstelligen Zahl extrahiert. 
Wenn die Wartezeit kurz genug ist, dann reicht das ja womöglich schon.

PS: überhaupt ging es mir nicht darum, eine optimale Strategie zur 
Ausgabe von Zeichen zu formulieren. Mir ging es einzig darum, daß 
unmittelbar nach der Ausgabe des Zeichens der falschestmögliche 
Zeitpunkt zum Warten ist. Denn in diesem Moment habe ich ja schon alles 
erreicht, was zu erreichen war: ich bin mein Zeichen ans Display 
losgeworden. Ob es jetzt 10µs braucht, um es auf das Glas zu malen oder 
10ms, das kann mir zu diesem Zeitpunkt vollkommen egal sein. Interessant 
wird das erst, wenn ich das nächste Zeichen ausgeben will. Aber ein 
Treiber weiß ja nicht (kann gar nicht wissen) wann das Hauptprogramm 
das nächste Zeichen ausgeben wird.

Axel S. schrieb:
> Interessant
> wird das erst, wenn ich das nächste Zeichen ausgeben will. Aber ein
> Treiber weiß ja nicht (kann gar nicht wissen) wann das Hauptprogramm
> das nächste Zeichen ausgeben wird.

die Frage muss doch mal gestellt werden, wer kann so schnell ein LCD 
ablesen dasmehr als 4 Aktualisierungen pro Sekunde gelesen werden 
können?

Ich mache nur 4 Aktualisierungen pro Sekunde nur deswegen weil die 
angezeigte Uhrzeit relativ flüssig laufen soll, ob die Zeit nun 10ms 
früher oder später aufs Display gemalt wird ist doch egal!

Auch bei der Überwachung einer Batterie-spannung oder -strom bekomme ich 
Peeks nicht mit, wenn ich sie gelesen habe sind sie lange vorbei, was 
nun, allenfalls könnte man peek detect einsetzen und extra irgendwo 
schreiben und stehen lassen, genau wie früher am analogen 
Zeigerinstrument mit Leuchtanzeige für peek (overload)

Genau wie bei einer Stopuhr auf dem LCD, versucht doch mal 1/10 oder 
1/100 Sekunden zu lesen!

A. S. schrieb:
> Zudem kommt es noch darauf an, wie es gefüllt wird. Wenn man zuerst
> alles Löschen muss, dann sollte es sehr schnell (<20ms) wieder voll sein
> um ein "Blinken" zu vermeiden.

bei TFT Displays habe ich mir abgewöhnt alles zu Löschen, das dauerte zu 
lange, aber ich hatte den Text im SRAM zwischengespeichert und nur die 
geänderten Buchstaben Pixel mit SW übermalt somit änderten sich nur die 
neueren Pixel.

Dummerweise ist da jede LIB jedes Display verschieden, z.B. für ein 
Nokia5110.
Es gibt eine LIB (nur) für AVR die löscht automatisch das ganze Feld 
unter dem neuen Buchstaben und die von Adafruit (für ESP32) tut es eben 
nicht, da muss man dann selber erst mal das Feld löschen vor Neumalen 
des Buchstabens (oder Ziffer oder Sonderzeichen)

Johannes S. schrieb:
> Bei der Adafruit_GFX kommt es darauf an wie man setTextColor() aufruft:
> mit nur einem Argument wird die Textfarbe gesetzt und Hintergrund ist
> transparent

.setTextColor(BLACK);

reicht also nicht?

hast du ein Beispiel, das wusste ich nicht, ich wunderte mich nur das 
sich so langsam alle Pixel füllten!

also statt

Joachim B. schrieb:
> .setTextColor(BLACK);

.setTextColor(BLACK, WHITE)?

hmm mal probieren, danke


Funktioniert einwandfrei, danke dafür, ich sollte mal wieder anfangen 
Anleitungen zu lesen, fällt mir schwer weil ich ein Mann bin :))))

Johannes S. schrieb:
> Aber diese Lib ist für Grafikdisplays und die kann der TO bei seinem
> DOGM163 nicht gebrauchen.

aber beim nokia5110 klappt das, bei anderen TFT bin ich nicht sicher, 
wäre zu probieren!

Was mir aufgefallen ist, gerade bei Display-Ansteuerung ist eine 
möglichst hohe Geschwindigkeit oft unnötig. Dem Benutzer bemerkt gar 
nicht, ob man bei sowas 30..50µs oder eine ganze Millisekunde wartet. 
Ich mache bei sowas daher entweder alles in Hardware oder mit 
irgendwelchen Wartezeiten, die gerade entstehen und auf jeden Fall lang 
genug sind.

Ben B. schrieb:
> Was mir aufgefallen ist, gerade bei Display-Ansteuerung ist eine
> möglichst hohe Geschwindigkeit oft unnötig. Dem Benutzer bemerkt gar
> nicht, ob man bei sowas 30..50µs oder eine ganze Millisekunde wartet.

wie schon geschrieben wurde, was soll denn der Prozzi in der 
verbleibenen Zeit noch alles machen?

ob er 4x oder 10x pro Sekunde das Display aktualisiert welches sagen wir 
1ms dauert, die Restzeit ist doch riesig

Hallo,

Ihr vergesst dabei eine Sache. Die Wartezeiten addieren sich, je nach 
Länge der Displayausgabe. Die üblichen Libs warten mit harten delays. 
Wenn nebenbei zum Beispiel eine schnelle serielle Kommunikation läuft 
gehen Daten verloren, weil die Einlesefunktion nicht zum Zug kommt.

Entweder man bekommt ein unkritisches Zeitfenster für die Displayausgabe 
hin. Oder man lässt den SPI Interrupt einen Buffer leeren welcher 
letztlich das Display bedient.

Veit D. schrieb:
> Hallo,
>
> Ihr vergesst dabei eine Sache. Die Wartezeiten addieren sich, je nach
> Länge der Displayausgabe. Die üblichen Libs warten mit harten delays.
> Wenn nebenbei zum Beispiel eine schnelle serielle Kommunikation läuft
> gehen Daten verloren, weil die Einlesefunktion nicht zum Zug kommt.

Unsinn. Für sowas hat der liebe Gott Interrupts und Zwischenpuffer 
erfunden.

> Entweder man bekommt ein unkritisches Zeitfenster für die Displayausgabe
> hin. Oder man lässt den SPI Interrupt einen Buffer leeren welcher
> letztlich das Display bedient.

Und worüber reden wir denn WIRKLICH? Ein großes 4x20 LCD mit 80 Zeichen 
braucht bei 40us/Zeichen 3,2ms Updatezeit. Naja, nicht wirklich schnell 
aber auch kein Drama, wenn man das mit 10 Hz / 100ms aktualisiert, 
kostet halt 3,2% CPU-Zeit.

Wer die Wartepausen WIRKLICH nicht mag oder gebrauchen kann schreibt in 
einem halbwegs schnellen Timer- Interrupt immer nur 1 Zeichen auf das 
LCD. Bei 1 kHz kommt man da auf 12,5Hz Updaterate mit geschätzt 
5us/Zeichen bzw. 0,5% CPU Last.

W.S. schrieb:
> Für all so etwas lohnt sich weder ein RTOS, noch ein Timer oder gar ein
> Timer+DMA - was für eine besonders grandiose Idee, insbesondere für den
> 4 Bit Betrieb.

Mal wieder Leseverständnis: 6! Setzen!
Hier gehts um den SPI Modus eines DOGM LCD.
Anonsten ist es im Forum bekannt genug, dass du DMA nicht verstanden 
hast und es daher verteufelst.

Falk B. schrieb:
> Und worüber reden wir denn WIRKLICH? Ein großes 4x20 LCD mit 80 Zeichen
> braucht bei 40us/Zeichen 3,2ms Updatezeit. Naja, nicht wirklich schnell
> aber auch kein Drama, wenn man das mit 10 Hz / 100ms aktualisiert,
> kostet halt 3,2% CPU-Zeit.
>
> Wer die Wartepausen WIRKLICH nicht mag oder gebrauchen kann schreibt in
> einem halbwegs schnellen Timer- Interrupt immer nur 1 Zeichen auf das
> LCD. Bei 1 kHz kommt man da auf 12,5Hz Updaterate mit geschätzt
> 5us/Zeichen bzw. 0,5% CPU Last.

eben nur wenn ich es schreibe hagelt -

Joachim B. schrieb:
> wie schon geschrieben wurde, was soll denn der Prozzi in der
> verbleibenen Zeit noch alles machen?
>
> ob er 4x oder 10x pro Sekunde das Display aktualisiert welches sagen wir
> 1ms dauert, die Restzeit ist doch riesig

Beitrag "Re: wie im µs Berich effizient warten"

Hansjörg schrieb:
> Wie kann ich auf einfache weiße die paar µs
> warten ohne das ich ich nichts mache.
> Also ich was Sinnvolles mache

Lustige Frage übrigens...
Der TO fragt also ernsthaft, was er in der Zeit, bis mal wieder ein 
Zeichen an das Display zu senden ist, Sinnvolles machen könne! Da kann 
die Antwort doch nur lauten: was weiße ich denn?? Wenn sein Programm 
also nichts anderes macht, als ab und zu ein Zeichen zu senden, woher 
soll dann in der "Zwischenzeit" was sinnvolles kommen? Offensichtlich 
verstehe ich das Problem nicht :-)
Gruß Rainer

W.S. schrieb im Beitrag #6430108:
> Was bist du doch für ein Blödmann

Danke für die Freundlichkeiten ;)

Der Rest des Postes ist wieder eine typische W.S. Nebelkerze, auch so 
lohnt sich DMA+Timer.
Einmal einstellen, abfeuern und die CPU wichtigerere Dinge erledigen 
lassen.