Atmega324 UART: Senden vom PC zum µC klappt nicht

[Troll A. (trollator)]

Guten Morgen zusammen!

Mein Aufbau sieht wie folgt aus:
Ich habe einen Atmega324 an dem ein Max232 hängt. Verbunden sind Rx, Tx 
(beide gekreuzt) und GND.
Der Atmega hat einen externen Quarz mit 10Mhz und die UART Einstellungen 
habe ich aus dem Tutorial und Datenblatt übernommen (Baud 9600 8N2).
Aktiviert ist ferner, dass beim Empfang von Zeichen ein Interrupt 
ausgelöst wird.

Am PC verwende ich HTerm.

Wenn ich Zeichen vom µC zum PC sende, klappt das einwandfrei. Das Senden 
vom PC zum µC hingegen klappt nicht - es wird kein Interrupt ausgelöst.

Ich habe dann einmal eine Brücke zwischen Tx und Rx vom Max232 gesetzt. 
Dann habe ich im HTerm die gesendeten Zeichen gesehen.
Als nächstes habe ich Tx und Rx vom µC gebrückt und daraufhin wurde der 
Interrupt ausgelöst.

Prinzipiell scheint das Empfangen vom µC also zu funktionieren.
Aber wenn ich über HTerm sende, kommt einfach nichts im µC an. Die Kabel 
habe ich natürlich auch schon mal gewechselt.

Gibts vielleicht irgendwelche Ideen, woran das liegen könnte?

[Rahul D. (rahul)]

Der Fehler ist in Zeile 42 deines geheimen Quellcodes.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Troll A. schrieb:
> Gibts vielleicht irgendwelche Ideen, woran das liegen könnte?
Weil du das ja alles sicher schon mit dem Oszilloskop kontrolliert und 
dort auch die beiden Timings (Baudrate) verglichen hast (das sollte man 
bei seriellen Schnittstellen generell), liegt es mit höchster mit 
höchster Wahrscheinlichkeit am Programm.

> es wird kein Interrupt ausgelöst.
Wie sieht es mit Polling aus, wenn schon der Interrupt nicht kommt?

[Troll A. (trollator)]

Rahul D. schrieb:
> Der Fehler ist in Zeile 42 deines geheimen Quellcodes.

Ich habe alles in mehreren Dateien gesplittet, aber hier mal die 
wichtigsten Funktionen:

Init

#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD)

#if ((BAUD_ERROR<990) || (BAUD_ERROR>1010))
#error BAUD not valid
#endif

void uart_init()
{
  UBRR0H = UBRR_VAL >> 8;;
  UBRR0L = UBRR_VAL & 0xFF;
  
  UCSR0B = (1<<RXCIE0)|(1<<RXEN0)|(1<<TXEN0);
  
  //8data 2stop bit
  UCSR0C = (1<<USBS0)|(3<<UCSZ00);
}

Interrupt

volatile uint8_t uart_string_complete = 0;
volatile uint8_t uart_string_count = 0;
volatile char uart_string[UART_MAX_STRING_LENGTH + 1] = "";

ISR(USART0_RX_vect)
{
  unsigned char nextChar;

  nextChar = UDR0;
    
  //Append new char only if string is not complete, else the main loop has to process the string first
  if(uart_string_complete == 0) 
  {
    uint8_t finishString = 0;
    
    if(nextChar == '\n' || nextChar == '\r' || uart_string_count == UART_MAX_STRING_LENGTH) 
    {
      finishString = 1;
    }
    else
    {
      uart_string[uart_string_count] = nextChar;
      uart_string_count++;      
      
      if(nextChar == ';')
        finishString = 1;
    }
      
    if(finishString == 1)
    {
      uart_string[uart_string_count] = '\0';
      uart_string_count = 0;
      uart_string_complete = 1;
    }
  }
}

Selbst wenn ich bei jedem Interrupt uart_string_complete auf 1 setzte, 
erhalte ich nichts.

Lothar M. schrieb:
> Weil du das ja alles sicher schon mit dem Oszilloskop kontrolliert

Habe ich leider nicht zur Verfügung...

Lothar M. schrieb:
> Wie sieht es mit Polling aus, wenn schon der Interrupt nicht kommt?

Schlecht. Mit

if ( UCSR0A & (1<<RXC0) )
    {
      // Zeichen wurde empfangen, jetzt abholen
      uint8_t c;
      
      while (!(UCSR0A & (1<<RXC0)));
      c = UDR0;
      
          lcd_gotoxy(0,1);
          lcd_putc(c);
    }

in der Main Loop bekomme ich leider auch keine Ausgabe.

Ich verstehe es irgendwie nicht, da ja das Senden vom µC zum PC 
einwandfrei klappt...

[Εrnst B. (ernst)]

Global hast du die Interrupts schon enabled?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Troll A. schrieb:
> Ich habe einen Atmega324 an dem ein Max232 hängt.
Dann musst du dessen Funktion wenigstens mal statisch kontrolliert? 
9V-Batterie am RS232-RX-Eingang mal so und mal andersrum gepolt und dann 
am RX-Ausgang des MAX gemessen, welche Pegel rauskommen?

