Probleme mit UART-Empfang

[Christian S. (aldebaran22322)]

Hallo Liebe Gemeinde,

Ich benötige mal eure Hilfe in Sachen Kommunikation zwischen AVR's.
Zur Hardware:

Der Sender ist ein ATmega162PU. Dieser sendet über ein Bluetooth-Modul 
(BTM222)  folgende Informationen:

A,0
B,0
C,0
D,0
E,48
F,56
G,0
H,0
I,0
J,0
K,0
L,0
M,0
N,0
O,0
P,0
Q,0
R,0
S,0
T,0
U,0
V,0
W,0
X,0
Y,0

Das funktioniert auch ganz Gut. Die Zahlen hinter den Buchstaben sind 
Werte eines DMX-Pultes.

Auf Empfängerseite ist ebenfalls ein BTM222 mit einem ATMega644.
Das Bluetooth-Modul empfängt auch alles wunderbar. Nur dem AVR konnte 
ich das zuhören noch nicht richtig beibringen.

Um Die Einstellung Baudrate mache ich mir keine Sorgen. Aber der 
Vollständigkeit halber: Der AVR läuft mit einem Externen 16MHz Quarz. 
Die Baudrate beträgt 19200 und der Code um die ganze geschichte zu 
Initialisieren sieht so aus:

UBRR1H   = (unsigned char)(F_CPU / (BAUD * 16L) - 1)>>8;
UBRR1L   = (unsigned char)(F_CPU / (BAUD * 16L) - 1);

UCSR1A = (1<<RXC1);
UCSR1B = (1<<RXEN1)|(1<<TXEN1)|(1<<RXCIE1);  
UCSR1C = (1<<UCSZ11)|(1<<UCSZ10); 
sei();

Die Einzige Debugging-möglichkeit die ich habe ist über dem UART0 die 
Daten Auszugeben und mir am PC im Terminal anzusehen.

Hier ist mein Code um den Empfang zu realisieren:


Auszug aus der UART.h:

char uart_getchar()
{
  // Ist schon ein Zeichen im Buffer?
  while (!(UCSR1A & (1<< RXC1)));
  return UDR1;
}

void uart_readline(char* str)
{
  char c;
  unsigned char index;
  
  index = 0;

   while (c != 13)
   {
    c = uart_getchar();
    if (c != -1)
    {
      if (c == 13)      /*ASCII: NewLine */
      {
        str[index] = '\0';  /* Ende der Zeile erreicht,also String abschließen */
        /* Funktion beenden */
        return;
      }
      else/*Ansonsten normales Zeichen, anhängen an die Zeichenkette */
      {
        str[index] = c;
        index++;
      }
    }
  }
}
[c]



Und die Main.c

[c]
ISR(USART1_RX_vect)
{
  
  char eingabe[255];
  char chan[1];
  char val;
  uart_readline(eingabe);
  uart_puts0("\r\n");
  uart_puts0("Eingabe ist: ");
  uart_puts0(eingabe);
  char *ptr;
  ptr = strtok(eingabe, ",");
  strcpy(chan, ptr);
  uart_puts0("\nChan:");
  uart_puts0(chan);
  ptr = strtok(NULL, ",");
  val = atoi(ptr);
  uart_puts0("\nVal:");
  uart_putc0(val);
  uart_puts0("\n");
}



int main(void)
{
   uart_init();
  DDRB=0b00000001; // Feedback LED 
  PORTB |= (1<<0); // Feedback LED AN
  _delay_ms(1000);
  PORTB &= ~(1<<0); // Feedback LED AUS
 
  while(1)
    {
    
    PORTB |= (1<<0);
    _delay_ms(50);
    PORTB &= ~(1<<0);
    _delay_ms(100);
    }
  
  
}

Hier ist ein Ausschnitt von dem, was mir mein kleiner Krabbler so 
ausspuckt:

Eingabe ist: A,0
Chan:A
Val:[00]

Eingabe ist: B,–¸?,4hxÄÇ€·ŽZ>rd~ÿ
Chan:B
Val:[00]

Eingabe ist: E,50
Chan:E
Val:2

Eingabe ist: F,,104
Chan:F
Val:h

Eingabe ist: M,8
Chan:M
Val:[08]

Eingabe ist: Q,100
Chan:Q
Val:d

Eingabe ist: W,
Chan:W
Val:[00]

Manchmal funktioniert alles wie geplant, manchmal setzt er ein Komma da 
wo keins sein soll. Manchmal Datensalat. Hin und wieder versagt strtok. 
Alles in allem zu ineffizient. Ich tippe mal Stark darauf, dass die Art, 
wie ich den Interrupt abarbeite zu lange dauert und der AVR deswegen 
info's verliert.
Mir ist auch klar, dass ich durch diese ganzen uart_puts0("whatever"); 
die ISR unfassbar verlängere.

