Hallo Gerd,
1. Lesen vom Port
Die drei Aussagen
- Weil ich mir nicht sicher bin, ob bei einer kompletten, neuen Seite nicht schneller ein neues Paket kommt.
- Weil ich denke, dass es sich so leichter auf andere Anwendungen anpassen lässt
- Weil das Problem nicht beim Lesen von der Schnittstelle liegt, sondern bei der Aktualisierung der Tabelle (und dort bei der Grafik)
gehören zusammen und beziehen sich nur auf Deinen Vorschlag eine feste Anzahl Bytes mit einem festen Timeout zu lesen.
Welche Möglichkeiten gibt es, den Lese-Rythmus zu bestimmen?
1. Termination-Charakter, bei diesen ESC-Sequenzen kann man "\1B" nehmen. Dann wird aber jede Sequenz einzeln an die Datenauswertung und an die Anzeige übergeben. Das habe ich probiert und verworfen...
2a. "BytesAtPort" abfragen und die anstehenden Daten lesen.
2b. Eine feste Anzahl Bytes und einen passenden Timeout vorgeben.
3. Flow-Control. Hab' ich hier nicht und ist wohl eher selten...
Habe ich da noch etwas übersehen?
Ich habe mich für 2a entschieden, weil
a) es vielleicht Fälle gibt (z.B. bei einer statischen Seite) bei denen ein kleineres Paket gesendet wird.
b) das Lesen (hoffentlich) so auch mit anderen seriellen Schnittstellen funktioniert.
c) ich keinen Grund sehe an dieser Stelle noch irgendwelche Millisekunden zu gewinnen.
2. Software-Struktur
Deinen Vorschlag ein Producer-Consumer-Schema zu verwenden, hatte ich aufgegriffen und ausprobiert.
Dadurch kann schon das nächste Paket von der Schnittstelle gelesen werden, während das vorherige verarbeitet wird.
Das funktioniert aber nur, wenn alle Consumer schnell genug sind! Anderenfalls sammeln sich die Daten halt nicht am Port, sondern im Queue.
Zitat:Code sollte immer nur eine möglichst klar umrissene Aufgabe erfüllen! Und das sollte nicht sowas sein wie "seriellen Port schnell bedienen & gesamten Datenblob verarbeiten & komplizierte Anzeige aktualisieren" - das sind 3 ganz klar getrennte Aufgaben!
Hier denke ich genau entgegengesetzt! (auch ein Zitat
)
Es bringt doch nichts, wenn ich den seriellen Port schnell bediene und die Daten auch noch schnell genug verarbeite, aber die Anzeige nicht in der gleichen Zeit aktualisiert bekomme.
Weil das eben keine getrennten Aufgaben sind, bestimmt die langsamste Schleife die Ausführungsgeschwindigkeit.
Auch sehe ich hier keine Möglichkeit, Aufgaben noch weiter zu parallelisieren, da die Abarbeitung des Streams in der Reihenfolge passieren muss.
In meinem vorletzten Versuch hatte ich das Aktualisieren noch in einer parallelen Schleife
Weil ich den Ablauf bei so einem kleinen Programm aber möglichst in einer Linie halte mag UND der letzte Versuch gezeigt hat, das die Anzeige gleich schnell aktualisiert wurde, habe ich es geändert.
3. String-Element und Schriftart
Ja, auch ein String lässt sich formatieren. Aber kann ich z.B. den Hintergrund eines einzelnen Zeichens ändern?
Zitat:Wenn ein User auf einem Standard-Windows keine Consolas-Schrift hat, dann hat der Admin geschlampt…
Da hast Du wohl recht, aber zunächst mal passt dann meine Software nicht.
Ach bei einem
non-proportional font sind "i" schmaler als "W", sie beanspruchen nur den gleichen Platz. Außerdem wird es durch Serife etwas ausgeglichen.
Aber wenn ein UI gut aussehen
MUSS, verwendet man keine Serife...
Ich habe mit der Tabelle ein bisschen rumprobiert und finde, mit einer mittigen Ausrichtung passt das auch mit anderen Schriftarten.
4. Fazit
Wesentliche Punkte bei der aktuellen Lösung sind
1. Die Datenauswertung in ein Array mit Changed-Flag.
- Dadurch werden in der Anzeige nur geänderte Felder aktualisiert.
- Sollte in einem Daten-Paket ein Wert zweimal vorkommen, werden die Felder im Array überschrieben und die Anzeige nur einmal aktualisiert.
2. Die Umsetzung des Array in die Tabelle innerhalb des xControls.
- Das geht schneller.
- Dadurch wird offenbar der Error 1604 vermieden.
Ich habe die Parallelisierung (siehe 2.) verworfen, weil es so für mich schnell genug funktioniert.
Vielleicht gibt es Fälle, wo man das nochmal aufgreifen muss.
Aber dann sollte man evtl. mehrmals das Daten-Array und nicht so oft die Anzeige aktualisieren.
Du hattest ja schon geschrieben, dass das nur 5-10x pro Sekunde sein muss.
/
Verarbeiten von ESC-Sequenzen (VT100)
