serieller(UART) Zeilenumbruch flexibler gestalten unter C

[oderlachs]

Hallo Freunde !
Ich muss mal wieder in die Runde fragen. Es geht mir um die Ausgabe einer neuen Linie über den UART beim PIC.

Ich bewerkstellige das zZt etwa so:

#define BD_RATE 9600 // Baudrate

#include <xc.h>
#include "uart.h"
//***************************************************************
void main(void) {
    UART_Init(BD_RATE);
    while(1){
    UART_Write_Text(" Mein Text\r\n"); // "\r\n" = Neue Zeile
    __delay_ms(1000);}
    return;
}

//***************************************************************

void UART_Write_Text(char *text)
{
  int i;
  for(i=0;text[i]!='\0';i++)
  {
      UART_Write(text[i]);}
  
}

//***************************************************************

void UART_Write(char data)
{
  while(!TRMT);
  TXREG = data;
}

//***************************************************************

Ich komme einfach nicht dahinter, wie ich einen Zeilenumbruch flexibler einsetzen kann.

Es ist doch unpraktisch, immer "\r\n" in den zu schreibenden String etc. einzufügen, besonders wenn man Werte von Variablen schreiben möchte.

Kann mir da mal wer "in den Achtersteven treten" ,um mich gedanklich anstossen ??

Gruss und Dank

Gerhard

[BMS]

Hallo,
am einfachsten fügt man in die Write_Text Methode einfach noch \r und \n mit ein:

void UART_Write_Text(char *text) //kann man natürlich auch umbenennen
{
  int i;
  for(i=0;text[i]!='\0';i++)
  {
      UART_Write(text[i]);}
  UART_Write(13); // ist \r
  UART_Write(10); // ist \n
}

Grüße,
Bernhard

[Peter(TOO)]

@Gerhard

Es ist doch unpraktisch, immer "\r\n" in den zu schreibenden String etc. einzufügen, besonders wenn man Werte von Variablen schreiben möchte.

Der Compiler ersetzt "\r" und "\n" mit den entsprechenden Steuercodes.
Wie Bernhard gezeigt hat kann man
UART_Write_Text(char *text);
und
UART_Write_Text_NL(char *text);
verwenden.


@Bernhard

void UART_Write_Text(char *text) //kann man natürlich auch umbenennen
{
  int i;
  for(i=0;text[i]!='\0';i++)
  {
      UART_Write(text[i]);}
  UART_Write(13); // ist \r
  UART_Write(10); // ist \n
}

Das ist nicht ganz sauber so, man sollte besser

  UART_Write('\r');
  UART_Write('\n');

Der Compiler übernimmt dann die Übersetzung in den passenden Steuercode.
Den Unterschied merkt man aber erst dann, wenn man einen anderen Zeichensatz als ASCII verwendet.

MfG Peter(TOO)

[oderlachs]

Ich danke Euch beiden für "Den Tritt in den Achtersteven"....

Berhard's Beispiel hatte ich schon probiert nur eben fehlte das "\n" bzw.. chr10....
Das ich den Code auch so schreiben kann:

UART_Write('\r');
UART_Write('\n');

wusste ich noch nicht..ist ja auch Compiler abhängig....

Euch Beiden nochmals vielen Dank

Gruss

Gerhard

[oberallgeier]

.. Das ich den Code auch so schreiben kann .. wusste ich noch nicht .. ist ja auch Compiler abhängig ..

Soweit ich weiß gibts Compiler?? und/oder Terminals?? die so nen AutoLinefeed haben - evtl. wählbar mit z.B. [CR=LF]. Da reicht dann ein simples \r . Bei meinen Compilern (Studio4/Winavr bzw. Studio7) schreib ich fürs br@y-Terminal immer nur "\r".

[Peter(TOO)]

Hallo Gerhard,

wusste ich noch nicht..ist ja auch Compiler abhängig....

Nein, das ist Standard-C, gab es schon in K&R.

"Text" ergibt einen String, welcher mit \0 terminiert ist.
't' ist ein einzelnes Zeichen und es gibt kein \0 am Ende.

MfG Peter(TOO)

[oderlachs]

