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ß
Angehängte Dateien:
-
img1.PNG
4,4 KB
Ohne den Code zu sehen, ist das schwer zu sagen. Die UART-Ausgabe machst Du per Interrupt?
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.
Heißt das, wenn ich die Baudrate auf 115kBaus erhöhe, wird dadurch auch die ausgabe schneller?
Marco G. schrieb: > Welche Alternative gibt es, solch ein Menü zu realisieren? Schau Dir mal MCURSES an.
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.
Ok, dann werde ich es mal mit einer höheren Baudrate probieren. Wie genau kann ich ein ganzes Bildschirmbild als Array abspeichern?
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!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.