Hallo,
ich habe über UART im HyperTerminal ein kleines Menü zur Anzeige
gebracht. Nun wollte ich zweckmäßigerweise mit Pfeiltasten navigieren,
und bin da auf unerwartete Probleme gestoßen, da diese nicht zur ASCII
Tabelle gehören.
Ich dachte, naja, guck ich doch einfach mal, was mir HyperTerminal
zurücksendet. Es werden immer zwei Bytes gesendet:
1. Byte 91d bzw 133okt
2. Byte 91d bzw 133okt
Egal, welche Taste ich drücke, es kommen immer diese beiden Bytes an!
Hat jemand ne Ahnung, wie man Pfeiltasten erkennen kann?
Pfeiltasten werden bei entsprechend gesetzteer Terminalemulation mit dem
ESCAPE Zeichen (27) und "[" eingleitet und dann, je nach Pfeiltaste, mit
"A", "B", "C" oder "D" beendet.
Aus ner Atmel Appnote Nr. vergessen:( "Terminaldriver.c" jedenfalls.
Sollte sich im Netz finden lassen.
Term_Get() ist die normale USART Empfangsroutine, welche ein ASCII
Zeichen von der seriellen empfängt, nichts weiter.
Gruß
Axelr.
Okay danke!
Also ich habe schon gewusst, dass mehrere Zeichen hinterheinander
gesendet werden für die Pfeiltasten.
Ich habe die UART Abfrage im Moment so:
1
if(UCSR0A&(1<<RXC0))
2
{
3
summe+=UDR0;
4
}
So. Wenn ich das Programm starte, und eine der Pfeiltasten drücke,
müsste ja eins von denen
27 + 91 + 65 = 183
27 + 91 + 66 = 184
27 + 91 + 67 = 185
27 + 91 + 69 = 186
herauskommen. Ich drücke, DANACH halte ich das Programm im Debugmodus an
und drücke nochmal was. Dann sehe ich ja in der Variablen summe die
Summe.
Hier steht - egal welche der Pfeiltasten ich drücke - immer eine 182
drin.
Jürgen Hems schrieb:> Okay danke!> Also ich habe schon gewusst, dass mehrere Zeichen hinterheinander> gesendet werden für die Pfeiltasten.>> Ich habe die UART Abfrage im Moment so:>
1
>if(UCSR0A&(1<<RXC0))
2
>{
3
>summe+=UDR0;
4
>}
5
>
Mit Verlaub, aber das ist Murks.
Empfange ein Zeichen.
Stell fest dass es den Wert 27 (= Escape) hat
Als Folge davon weißt du, das das noch nicht alles war -> nächstes
Zeichen empfangen etc.
Da mit Summen zu hantieren ist Blödsinn.
Schon alleine daran zu erkennen, dass du keine Möglichkeit hast,
vernünftiges Debugging zu betrieben wie zb: einfach mal das was
empfangen wurde als Hex-Zahlen wieder auszugeben, um zu sehen was da
über die Leitung kommt.
Dass du hier so dermassen im Nebel stocherst, ist eine direkte Folge
davon, dass du dich um eine vernünftige Auswertung von empfangenen
Zeichen drücken willst.
Jürgen Hems schrieb:> Also ich habe es im Debugmodus getestet, das erste empfangene Zeichen> war 91 ;-(
Ich kann mich nur wiederholen
> Dass du hier so dermassen im Nebel stocherst, ist eine direkte> Folge davon, dass du dich um eine vernünftige Auswertung von> empfangenen Zeichen drücken willst.
Mach dir ein Testprogramm, welches für jedes empfangene Zeichen seinen
Hex Code ausgibt, drück auf die Taste und dann weißt du es ganz genau.
Da 91 (also '[' in der Cursor-Tasten Sequenz ja tatsächlich vorkommt,
hast du höchst wahrscheinlich irgendwo anders das Escape verschlampt.
Am besten machst du dir eine einzige Empfangsroutine, die ein
empfangenes Escape auswertet.
Für die Cursorsteuerung definierst du dir programmintern eines der
unteren ASCII-Steuerzeichen um. Zb. könntest du (für dich) definieren:
Deine Zeichenempfangsroutine liefert 0x04 bei Cursor links
0x05 rechts
0x06 rauf
0x07 runter
Die zentrale Empfangsroutine liefert jetzt alle Zeichen ganz normal, es
sei denn sie bekommt ein Escape vorgesetzt. In dem Fall merkt sie sich
diesen Escape (in globalen Variablen) und liefert zunächst mal ein 'Ich
hab kein Zeichen für den Aufrufer' wenn es sich um eine nicht wartende
Funktion handelt. Bei den nächsten Aufrufen werden dann die
eintrudelnden Zeichen aufgrund des vorhergehenden Escapes anders
ausgewertet, bis feststeht ob es eine Cursor-Taste war und wenn ja
welche.