> Ich habe dann einmal eine Brücke zwischen Tx und Rx vom Max232 gesetzt.
Auf welcher Seite? Auf der RS232 Seite oder der TTL-Seite?

> Als nächstes habe ich Tx und Rx vom µC gebrückt und daraufhin wurde der
> Interrupt ausgelöst.
Von wo aus wurde da gesendet? Der MAX war dabei noch angeschlossen?

Troll A. schrieb:
> Lothar M. schrieb:
>> Weil du das ja alles sicher schon mit dem Oszilloskop kontrolliert
> Habe ich leider nicht zur Verfügung...
Würde ich ändern. Serielle Schnittstellen bekommt man nur mit einem 
"Deserializer" wie einem Oszi oder einem Logicanalyzer sicher in den 
Griff. Ein Oszi ist besser, weil man damit auch die Signalqualität 
(Pegel, Flanken) bewerten kann.

Denn das Debuggen von seriellen Schnittstellen ohne Oszi ist wie 
Autofahren nach Gehör: man merkt Probleme immer erst dann, wenn es 
schiefgegangen ist.

[Martin H. (horo)]

Lothar M. schrieb:
> oder einem Logicanalyzer

Für kleines Geld gibt es die "Salae-Kompatiblen", als SW empfehle ich 
sigrok, das erlaubt intensives Analysieren serieller Kommunikation. 
Verfügbar auch für Windows.

https://sigrok.org

[Volker B. (Firma: L-E-A) (vobs)]

Troll A. schrieb:

> Das Senden
> vom PC zum µC hingegen klappt nicht - es wird kein Interrupt ausgelöst.

Du bist Dir sicher, dass der PC sendet? Brücke doch mal versuchsweise am 
PC TxD und RxD, dann sollte das Terminalprogramm ein Echo empfangen.

Auch schadet es nichts, die Handshakeleitungen am PC zu brücken. RTS mit 
CTS verbinden sowie DCD mit DSR und DTR verbinden.

Grüßle,
Volker

[Oliver S. (oliverso)]

Troll A. schrieb:
> UBRR0H = UBRR_VAL >> 8;;
> UBRR0L = UBRR_VAL & 0xFF;

Hat zwar nichts mit deinem eigentlichen Problem zu tun, daher nur so als 
Hinweis: die Verwaltung der 8-Bit-Register bei einem 16-Bit-Register 
macht der Compiler für dich.

UBRR0 = UBRR_VAL;

Oliver

[Harald K. (kirnbichler)]

Volker B. schrieb:
> Du bist Dir sicher, dass der PC sendet? Brücke doch mal versuchsweise am
> PC TxD und RxD, dann sollte das Terminalprogramm ein Echo empfangen.

Hat er wohl gemacht:

Troll A. schrieb:
> Ich habe dann einmal eine Brücke zwischen Tx und Rx vom Max232 gesetzt.
> Dann habe ich im HTerm die gesendeten Zeichen gesehen.

[Volker B. (Firma: L-E-A) (vobs)]

Harald K. schrieb:
> Volker B. schrieb:
>> Du bist Dir sicher, dass der PC sendet? Brücke doch mal versuchsweise am
>> PC TxD und RxD, dann sollte das Terminalprogramm ein Echo empfangen.
>
> Hat er wohl gemacht:
>
> Troll A. schrieb:
>> Ich habe dann einmal eine Brücke zwischen Tx und Rx vom Max232 gesetzt.
>> Dann habe ich im HTerm die gesendeten Zeichen gesehen.

Sorry, das hab' ich überlesen. Dann hilft wohl nur noch ein Oszilloskop.

Nachtrag: Die Berechnung der Baudrate ist korrekt? Nicht dass der 
Compiler dafür 16-Bit-Zahlen verwendet.

Grüßle,
Volker

[S. L. (sldt)]

>  Ich habe dann einmal eine Brücke zwischen Tx und Rx
> vom Max232 gesetzt. Dann habe ich im HTerm die gesendeten
> Zeichen gesehen. Als nächstes habe ich Tx und Rx vom µC
> gebrückt und daraufhin wurde der Interrupt ausgelöst.

Also für mich folgt daraus, dass die Verbindung vom MAX232 zum 
ATmega324.PD0 nicht in Ordnung ist.

[Volker B. (Firma: L-E-A) (vobs)]

S. L. schrieb:

> Also für mich folgt daraus, dass die Verbindung vom MAX232 zum
> ATmega324.PD0 nicht in Ordnung ist.

Das ließe sich ja auch einfach prüfen: An der MCU RxD und TxD brücken 
und die MCU im Reset halten. Dann sollte der PC sein Echo empfangen.

Grüßle,
Volker

[Hannes (taurus16)]

Bau mal ein

sei();

als letzte Zeile in deine Uart-Init.

[Mario P. (mario_71950c)]

Wie sind die Schnittstelleneinstellungen von HTerm?
Arbeitet HTerm mit 2 Stoppbits (Baud 9600 8N2)?