Hallo,
Hier soll es nicht darum gehen, wie man ein grafik LCD/TFT anstsuert,
sondern viel mehr darum, wie man Informationen abschickt und diese dann
"verarbeitet" werden um grafisch zu entstehen.
Ich habe zb. ein ILI9341 320x240 TFT Display und auch ein ST7920 128x64
LCD Display.
Initialiesierung, nutzung von SPI etc. ist soweit erstmal verstanden.
Mich interessiert grade viel mehr, und ich konnte bis jetzt auch nicht
viel darüber finden, wie es den im Hintergrund abläuft. Also als
Beispiel eine einfache Textausgabe (ganz davon abgesehn das einige
Displays Text-Modi haben). Irgendwo muss ja eine art Schriftart
vorliegen. und irgendwas muss ja bestimmen wo die schrift hinkommt. Wenn
ich zb. "Hello" ausgeben möchte, muss ja erstmal etwas die Pixel für
jeden Buchstaben setzen, dann muss der "cursor" ja auch weiter wandern.
Oder wie das ganze funktionert, wenn ich zb. ein Diagramm darstellen
will? Den Rahmen (oder zb. Raster beim Oszi) würde man ja noch recht
leicht hinbekommen. Nur wie stellt man es an, dass die "geschriebene
Linie" (also der strahl beim oszi) nicht das Raster kaputt macht? Also
ich meine, wenn die Linie durch zufall mal auf einem Raster liegt, dann
wird beim verändern der linie ja das alte Pixel wieder gelöscht. Dann
muss ja irgendetwas überwachen, dass das Raster nicht versehentlich
"weggeblendet" wird?
Genauso frage ich mich, wie ich einen 2 Dimensionalen Puffer aufbauen
soll. Brauche ja im grunde einen Platzhalter für jeden Pixel im grafen,
und je nachdem ob dort ein Pixel gesetzt wird, ändert der Puffer dort
halt seinen Status. Beim 128x64 Display sind ja nur zwei zustände,
schwarz oder weiß, möglich, dadurch ergibt sich ja schon 2048 Byte,
allein um das display zu Puffern. wenn noch Farbe dazukommt und mehr
Pixel, reicht der Speicher ja gar nicht mehr. Mir würden bei dem ILI9341
ja schon 8 Farben reichen, das wären dann aber schon 76,8 Kbyte.
Außerdem muss sich der Puffer ja ständig verschieben, sobald neue Daten
reinkommen, also zb bei Verwendung als Datenlogger oder oszi. Wie
bewerkstelligt man sowas?
Oder sind meine Gedanken grade totaler schwachsinn?
Würde gern mehr zu dem Thema erfahren. Habe ja nicht vor 3D sachen
darzustellen :)
Bin für alle Infos/Links dankbar!
Mit freundlichen Grüßen Sascha
Sascha712 schrieb:> Mich interessiert grade viel mehr, und ich konnte bis jetzt auch nicht> viel darüber finden,
Ich kenn jetzt nicht die neuere Literatur.
Aber wenn dir eine etwas ältere Literatur auch genügt, dann würde ich
dir zu einem Foley/Van Dam raten
http://www.amazon.com/Computer-Graphics-Principles-Practice-Edition/dp/0201848406
Zu seiner Zeit war es eines der Standardwerke, die man haben musste,
wenn man in Computer-Graphik einstieg.
> wie es den im Hintergrund abläuft. Also als> Beispiel eine einfache Textausgabe (ganz davon abgesehn das einige> Displays Text-Modi haben). Irgendwo muss ja eine art Schriftart> vorliegen.
Exakt.
> und irgendwas muss ja bestimmen wo die schrift hinkommt. Wenn> ich zb. "Hello" ausgeben möchte, muss ja erstmal etwas die Pixel für> jeden Buchstaben setzen, dann muss der "cursor" ja auch weiter wandern.
Bei einem reinen Grafikdisplay gibt es keinen Cursor in dem Sinne.
Textausgabe bedeutet einfach nur, die richtigen Pixel an der richtigen
Stelle in der richtigen Farbe einzuschalten.
> Oder wie das ganze funktionert, wenn ich zb. ein Diagramm darstellen> will? Den Rahmen (oder zb. Raster beim Oszi) würde man ja noch recht> leicht hinbekommen. Nur wie stellt man es an, dass die "geschriebene> Linie" (also der strahl beim oszi) nicht das Raster kaputt macht? Also> ich meine, wenn die Linie durch zufall mal auf einem Raster liegt, dann> wird beim verändern der linie ja das alte Pixel wieder gelöscht.
Soll vorkommen.
> Dann> muss ja irgendetwas überwachen, dass das Raster nicht versehentlich> "weggeblendet" wird?
Im einfachsten Fall beginnt die Ausgabe des nächsten Bildes damit, dass
der Raster komplett neu gezeichnet wird.
Wie überhaupt recht viel in der Computergrafik darauf beruht, dass man
sich im Speicher das komplette Bild neu erzeugt (inkl. Raster und
sonstigen Hilfslinien) und dann dieses neue Bild komplett ausgibt.
Darauf aufbauend gibt es natürlich Möglichkeiten, wie man das
beschleunigt, zb in dem man sich den Hintergrund (Raster +
Beschriftungen) in einem Buffer bereits ausgabefertig vorhält, so dass
man diese Pixel lediglich aus diesem Buffer auf die Anzeige transferiert
und dann da die Linien für das nächste Bild drüber malt.
> Genauso frage ich mich, wie ich einen 2 Dimensionalen Puffer aufbauen> soll.
In den meisten Programmiersprachen nennt man das ein Array.
> Brauche ja im grunde einen Platzhalter für jeden Pixel im grafen,> und je nachdem ob dort ein Pixel gesetzt wird, ändert der Puffer dort> halt seinen Status.
Ja.
> Beim 128x64 Display sind ja nur zwei zustände,> schwarz oder weiß, möglich, dadurch ergibt sich ja schon 2048 Byte,> allein um das display zu Puffern.
1K
Schwarz oder Weiß sind ja nurt 2 zustände. Ist ein Bit 0, dann soll das
entsprechende Pixel schwarz sein, ist es 1, dann soll es weiß sein.
> wenn noch Farbe dazukommt und mehr> Pixel, reicht der Speicher ja gar nicht mehr.
Tja. Pech gehabt.
> Mir würden bei dem ILI9341> ja schon 8 Farben reichen, das wären dann aber schon 76,8 Kbyte.
8 Farbe lassen sich in 3 Bit codieren, womit du dann 28.8k brauchst und
nicht 76.8 k
28.8k werden nicht ganz reichen, weil 3 Bit pro Pixel in der
Verarbeitung recht ekelig sind (aber machbar). Wahrscheinlicher ist es,
dann eben 4 Bit pro Pixel herzunehmen und damit potentiell 16 Farben pro
Pixel machen zu können.
> Außerdem muss sich der Puffer ja ständig verschieben
Was muss sich da verschieben?
> sobald neue Daten> reinkommen, also zb bei Verwendung als Datenlogger oder oszi. Wie> bewerkstelligt man sowas?
Indem man nur einen Ausgabepuffer hat, die darzustellenden Daten nicht
als Bild vorrätig hält, sondern in Form der Datenwerte selber und dann
eben dafür sorgt, das man zb 20 mal in der Sekunde ein komplett neues
Bild aufbaut, das man dann anzeigt.
Das ist das Problem mit den einfachen Display Controllern die über einen
Datenbus angeschlossen werden und einfache Kommandos verarbeiten. Die
Performance reicht nur für einfache Grafiken und Touchbuttons.
Die Buchstaben muss man pixelweise setzen, das war schon richtig. Dabei
kann man durch Nutzen der Controllerfeatures etwas optimieren: erst ein
Window setzen und dann kann man alle Pixeldaten nacheinander schicken
ohne jedesmal erst die Position zu setzen.
Graphen kann man evtl. durch srcoll Funktionen des Controllers schneller
machen, aber auch das ist limitiert weil dann der ganze Fensterbereich
verschoben wird.
Für ordentliche Performance braucht man dann µC mit integrierter
Displayansteuerung und zusätzlichem RAM.
Na das ich das keine 25fps habe bzw brauche ist mir schon bewusst. Aber
so 5 bilder pro sekunde sollten ja machbar sein?
Gibt es, außer das eine Buch oben, kostenlose informationen über das
thema?
Na ja.
Wenn ich dich richtig verstanden habe, dann ist das was du willst, ja
nicht so sehr das große algorithmische Problem.
Alles steht und fällt mit dem Problem, die Bytes eines Bildes möglichst
rasch vom µC zum Display schaufeln zu können, wenn das Display selber
keine höherwertigen grafischen Operationen oder gar Double Buffering
anbietet.
Welche Methode dann eingesetzt wird, hängt auch nicht unwesentlich davon
ab, wie komplex das darzustellende Bild eigentlich ist und wie aufwändig
es ist, es jedes mal neu zu erzeugen.
Es gibt dann auch noch die Möglichkeit, die Dinge nicht einfach blind
übereinander zu malen, sondern beim Malen einer Linie den 'Untergrund'
zu berücksichten. Zb. in dem man Pixel per XOR-Operation setzt. Eine
zweimalige Ausgabe derselben Linie hinterlässt dann den Untergrund so
wie er vor der ganzen Aktion war.
Einfach mal ein bischen spielen.
Das erste Zwischenziel bei einem Display, dessen Controller nichts
anbietet, ist es sowieso erst mal einzelne Pixel gezielt setzen zu
können. Vorher geht sowieso nichts.
Das Datenblatt zum Display gibt einen Überblick über die Features und es
gibt einige Bibliotheken zur Ansteuerung im Sourcecode, da sieht man
auch was geht und wie aufwändig einige Funktionen sind.
Die Geschwindigkeit hängt sehr stark an der Busanbindung und wie schnell
der µC die Kommandos und Daten raushauen kann. Auf Youtube findest du
eine Menge Beispielvideos wenn du zb nach dem Controller 'ILI9341'
suchst.
Gesamtdarstellungen im Netz zu finden, wird vermutlich eher schwierig.
Als unmöglich würde ich es aber auch nicht bezeichnen wollen.
Das Problem mit dem Thema ist, dass die einzelnen Punkte - Du hast das
ja schon recht einleuchtend gegliedert - im Grunde trivial sind.
Abgesehen von dem Buch, dass Karl Heinz genannt hat, hatte eben sonst
kaum jemand Grund eine weitere Gesamtdarstellung zu erstellen und die
noch kostenlos in's Netz zu stellen.
Die einzige, reale Möglichkeit, die mir spontan einfällt, ist, die
offenen Vorlesungen/Skripte von Unis, dann vor allem amerikanische Unis,
durchzusehen. (Die deutschen sind da etwas zugeknöpfter).
Ansonsten nimm Deine Gliederung und versuche dafür Darstellungen zu
finden. Wie Fonts aufgebaut sind, wie man Diagramme erstellt, wie man
Linien und Kreise zeichnet, etc. wird man leicht finden. Hingegen ist
die Frage wie man einen Punkt der schon gesetzt ist, nicht wieder löscht
schon Programmierer-Einmal-Eins (Bitoperationen), über das sich selten
jemand ausführlich Gedanken macht und das auch noch niederschreibt.
Allgemein nützlich, wenn man mal über die Grundlagen hinaus ist, sind
aber, denke ich, die "Algorithmen in C" von dem Robert Sedgewick. Da
gibts eine online-Version von. Auch das mehrteilige Buch von dem N.
Wirth ist interessant. (Gibts mit ein bisschen Suchen auch online, meine
ich).
Ja, werds versuchen. Hab gestern auch erst meinen Raspberry Pi zum Logic
analyzer umfunktioniert, mit piscope. Um direkt zu sehen, ob das SPI
alles richtig macht, also um fehler direkt von anfang an zu finden.
Werde also erstmal versuchen ein paar Pixel draufzuzaubern.
Um kurz meine Überlegung zum Oszilogramm zu erläutern:
Es kommen ja ständig werte vom ADC rein. Daher muss das oszilogramm ja
stätig fortlaufend sein. Ich kann also nicht den ganzen Bildschirm um x
Pixel nach links verschieben, da das oszilogramm ja nur in einem Fenster
ist. Beispielweise 60x100 Pixel. dann muss ich ja alle Pixel in diesem
bereich um eins nach Links schieben, damit der neue wert wieder platz
hat. Dabei darf dann ja auch das Raster nicht verschoben werden^^
Gruß
Sascha712 schrieb:> ist. Beispielweise 60x100 Pixel. dann muss ich ja alle Pixel in diesem> bereich um eins nach Links schieben, damit der neue wert wieder platz> hat. Dabei darf dann ja auch das Raster nicht verschoben werden^^
Dann bearbeitest Du halt in Deinem internen Array/Matrix nur die Pixel,
die sich ändern sollen:
..oooo
..oooo
..oooo
..oooo
..oooo
..oooo
..oooo
..oooo
..oooo
......
. = statisch
o = ändert sich
Richtig Spaß macht Computergrafik ab OpenGL aufwärts. Zwar ist es gut,
wenn man weiß, wie man jedes einzelne Pixel von Hand setzen kann. Aber
zum Erstellen einer tauglichen Anwendung im Jahr 2014 ist das doch eher
mühsam. Dafür sind höhere Abstraktionsebenen da: Dass man sie nutzt :-)
Ich weiß ja nicht, wie gut du programmieren kannst. Wenn du da drinn
fertige Lösungen suchst, dann wirst du nicht fündig. Im Buch werden die
Grundlagen durchgezogen, allgemeine Algorithmen beschrieben, die
Prinzipien erläutert und die dahinter liegende Mathe durchgezogen.
Wenn du Fertiges suchst, das du nur noch abtippen brauchst, dann ist das
eher nichts für dich. Wahrscheinlich ist es eher nichts für dich.
20 euro. Das bei amazon wäre mir auch zu teuer :D
Ja, komme wohl nicht drumrum. :)
Sicher gibts fertige liberis. Nur dannnist ja 80% meines codes von wem
anders :)
Und bestimmt lässt sich hier und da auch was optimieren. Bin zwar noch
nicht so erfahren, aber ich lerns gern.
Naja, viele Wege führen nach ROM. Eine Sparvariante für kleine/langsame
LCDs/uCs ist ein Oszi für Arme, das nicht echt scrollt sondern den
virtuellen Schreibzeiger einfach von links nach rechts durchlaufen läst
und dabei den alten Punkt dieser Spalte löscht und den neuen setzt. So
wie man es aus dem Film von EKG Geräten kennt.
Sascha 712 schrieb:> Kann ich den mit der literatur im zweitem post den wirklich was mit dem> atmega anfangen?
Wohl eher nicht.
Weißt du, im Prinzip ist das Ganze doch recht einfach: Wenn man ein
Display mit Controller hat und dennoch wenigstens so einigermaßen frei
sein will mit der Anzeige, dann muß man sich im (hoffentlich vorhandenen
RAM) einen Bildpuffer einrichten, den man nach getaner Zeichenarbeit
komplettiko in das Display kopiert. Bei einfachen monochromen Displays
kommt man da mit einem normalen Achtbitter zurecht, weil der RAM dafür
ausreicht. Bei bunten TFT's hört das Ganze auf, weil man recht bald viel
mehr RAM braucht, als der µC drin hat - und so ab 480x272 braucht es nen
so großen RAM, daß damit die meisten Achtbitter überfordert sind, da ist
dann ein 32 Bitter vonnöten.
Ansonsten, was das eigentliche Zeichnen von diversen Dingen betrifft,
brauchst du dafür eine nette Sammlung von Funktionen, denen man
salopperweise Namen wie GDI usw. gegeben hat - da tummeln sich im
wesentlichen Funktionen für:
- Pixel setzen
- Linien zeichnen
- Kreise zeichnen
- Flächen füllen
- Text zeichnen
- Bilder zeichnen
und dazu gehören natürlich Fonts in einem Format, was das jeweilige GDI
auch versteht. Guck mal hier in der Codesammlung nach der Lernbetty,
dort findest du so ein GDI nebst einigen Fonts, obendrein ein Tool, um
sich selber nen Font zu machen. Das Ganze ist zwar für nen 32 Bitter
(hier ARM7) geschrieben, aber in simplem C ohne Besonderheiten. Sollte
also auch für einen AVR fast ohne Änderungen benutzbar sein - wenn man
mal von den Pointerbesonderheiten beim AVR (const oder nicht) absieht.
Dieselbe Quelle läuft bei mir auch auf anderen µC mit anderer Endianess
(Motorola und Fujitsu), sollte also universell genug sein.
Naja, andere habens ja auch geschafft fortlaufende Oszilografen
hhinzubekommen :D
Das Buch aus dem Link ist doch gar nicht das von Amazon.
Naja, werde mich langsam dran wagen.
Werde denke erstmal mit dem 128x64 Display arbeiten. Das ILI9341 scheint
doch recht kompliziert zu sein. Und außerdem hab ich keinen Pegelwandler
von 5 auf 3,3 Volt :) Und ob ich das einfach mit Spannungsteiler
arbeiten soll? Weis nicht, klappt sowas den bei den frequenzen vom SPI?
>Das Buch aus dem Link ist doch gar nicht das von Amazon.
Na toll. Da hab' ich 'nen Bock geschossen. :-) Entschuldigung.
Allerdings solltest Du es trotzdem lesen. Das Thema stimmt.
Ja, W.S. da hast/haben du/sie schon recht.
Ich geb mich am anfang ja erstmal mit Monochrom zufrieden. Hab ja auch
kein bestimmtes ziel vor augen. Es geht erstmal ums verstehen und
schauen was möglich ist. Dann kann ich mir auch was nützliches dazu
ausdenken :)
Momentan nutze ich ja nur HD44780 LCDs und die sind ja recht primitiv.
Daher auch meine Überlegung was mit Grafikdisplays zu machen.
Das ganze wird sich wie gesagt nur in 2D abspielen und wenn überhaupt
nur in 16 Farben(falls ich irgendwann dazu komme das ILI9341 zu
benutzen)
Ich müsste also im Grunde auf dem uC erstmal nen Bildpuffer anlegen?
1
intLCD[64][128]=
2
{{0,0,0,0,0,0,0.........0,0,0,0}
3
{0,0,0,0,0,0,0.........0,0,0,0}
4
{0,0,0,0,0,0,0.........0,0,0,0}
5
{0,0,0,0,0,0,0.........0,0,0,0}
6
....
7
{0,0,0,0,0,0,0.........0,0,0,0}
8
{0,0,0,0,0,0,0.........0,0,0,0}}
Je nachdem ob ein Pixel gesetzt wird oder nicht, setze ich eine 0 oder
eine 1 in die jeweilige Array Position. Sollte man eig. einen anderen
Datentyp nehmen? int reserviert doch mehr Speicher als nur 1 Bit? Oder
wie läuft das ganze ab?
Weil rechnerisch brauch ich ja nur 1 Kbyte für das monochrome 128x64
Display.
Als nächstes würde ich ja mit entsprechenden Funktionen etc. in diese
Array das Bild aufbauen. und dann würde ich jeden einzelnen Pixel ans
LCD senden, indem ich ihm erst die Adresse mitteile und dann ob der
Pixel gesetzt wird oder nicht?
Dauert das nicht "vergleichsweise" ewig? Weis ja nicht wie der
Datendurchsatz von SPI so ist, hab ich auch noch nichts mit gemacht :)
bzw. bin ich dabei.
Könnt ihr mir nen 32 bit fähigen uC empfehlen, der sich ähnlich
programmieren lässt wie ein avr? Kenn mich außerhalb der 8bit welt eher
schlecht damit aus.
Evtl auf nem entwicklungsboard, weil das wird es wohl nicht als DIP
geben :)
Pauschal, d.h. ohne ein konkretes Display lässt sich über die notwendige
resp. angemessene Speicherorganisation nichts sagen. Suche Dir einfach
mal einige Displays raus und schaue Dir die Datenblätter dazu an.
Aber soweit ist es richtig, das ein Integer in der Regel mehr als ein
Bit umfasst. Ob Du nun aber ein Integer, ein Byte oder was auch immer
nimmst hängt vom konkreten Display ab.
Bei monochromen Displays wird in der Regel ein Byte mehrere Pixel
kodieren.
Ob aber nun ein Byte vertikal oder horizontal angeordneten Pixel
entspricht, ist nirgendwo festgelegt - allerdings ist die waagerechte
Anordnung, soweit ich weiß, üblicher.
D.h. bei einem 64 * 128 Pixel Display könntest Du etwa
uint8 BildSpeicher[8][16];
oder
uint16 Bildspeicher[4][8];
schreiben.
oder sogar,
uint32 Bildspeicher[2][4];
Was am effezientesten ist, hängt von der Wortbreite des Prozessors ab.
Die erste Adresse enthielte dann, wenn der Koordinatenursprung (0,0)
oben, links liegt (was auch nicht grundsätzlich so sein muß)
+-----+-----+-----+-----+-----+-----+------+-----+------+
| 0,0 | 0,1 | 0,2 | ... | 0,7 | ... | 0,15 | ... | 0,31 |
+-----+-----+-----+-----+-----+-----+------+-----+------+
-------------------------------------
Die Bewegung vom 8-Bit AVR weg zu einem 32Bit Prozessor ist allein schon
eine große Umstellung. Wenn Du in C programmierst, dann ist zwar einfach
ein 32Bit-Typ der "natürliche" aber es gilt immer noch, das Du in C den
den Daten angemessenen Typ benutzt. Nach den 32Bit richtest Du Dich
genau dann, wenn Geschwindigkeit und Effizienz bei einer bestimmten
Aufgabe wichtige Faktoren sind. Aber warum sollte man 32 Bit bei
ASCII-Strings benutzen? Das geht weiterhin gut mit 8Bit.
Die größte Umstellung wird Dich bei der Programmierung der Peripherie
treffen. Die 32Bitter haben in der Regel wesentlich komplexer zu
programmierende Peripherie. Obwohl am Ende eigentlich dem Wesen nach
gleich, gibt es doch mehr Betriebsmodi von Timern und UART etc. Dann
gibt es oft noch DMA und die Interrupts lassen sich, anders als beim AVR
häufig noch konfigurieren, was Du vom AVR nicht kennst.
Ich schlage Dir als Anfang die STM32-Prozessoren vor. Da gibt sehr
günstige Boards.
-------------------------------
Aber wiegesagt, schaue Dir erstmal die Datenblätter einer Reihe von
Displays an.
Sascha712 schrieb:> Ich müsste also im Grunde auf dem uC erstmal nen Bildpuffer anlegen?> int LCD[64] [128] => {{0,0,0,0,0,0,0.........0,0,0,0}
...
Nein. So schonmal nicht. Du willst ja 128x64 Bits, nicht 128x64
int mit je 16 Bits. Du wirst also wohl oder übel einzelne Bits in
einem entsprechend breiteren Datentyp verwenden müssen. Also z.B.
uint8_t und dann nur 1024 davon. Ob du das nun als eindimensionales Feld
oder zweidimensional machst, ist Geschmackssache.
Die viel wichtigere Entscheidung ist, wie du die einzelnen Bits in
deinem Array zu den Pixeln des Bildschirms zuordnest. Verschiedene
Grafikchips verwenden da durchaus verschiedene Methoden. Zwar
organisieren die meisten ihren Grafikspeicher in Bytes, aber bei manchen
sind die 8 Bits in einem Byte horizontal angeordnet, bei anderen
vertikal. Mal ist das kleinste Bit links, mal das größte.
Man kann, muß aber nicht, diese Organisation für seinen Display-Buffer
übernehmen. Für eine eigene Organisation sprechen:
* man kann Besonderheiten des Controllers wegabstrahieren, etwa daß ein
128x64 LCD mit KS0108 in Wirklichkeit aus zwei unabhängigen 64x64 LCD
besteht.
* man kann die Grafikroutinen für verschiedene LCD-Controller gleich
lassen und muß nur die eine Funktion, die den Grafik-Buffer auf das LCD
schiebt, an den Controller anpassen.
Dagegen spricht vor allem, daß die letztgenannte Funktion schnell sein
muß. Deswegen wird man da kaum komplexe Transformationen wie das
Spiegeln eines Bytes o.ä. drin machen wollen.
> Als nächstes würde ich ja mit entsprechenden Funktionen etc. in diese> Array das Bild aufbauen. und dann würde ich jeden einzelnen Pixel ans> LCD senden, indem ich ihm erst die Adresse mitteile und dann ob der> Pixel gesetzt wird oder nicht?
Nicht wirklich pixelweise. Sondern in der Breite, die das LCD entgegen
nimmt. In der Regel sind das Bytes, also immer 8 Bit auf einmal.
> Dauert das nicht "vergleichsweise" ewig?
Typische LCD-Controller wie der KS0108 brauchen ca. 10µs für ein Byte.
Die 1024 Byte für ein 128x64 Display sind also in 10ms kopiert. Wenn man
die beiden Teildisplays verschachtelt anspricht, reichen sogar 5ms. Also
100 bzw. 200 Auffrischungen pro Sekunde. Schnell genug.
XL
