Uart, Empfangener String ist leer

[Susan (Gast)]

Hallo,

Ich versuche mit einem AtMega über Usart mit einer bereits bestehenden 
SPS zu kommunizieren. Die SPS soll mir einen String mit einem Namen 
schicken, den ich weiterverarbeite.

Es kommt auch ein String (6 Zeichen) beim µC an, lassen ich ihn mir aber 
über ein Terminalprogramm ausgeben wird nichts angezeigt.

Ich habe an den Usart-Pins einen Mux angeschlossen, da ich mit der SPS 
und dem PC kommuniziere. Teste ich das Programm statt mit der SPS mit 
dem PC, also sende den String über ein Terminalprogramm funktioniert es.

UART_USB;  //Mux wird auf USB eingestellt
  
char filename[33];      //vollständiger Dateiname
char dateiname_c[16];    //Empfangener Name von der SPS

uart_puts("Uuund...");    //Debuggen

UART_SPS;      //Mux auf SPS einstellen        
uart_gets(dateiname_c, 7);  //String empfangen
  
strcpy(filename, dateiname_c);  // Erstellung des Filenames
strcat(filename, ".TXT");
  
UART_USB;  //Mux auf USB einstellen
  
uart_puts(dateiname_c);    //Kontrolle
uart_puts(filename);

void uart_gets( char* Buffer, uint8_t MaxLen )
{
  uint8_t NextChar;
  uint8_t StringLen = 0;
 
  NextChar = uart_getc();         // Warte auf und empfange das nächste Zeichen
 
                                  // Sammle solange Zeichen, bis:
                                  // * entweder das String Ende Zeichen kam
                                  // * oder das aufnehmende Array voll ist
  while( NextChar != '\n' && StringLen < MaxLen - 1 )
  {
    *Buffer++ = NextChar;
    StringLen++;
    NextChar = uart_getc();
  }
 
                                  // Noch ein '\0' anhängen um einen Standard
                                  // C-String daraus zu machen
  *Buffer = '\0';
}

Auf meinem Terminal ist folgendes zu sehen:
Uuund....TXT
Der Auszug des Prgramms wird komplett abgearbeitet, aber dateiname_c 
wird leer angezeigt.

Ich arbeite mit 8N1, das auch auf die SPS passen sollte. Diese wurde vor 
längerer Zeit programmiert und es wurde mir von dem Programmierer mit 
einem Terminalprogramm demonstriert, dass dieses Format passt. Selbst 
kann ich das nicht überprüfen, da kein Laptop mit einer 
RS232-Schnittstelle vorhanden ist.

Ich weiß nicht genau woran das Problem liegen kann und erhoffe mir hier 
ein paar Tipps. Das Usart an sich funktioniert, nur mit der SPS nicht. 
Könnte es den sein, dass das Format 8N1 doch nicht passt? Bevor ich den 
Programmierer nochmal kommen lasse, möchte ich erst sicherstellen, dass 
ich keinen fehler gemacht habe.

Vielen Dank,
Susan

[Daniel V. (danvet)]

Wie so oft liegt das Problem in dem Codeteil, den du nicht zeigst :-(

Was macht uart_getc(), wenn nichts ankommt? Schreibt es lauter Nullen?
UART richtig initialsiert?
Was sagt der Debugger über den String "Buffer" an der Stelle *Buffer = 
'\0' , was steht drin?

[Susan (Gast)]

Sorry :).

uint8_t uart_getc(void)
{
     while(!(UCSRA0A & (1<<RXC0)))    //Warten bis Zeichen verfügbar
        ;
     return UDR0;       //Zeichen aus UDR zurückgeben
}

void uart_init()
{
   //set Baud-Rate
   UBRR0H = UBRRVAL >> 8;
   UBRR0L = UBRRVAL & 0xff;
   //set frame format: 8bit, no Parity, 1 stopbit
   UCSR0C = (1 << UCSZ01) | (1 << UCSZ00));
   //enable serial receiver and transmitter
   UCSR0B = (1 << RXEN0) | (1 << TXEN0) | (1 << RXIE0);

}

uart_getc wartet bis ein Zeichen kommt. Ich hatte zu Beginn RXD und 
TXD-Leitungen vertauscht und das Programm ist dann auch nicht 
weitergelaufen. Ich hatte auch ein Oszi dran hängen und es kommt was an.
Wenn ich statt mit der SPS mit einem Terminalprogramm kommuniziere 
funktioniert es, deswegen nehme ich an, dass mein UART korrekt 
initialisiert wurde. Sollte dem nicht so sein ist Aufklärung natürlich 
herzlich willkommen :).

Der String buffer ist dateiname_c.

Ich habe jetzt noch mit strlen die Länge von dateiname_c  bestimmt. Die 
ist 0 also sthet dort definitiv nichts drin. Ich verstehte nur noch 
nicht so ganz warum :).

Gruß
Susan

[Karl H. (kbuchegg)]

> 1 << RXIE0

Das passt nicht.
Man gibt keinen Interrupt frei, für den man keinen Handler hat.
Sowas wird mit Prozessorreset beim Empfang eines Zeichens geahndet.