Leider habe ich wie gesagt keine andere Möglichkeit in den AVR zu 
gucken. Des weiteren bin ich auch am Ende meiner Programmiererischen 
Fähigkeiten und hoffe, dass ihr mir den Entscheidenden Tipp gebt.

Bin für jeden konstruktiven Rat dankbar.

[Marc V. (Firma: Vescomp) (logarithmus)]

Christian S. schrieb:
> Bin für jeden konstruktiven Rat dankbar.

 Lass deiner ISR Routine ein bisschen Luft, mach die USART Ausgabe
 in main.

 In der ISR Stringende abwarten, Flag setzen, Rest in main()

[Karl M. (Gast)]

Da sieht man mal wieder, wie mal sich selbst in's Abseits stellt.

Programmiere einen RX- und TX- Fifo für jeweils einen Uart, dann kann 
man ganz bequem in der Main-Loop den Datenstrom per DEA analysieren und 
entsprechend deiner Vorgaben reagieren.

[Wolfgang (Gast)]

Christian S. schrieb:
> Die Einzige Debugging-möglichkeit die ich habe ist über dem UART0 die
> Daten Auszugeben und mir am PC im Terminal anzusehen.

Dann solltest du vielleicht mal 8€ in einen kleinen Logikanalysator 
investieren, damit du dir solche Dinge zeitlich genau ansehen kannst, 
z.B. indem du einen IO-Pin setzt, solange der µC in der ISR am werkeln 
ist und sehen kannst, wie das in Bezug zur Datenübertragung steht.

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Die ISR wird normalerweise für jedes empfangene Zeichen ausgelöst, du 
hast also, wenn du ganze Strings in der ISR abfragst (abgesehen von dem 
zeitraubenden extra Krams) auf jeden Fall nach dem ersten empfangenen 
Zeichen beim zweiten Zeichen einen 'pending' Interrupt, der dazu führt, 
das die ISR beim Verlassen auf jeden Fall sofort wieder getriggert wird, 
egal, ob da noch ein Zeichen ist oder nicht.

Die ISR sollte also, wie oben schon angedeutet, nur ein Zeichen 
empfangen und kann meinetwegen Flags oder was auch immer setzen, um CR 
oder Komma zu signalisieren. Bei DMX bietet es sich an, die Daten ohne 
Rücksicht in einen Buffer zu schreiben und während des langen Mark/Space 
zu bearbeiten.

[Christian S. (aldebaran22322)]

Danke für eure Antworten

Wolfgang schrieb:
> Christian S. schrieb:
>> Die Einzige Debugging-möglichkeit die ich habe ist über dem UART0 die
>> Daten Auszugeben und mir am PC im Terminal anzusehen.
>
> Dann solltest du vielleicht mal 8€ in einen kleinen Logikanalysator
> investieren, damit du dir solche Dinge zeitlich genau ansehen kannst,
> z.B. indem du einen IO-Pin setzt, solange der µC in der ISR am werkeln
> ist und sehen kannst, wie das in Bezug zur Datenübertragung steht.

Logic-Analyser ist vorhanden, allerdings habe ich in diesem Zusammenhang 
keine Verwendung gesehen. Dass die Abarbeitung der ISR zu lange dauert 
habe ich auch ohne Analyzer herausgefunden indem ich einfach meine 
Blinkende LED aus der main beobachtet habe. Ist zwischendurch immer 
wieder stehen geblieben. Aber der Tipp ist gut. Ohne meine Feedback-LED 
oder einem Analyzer hätte ich mich wohl tot gesucht.



Die Idee mit dem FIFO bin ich mal angegangen, allerdings mit mäßigem 
Erfolg. Ich habe mehrere fertig gestrickte versionen eines Ringpuffers 
ausprobiert und bin dann letztendlich bei diesem hier stehen geblieben:
https://www.mikrocontroller.net/articles/FIFO#Code-Beispiel

Und hier lässt mich wieder mein Hirn im Stich. Diese Pointerarithmetik 
ist mir noch'ne nummer zu hoch. Ich habe den FIFO-Buffer aus dem 
Tutorial ohne änderungen in mein Projekt intigriert und meinen Code wie 
folgt angepast:


main.c

ISR (USART1_RX_vect)
{
  BufferIn(uart_getchar());
}

int main(void)
{
   uart_init();
      while(1)
    {

     uint8_t eingabe;
    BufferOut(&eingabe);
    
                uart_puts0("\r\n");
    uart_puts0("Eingabe ist: ");
    uart_putc0(eingabe);

    PORTB |= (1<<0);
    _delay_ms(50);
    PORTB &= ~(1<<0);
    _delay_ms(100);
    }
  
  
}

UART.h

char uart_getchar()
{
  while (!(UCSR1A & (1<< RXC1)));
  return UDR1;
}

