Moin,
ich würde gerne ein Menü per UART(Wie im Anhang zu sehen)realisieren.
Ich dachte daran, das ganze mittels VT100 auszuführen. Merkwürdigerweise
wird ohne weitere delays der Code extrem langsam. Weiß jemand, was
ich(grundsätzlich) falsch mache? Oder ist es normal, dass code mit
vielen VT100 befehlen langsam wird?
Welche Alternative gibt es, solch ein Menü zu realisieren?
Gruß
Nein, außer der VT100 Ausgabe läuft nur noch ein Counter und eine
Berechnung. Aber das bringt mich auf eine Idee. Wahrscheinlich kann ich
mir viele befehle sparen. Ich werde mal versuchen, das Grundbild beim
start zu erschaffen und dann nur noch die dynamischen Inhalte zu
aktualisieren.
Das hängt auch von deiner Baudrate ab. Das VT100 braucht z.B. für die
Cursorpositionierung 8 Zeichen plus das Zeichen, das du ausgeben willst.
Wenn du mit 9600Baud arbeitest, braucht ein Zeichen ca. 1ms. Wenn du
viel Positionierungen drin hast, wird das sehr langsam.
Marco G. schrieb:> Baudrate auf 115kBaus erhöhe
Klar wird die Ausgabe dadurch schneller und Dein µC verbraucht weniger
Zeit im TX-Interrupt.
Zusätzlich solltest Du deine Idee, nur noch die Deltas auszugeben,
weiter verfolgen. Wenn der RAM von Deinem µC groß genug ist, dann kannst
Du den Bildschirm als Array definieren und dort die Änderungen
hineinschreiben.
Dann rufst Du bei Bedarf eine Update-Routine auf, die nur die Deltas aus
dem Array an das Terminal ausgibt.
Dann wird das sehr zügig.
Peter M. schrieb:> ... und Dein µC verbraucht weniger Zeit im TX-Interrupt.
Geht es bei 115kBd schneller, das nächste Byte ins Transmit Register zu
schreiben, als bei 9600Bd?
Wolfgang schrieb:> Geht es bei 115kBd schneller, das nächste Byte ins Transmit Register zu> schreiben, als bei 9600Bd?
Was ich geschrieben habe:
Peter M. schrieb:> Dein µC verbraucht weniger> Zeit im TX-Interrupt.
ist nicht ganz korrekt beschrieben.
Was ich damit sagen wollte ist, dass das Versenden der Daten, bedingt
durch die höhere Baurate, schneller geht.
Der TX-Interrupt wird in kürzeren Zeitabständen aufgerufen.
Damit wird auch das Transmit Register, logischer Weise, schneller mit
dem nächsten Wert geladen.
Und, was ich annehme, da Marco das Versenden im Pollingmodus macht, hat
die höhere Baurate auch darauf direkten Einfluß.
Marco G. schrieb:> Wie> genau kann ich ein ganzes Bildschirmbild als Array abspeichern?
Du legst Dir ein Array von der Größe des Bildschirms an. Bspw. 80x25
Bytes groß, also 2000 Bytes, an.
array[0] ist dann Zeile 1 Spalte 1. array[1] ist Zeile 1 Spalte 2, usw.
Wenn Du nur mit ASCII Zeichensatz arbeitest, dann kannst Du das MSB (Bit
7) benutzen um eine Änderung zu kennzeichnen.
Die Update (Ausgaberoutine) überprüft dann, ob dieses Bit gesetzt ist
und
gibt nur den neuen Wert für diese Position aus.
Nach der Ausgabe wird das Bit gelöscht.
Das klingt vielleicht etwas kompilziert, verbessert jedoch die gesamte
Performance bei der Ausgabe.
Und Du hast den Vorteil, dass Du nur dann die Bildschirmausgabe machen
musst, wenn es notwendig ist.
Alternativ kopiert die Ausgaberoutine das gesamte Array, ohne Bewertung
des Bit 7 auf den Bildschirm. Bit 7 wäre in diesem Fall obsolete.
Und zwar so, dass nur eine Positioniersequenz an den Bildschirmanfang
ausgegeben wird und danach die Daten an einem Stück ausgegeben werden.
D.h., ohne ESC-Sequenzen zur Positionierung.
Das Terminal macht nach dem 80. Zeichen, meist automatisch einen Sprung
in die nächste Zeile.
Die alten VT100 konnten das, ob es Putty kann, weiss ich nicht.
Das sind meine Überlegungen dazu.
Nachtrag:
Wenn Du mit einem Array arbeitest und die alternative Methode zur
Ausgabe benutzt, dann löschst Du den Bildschirm in dem Du 0x20
(Leerzeichen) in das array schreibst.
Ein weiterer Vorteil ist, dass intern mit Distanzen auf das array
zugreifen kannst.
Ich meine damit, dass Du das Grundbild direkt bei der Definition des
Arrays anlegen kannst und Dir per #define die Distanzen dazu erstellst.
D.h., die Distanzen zeigen auf den Anfang des Feldes in Deiner Maske,
die mit den entsprechenden Daten gefüllt werden.
Viel Erfolg!
Peter M. schrieb:> Damit wird auch das Transmit Register, logischer Weise, schneller mit> dem nächsten Wert geladen.
Die Zeit, die der µC zum Laden des Registers in der ISR verbringt, hängt
einzig und alleine von der Datenmenge ab und ist völlig unabhängig von
der Datenrate. Die Übertragung geht bei höherer
Übertragungsgeschwindigkeit natürlich schneller, weil das Produkt aus
Geschwindigkeit und Zeit immer gleich dem Datenvolumen ist.
Wolfgang schrieb:> Die Zeit, die der µC zum Laden des Registers in der ISR verbringt, hängt> einzig und alleine von der Datenmenge ab und ist völlig unabhängig von> der Datenrate.
Das ist nicht korrekt!
Die Datenmenge hat damit überhaupt nichts zu tun.
Schauen wir uns einmal so einen Vorgang einmal an:
Die UART-ISR wird nach dem versenden des ersten Bytes aufgerufen,
lädt das nächste Byte in den TX-Buffer und kehrt zurück.
Und genau darum geht es:
Bei 115200 Baud ist das Byte schneller versendet, als bei 9600 Baud und
die UART-ISR wird entsprechend schneller wieder aufgerufen. In diesem
Fall
12 fach schneller!
Es ist unerheblich wieviel Bytes gesendet werden soll, an der
Aufruffrequenz der UART-ISR ändert dies nichts!
Das Laden des TX-Registers dauert allerdings immer die gleiche Zeit, da
dies von Taktrate des Prozessors abhängig ist und NICHT von der
Baudrate.
Wolfgang schrieb:> ist völlig unabhängig von> der Datenrate.
Diese Aussage ist schlicht Quatsch!
img1.PNG
(4,4 KB)
