Bedingung wird nicht Wahr

[Sam (Gast)]

Hallo,

hab ein Problem mit einem Teil meines Codes,
und zwar wird eine Interruptroutine, in die eine if-Aweisung 
implementiert   ist aufgerufen. Die If Anweisung soll erst dann als war 
betrachtet werden, wenn ich auf der Tastatur die Entertaste Drücke.

In die If Anweisung wird jedoch nie reingesprungen.

Weiß jemand woran es liegen könnte??
ist was am Code falsch??



if(interruptflag&0x04) // Abfragen, ob Sende- oder Empfangsinterrupt
{
 IEN=0;                                      //Interrupt´s Aus

 *readpointer  = Receiver_Buffer_Register;   // Zeichen von UART 
einlesen
 putchar(*readpointer);               // normale Zeichen werden 
ausgegeben

  if (*readpointer == '\n')             //<---wird nie als Wahr 
Akzeptiert
   {                        trigger = 2;
    putchar('A');                           //Test Ausgabe
   }

IEN=1;

printf("tr = %d ", trigger);                // Test Ausgabe
putchar('B'); putchar('\n');                //Test Ausgabe

readpointer++;

}

[yalu (Gast)]

Bist du sicher, dass für die Enter-Taste ein '\n' (LF) und nicht ein
'\r' (CR) gesendet wird? Probier's einfach mal mit '\r'.

[Sam (Gast)]

bei windows sind es sogar zwei zeichen   \r\n wobei das \n das letzte 
von beiden ist.

[Sam (Gast)]

bei windows sind es sogar zwei zeichen   \r\n wobei das \n das letzte 
von beiden ist.

aber komischer weise geht´s hier mit \r.

Gleicher Quellcode nur eine andere Interruptroutine und dort klappt es 
auch mit \n, ich glaube das muß man nicht verstehen.

oder hat einer eine Idee wieso es hier klappt??

else if (interruptflag&0x02)
{
  if (*writepointer == '\n')   \\ <-----klappt
      trigger = 1;

  putchar('\n');
  printf("trigger1 = %d  ", trigger);
  Transmitter_Holding_Register = *writepointer;  // Zeichen auf UART 
schreiben
  writepointer++;
  putchar('b'); putchar('\n');

}


info: Prgrammiere uC(c167) mit Keil und Versuche einen UART in gang zu 
bringen.

[yalu (Gast)]

Ein klassisches Terminal (z.B. ein VT100) sendet bei Drücken der
Enter-Taste einen CR, das hat mit unterschiedlichen Betriebssystemen
zunächst nichts zu tun. Deswegen machen das Terminalemulationsprogram-
me (Minicom, Hyperterm usw.) genauso. Man kann allerdings viele
Terminals bzw. Emulatoren so umkonfigurieren, dass bei Enter ein CR+LF
oder auch nur ein LF gesendet wird. Der Default ist aber ein einzelnes
CR.

Dein erstes Beispiel zeigt die Empfangsroutine, die Zeichen wahr-
scheinlich von einem Terminal empfängt. Deswegen ist es richtig, auf
CR abzufragen.

Das zweite Beispiel ist die Senderoutine. Die Zeichen stammen nicht
vom Terminal, sondern von deiner Controllersoftware, und diese
verwendet offensichtlich ein LF ('\n') am Zeilenende, wie in C üblich.

Streng genommen müsstest du am Zeilenende sowohl einen CR (setzt den
Cursor an den Anfang der aktuellen Ausgabezeile) also auch einen LF
(bewegt den Cursor eine Zeile tiefer an der gleichen Horizontalposi-
tion) ausgeben. Vielleicht tust du das ja auch. Aber auch hier können
die Terminals oft so umkonfiguriert werden, dass ein einzelner CR oder
LF wie die Kombination aus CR und LF behandelt wird.

Das ganze CR/LF-Gedöns stammt noch aus der Zeit der Fernschreiber, wo
die beiden Steuerzeichen mechanisch umgesetzt wurden. CR ist der
Wagenrücklauf, LF dreht die Papierwalze um ein Zeile weiter. Im
Elektronikzeitalter wäre es sinnvoller und weniger verwirrend, diese
beiden Zeichen durch ein einzelnes namens LE (Line End) zu ersetzen,
das sowohl bei der Eingabe, bei der Ausgabe als auch in Textdateien
verwendet wird.

In Unix/Linux/C und auf den Apple-Rechnern wird das prinzipiell auch
so gemacht, indem nur ein Zeichen (LF in Unix/Linux/C bzw. CR bei
Apple) ein Zeilenende markiert. Die Konvertierung für Ein-/Ausgabe-
geräte, die nach dem klassischen Standard arbeiten, macht das
Betriebssystem. Nur bei hardwarenaher Programmierung schlägt die
Unterscheidung zwischen CR und LF bei Ein- und Ausgabe manchmal noch
zu.

DOS/Windows verhält sich diesbezüglich noch "fernschreibermäßig", was
die Kommunikation mit Ein-/Ausgabegeräten oft etwas erleichtert. Dafür
mussten in die Standardbibliothek des aus der Unix-Welt stammenden C
Krücken eingebaut werden, um zwischen den beiden unterschiedlichen
Zeilenendedarstellungen zu konvertieren.

[Sam (Gast)]

Echt eine Super Erklärung. Danke.