void uart_readline(char* str)
{
  char c;
  unsigned char index;
  
  index = 0;

   while (c != 13)
   {
    c = BufferOut(&str);
    if (c != -1)
    {
      if (c == 13)
      {
        str[index] = '\0';
        return;
      }
      else
      {
        str[index] = c;
        index++;
      }
    }
  }
}

Auf dem ersten blick in meinen Terminal habe ich mich gefreut. Nach dem 
Controller-Start sieht es so aus:

Eingabe ist: A
Eingabe ist: ,
Eingabe ist: 0
Eingabe ist: 

Eingabe ist: B
Eingabe ist: ,
Eingabe ist: 0
Eingabe ist: 

Eingabe ist: C
Eingabe ist: ,
Eingabe ist: 0
Eingabe ist: 

Eingabe ist: D
Eingabe ist: ,
Eingabe ist: 0

Danach kommt allerdings nurnoch Block A und B in Dauerschleife. Selbes 
spiel, wenn ich den Puffer erhöhe. Dann schafft die erste runde es 
lediglich ein paar Buchstaben weiter im Alphabet.

ICh muss aber dazu sagen, dass mein Compiler einige Warnugen und 
Hinweise ausspuckt:

expected 'uint8_t *' but argument is of type 'char **'

dabei bezieht er sich auf die stelle stelle im FIFO-Code

uint8_t BufferOut(uint8_t *pByte)

und

Warning  1  passing argument 1 of 'BufferOut' from incompatible pointer type [enabled by default]

für diese stelle:

c = BufferOut(&str);

Aus meiner UART.h

[indEAS (Gast)]

So wie ich das sehe, solltest Du einen Start (und einen Stop Identifier) 
spendieren:

// Datenstring leeren bzw. initialisieren:
for (buffid_rx=0; buffid_rx < RX_BUFFER_LENGTH; buffid_rx++) rx_buffer[buffid_rx]=0; // Empfangsdatenpuffer leeren
buffid_rx=0; // Zeiger auf den Anfang
rx_complete = false;
while (rx_complete == false)
 {
 while (!kbhit())   // auf neues Zeichen warten
  {
  restart_wdt();
  delay_us(20);
  // hier könnte man ncoh eine Timeout oder blinke LED spendieren...
  }
 character = getc();      // Character in den Puffer
 if (character == 0x2A) buffid_rx = 0;   // Bei Empfang von * Pointer zurücksetzen
 else  buffid_rx++; // Zeiger inkrementieren
 if (buffid_rx >= RX_BUFFER_LENGTH) buffid_rx = RX_BUFFER_LENGTH;  // Überlauf abfangen
 rx_buffer[buffid_rx]=character;
 if (character == 0x0D) rx_complete=true;   // Bei Empfang von CR aus der 
 }

Danach kannst Du den Krempel interpretieren
z.B.

LED_data_hb = ASCI_TO_HEX(rx_buffer[2],rx_buffer[3]);  // LEDs Byte 1
LED_data_lb = ASCI_TO_HEX(rx_buffer[4],rx_buffer[5]);  // LEDs Byte 0

[W.S. (Gast)]

Christian S. schrieb:
> Das funktioniert auch ganz Gut.

Christian S. schrieb:
> while (!(UCSR1A & (1<< RXC1)));

Nein, das funktioniert eben nicht ganz gut, sondern ganz schlecht.
Du machst den immer wiederholten Anfängerfehler, mit dem Kopf durch die 
Wand programmieren zu wollen ohne auch nur einmal links oder rechts zu 
schauen.

Also:
1. schreib dir einen ordentlichen UART-Treiber! Das ist so einer, der 
beide Zeichenströme puffert (in und out), der die Zeichen-Ein- und 
Ausgabe per Interrupt erledigt und eine hardwareunabhängige 
Schnittstelle zu den höheren Programmschichten bietet. Ich hab hier 
schon so oft was Entsprechendes gepostet.

2. mache kein derartiges Gedöns wie in deiner geposteten 
Interruptroutine! In eine ISR kommt sowas nicht rein, merk dir das. 
Grund: du blockierst damit nämlich auf sinnlosesete Weise den ganzen µC, 
weil er in der ISR auf irgend ein langsames Flag warten muß, ohne 
derweil was Sinnvolles tun zu können. Selbst ein anderer Interrupt geht 
bei sowas regelmäßig flöten.

3. zur Auswertung:
Lade dir am besten die Lernbetty herunter, die ist zwar für einen 
ARM7TDMI, aber bis auf die Innereien des UART-Treibers ist z.B. die 
gesamte Kommandoauswertung hardwareunabhängig. Das könnte dann so 
aussehen:

if (match("A,",&Cpt))  { Awert = Long_In(&Cpt); return;}
if (match("B,",&Cpt))  { Bwert = Long_In(&Cpt); return;}
usw.

Also denke zuerst nach und hau erst dann in die Tasten.

W.S.