[Susan (Gast)]

Das soll mal mit Interrupts laufen deswegen habe ich ihn schon 
freigegeben, werde es aber nochmal raus nehmen.

[Karl H. (kbuchegg)]

Solange du keinen sei() im Programm hast, gehts noch. Trotzdem ist das 
kein guter Stil. Vor allen Dingen dann nicht, wenn du nur Ausschnitte 
aus deinem Programm zeigst.

[Stefan E. (sternst)]

Die für mich interessantesten Fragen in diesem Thread sind:

1) Wie konnte das Programm mit dem frei geschalteten RXC-Interrupt 
überhaupt je über das uart_getc hinweg kommen?

2) Und wie ist dann das hier überhaupt möglich?
> Wenn ich statt mit der SPS mit einem Terminalprogramm kommuniziere
> funktioniert es

3) Last but not least, wie hast du die Funktion uart_getc überhaupt 
durch den Compiler bekommen?

[Susan (Gast)]

Danke für die vielen Antworten. Ich werde versuchen alle Fragen zu 
beantworten.
Das gesamte Programm ist mehre kByte groß, deswegen dachte ich, ich 
beschränke mich auf den wichtigen Teil.

1. Die Interrupts waren nicht eingeschalten

2.Je nachdem ob der Mux auf SPS Oder PC(USB) geschalten wird, kann ich 
mit der SPS oder eben mit dem Terminalprogramm kommunizieren, wobei auch 
hier die Interrupts nicht eingeschalten waren.

3. Ich habe den Tippfehler in der uart_getc gefunden und entschuldige 
mich dafür. Der Laptop mit dem Programm hat in der Halle kein WLan und 
ich habe die beiden Funktionen abgetippt.

Gruß
Susan

[Susan (Gast)]

Achja. Tippfehler verbessert

uint8_t uart_getc(void)
{
     while(!(UCSR0A & (1<<RXC0)))    //Warten bis Zeichen verfügbar
        ;
     return UDR0;       //Zeichen aus UDR zurückgeben
}

[Karl H. (kbuchegg)]

Susan schrieb:
> Danke für die vielen Antworten. Ich werde versuchen alle Fragen zu
> beantworten.
> Das gesamte Programm ist mehre kByte groß, deswegen dachte ich, ich
> beschränke mich auf den wichtigen Teil.

Und du merkst erst jetzt, dass deine Basis, auf der alles andere 
basiert, nicht funktioniert?

Sauber.

Dann speck ab! Testprogramm, welches nur mit der SPS kommunizert und 
sonst nichts.
Wenn irgend geht, bau dir einen Splitter ein oder sonst eine 
Ausgabemöglichkeit, so dass du sowohl mit der SPS als auch mit dem PC 
kommunizieren kannst. Anstatt PC geht auch ein LCD oder sonst irgendwas, 
Hauptsache du kannst dir ansehen, was du von der SPS kriegst.
Jedes Zeichen, welches von der SPS kommt, wird sofort auf deiner 
Ausgabefläche ausgegeben!
Wenn du nicht nachvollziehen kannst, was in deinem Programm los ist, 
dann musst du dir eben Möglichekeiten dafür schaffen. Und bei einer UART 
bedeutet das dann eben: du musst direkt und unmittelbar und unverfälscht 
mitlesen können, was dein µC von der UART kriegt.

[Uwe (Gast)]

Die beiden Aussagen widersprechen sich :
>Teste ich das Programm statt mit der SPS mit dem PC, also sende den
>String über ein Terminalprogramm funktioniert es.
und
> Selbst kann ich das nicht überprüfen, da kein Laptop mit einer
> RS232-Schnittstelle vorhanden ist.
Versuch erst mal die richtige Baudrate herauszufinden mit der die SPS 
arbeitet. Diese stellst du dann am µC und auch am PC ein.
Danach überprüfst du mal ob für die SPS 8N1 wirklich stimmt.

[Susan (Gast)]

Karl Heinz Buchegger schrieb:
> Und du merkst erst jetzt, dass deine Basis, auf der alles andere
> basiert, nicht funktioniert?

Der wichtige Teil für das Problem. Der Datenlogger drumherum 
funktioniert, das PC-Programm zur Auswertung auch nur kann ich bisher 
den Daten noch keinen genauen Typ zuordnen.

Uwe schrieb:
> Die beiden Aussagen widersprechen sich :
>>Teste ich das Programm statt mit der SPS mit dem PC, also sende den
>>String über ein Terminalprogramm funktioniert es.
> und
>> Selbst kann ich das nicht überprüfen, da kein Laptop mit einer
>> RS232-Schnittstelle vorhanden ist.

Meine Platine hat deswegen einen USB-Anschluss, die SPS nur eine RS232.

...Und wenn ich die beiden miteinander verbinde, funktionieren ja beide 
über UART, bekomme ich die SPS-daten auf den PC. Manchmal sieht man des 
Wald vor lauter Bäumen nicht :).
Dann werde ich das jetzt erstmal tun.

Vielen Dank an alle.