Ja Peter ich glaube es Dir...wir hatten wir ja in der Programmierausbildung auch so gelernt ...damaaaals. Aber das was alles MS-C/C++ da war doch einiges anders...und vieles vergessen...
...auch die XC8/16 Compiler(Mircrochip) sind für mich als Einsteiger in PIC doch noch etwas gewöhnungsbedürftig....na ja man lernt ja dazu.

Gruss
Gerhard

[Peter(TOO)]

Soweit ich weiß gibts Compiler?? und/oder Terminals?? die so nen AutoLinefeed haben - evtl. wählbar mit z.B. [CR=LF]. Da reicht dann ein simples \r . Bei meinen Compilern (Studio4/Winavr bzw. Studio7) schreib ich fürs br@y-Terminal immer nur "\r".

Das liegt am Betriebssystem.
CRLF kommt noch von den alten TTY, die Fernschreiber brauchten da einzelne Befehle.
Die Drucker übernahmen das dann.
Damals war dann Fettschrift mit mehrmaliger Ausgabe des selben Textes mit nur einem CR.

Unter Unix/Linux wird normal nur CR verwendet. Der Treiber expandiert dies dann zu CRLF.
Allerdings kann man den Treiber über Befehle konfigurieren. Will man binäre Daten übertragen, stört das automatische expandieren. Die einfachste Variante ist bei open(); den b-Parameter anzugeben (b = binary).

MS war so ein Treiber scheinbar zu komplex, der kann seit DOS nicht automatisch expandieren.

MfG Peter(TOO)

- - - Aktualisiert - - -

Hallo Gerhard,

Bei meinem " ...damaaaals." gab es MS-C/C++ noch gar nicht. Da hatte MS erst BASIC im Verkauf.
Meine ersten 10 Jahre bestanden aus diversen BASIC und Assembler (6502, 8080 und Z80). C kam dann bei mir erst 1986 dazu.

MfG Peter(TOO)

[oderlachs]

Nun Peter, bis 91 war ich nur vom HF-Bazillus infiziert...die Bits und Bytes kamen dann so 1992....mit dem C64...AT8085(ASSR/BASIC/Pascal) usw... Ich liege in Sachen PC wohl so 10 Jahre hinter Dir...

[Peter(TOO)]

Nun Peter, bis 91 war ich nur vom HF-Bazillus infiziert...die Bits und Bytes kamen dann so 1992....mit dem C64...AT8085(ASSR/BASIC/Pascal) usw... Ich liege in Sachen PC wohl so 10 Jahre hinter Dir...

HF war nie wirklich mein Ding. Mich faszinierte Analog und Digital mehr. Fundierte HF-Grundlagen habe ich, die benötigte man damals auch um 74Sxx-Schaltungen fehlerfrei zum laufen zu bringen.
Mein Onkel hatte ab 1972 einen Wang 2200, für seine Buchhaltungen als Treuhänder. Damals habe ich Klingonen abgeschossen, natürlich mit reiner ASCII-Graphik.
Und 1976 musste ich dann an die Mikroprozessoren ran. Mein damaliger Lehrmeister kam auch an der HF und fand digital langweilig. Folglich wurde ich dazu "verknackt" die µP zu betreuen. Wie bekamen damals ein Projekt eines Geldspielautomaten, welches ein Software-Typ entwickelt hatte, leider auch die Hardware. Das Hauptproblem war, dass wenn der Auszahl-Magnet angesteuert wurde, der µP immer aus dem Programm flog. Nach dem Einbau von 220nF und 100nF am 7805 hat es dann funktioniert.
Ich musste dann das ganze Hardwarekonzept überarbeiten und im Netzteil waren noch ein paar grobe Fehler.
Und am Schluss wurde ich dazu verdonnert die Testprogramme für die Hardware auf einem KIM-1 zu schreiben.

Das nächste war dann BASIC, da habe ich einen Cross-Assembler für den 6502 auf dem Wang geschrieben.

1978 kam dann ein S100-Bus System mit CP/M 1.4, 8080 Assembler und CBASIC hinzu. Und etwas später ein Apple][ mit DOS, später UCSD-Pascal und Z80-Karte mit CP/M 2.2.

So sammelt sich etwas Wissen mit der Zeit.