Atmega48 - UART als Interrupt

[Julian W. (julian-w)]

Hallo,
ich verzweifle gerade... ich kriege einfach nicht die UART beim Atmega48 
zum laufen... :( Hier mal mein Code:

int main(void)
{
    InitIO();
    InitUART();
    sei();

    while(1){};

    [...]
}

[...]

void InitUART()
{
    LightOn(LED_READY);

    #ifndef  UART_BAUD
    #define  UART_BAUD    9600UL
    #endif

    #ifndef  F_CPU
    #define  F_CPU    16000000UL
    #endif

    #define  UART_UBRR    ( ( ( F_CPU / 16 ) / UART_BAUD ) - 1 )

    UBRR0H = ( unsigned char )( UART_UBRR >> 8 );
    UBRR0L = ( unsigned char )UART_UBRR;

    UCSR0B = ( _BV( RXCIE0 ) | _BV( RXEN0 ) | _BV( TXEN0 ) );
    UCSR0C = ( _BV( USBS0 ) | _BV( UCSZ01 ) | _BV( UCSZ00 ) ); // 8N2

    LightOn(LED_ERROR);
}

ISR(USART_RX0_vect )
{
    uint8_t tmp = UDR0;
    LightOn(LED_RESET);
}

Die Funktion LightOn() schaltet einfach nur simple LEDs an und aus, die 
funktioniert auch tadelos. Nur sobald jetzt ein Zeichen empfangen wird 
passiert nichts und der Atmega48 stürzt einfach ab!? (Hatte noch eine 
TLC5940 ansteuerung im Hintergrund die Interrupt-Basiert ist und die 
funktionierte nach dem Senden eines Zeichens nicht mehr)

Könnt irh einen Fehler finden? Ich weiß einfach nicht mehr weiter bei 
sowas simplen...

Viele Grüße
Julian

[Thomas E. (thomase)]

Julian W. schrieb:
> ISR(USART_RX0_vect )
Der Vektor heisst USART_RX_vect. Compilerwarnungen beachten!

mfg.

[Karl H. (kbuchegg)]

Julian W. schrieb:

> funktioniert auch tadelos. Nur sobald jetzt ein Zeichen empfangen wird
> passiert nichts und der Atmega48 stürzt einfach ab!?

Wenn Interrupts im Spiel sind und der µC bei Auftreten eines INterrupts 
abschmiert, dann stimmt meistens der Name der ISR nicht.
D.h. da wurde an den Interrupt KEINE ISR gebunden. Und sobald dieser 
Fall eintritt, tritt der Default-Handler auf die Bühne, welcher .... den 
µC resettet.

Also: Überprüf den Namen deiner ISR

[Julian W. (julian-w)]

Okay, hab ich mal geändert... aber darüber hat der Compiler eigetnlich 
nie gemekert.
Einzigst was noch immer kommt:

main.c|67|warning: control reaches end of non-void function|

[Karl H. (kbuchegg)]

Julian W. schrieb:
> Okay, hab ich mal geändert... aber darüber hat der Compiler eigetnlich
> nie gemekert.
> Einzigst was noch immer kommt:
>
> main.c|67|warning: control reaches end of non-void function|

Schön.
UNd welches ist die Zeile 67?

[Julian W. (julian-w)]

Das hier:

ISR(USART_RX_vect)
{
    uint8_t tmp = UDR0;
    LightOn(LED_RESET);
}

[Cyblord -. (cyblord)]

Karl Heinz Buchegger schrieb:
> Julian W. schrieb:
>> Okay, hab ich mal geändert... aber darüber hat der Compiler eigetnlich
>> nie gemekert.
>> Einzigst was noch immer kommt:
>>
>> main.c|67|warning: control reaches end of non-void function|
>
> Schön.
> UNd welches ist die Zeile 67?

Das Ende der main wahrscheinlich. Die sollte int zurückgeben. Macht er 
aber nicht. Macht wohl nur return; oder gar nix.
Ist aber auch für das Problem hier nicht relevant.

gruß cyblord

[Thomas E. (thomase)]

../usart0.c:119:1: warning: 'USART_RX0_vect' appears to be a misspelled 
signal handler

Julian W. schrieb:
> aber darüber hat der Compiler eigetnlich nie gemekert.
Wie dem auch sei.

Karl Heinz Buchegger schrieb:
> Schön. UNd welches ist die Zeile 67?
Mach doch mal die Augen auf:

Julian W. schrieb:
> [...]

Julian W. schrieb:
> control reaches end of non-void function
Da wurde der "Point of no return" erreicht.

cyblord ---- schrieb:
> Ist aber auch für das Problem hier nicht relevant.
Ist dem GCC aber auch egal.

mfg.

[Karl H. (kbuchegg)]

Julian W. schrieb:
> Das hier:
>
>

> ISR(USART_RX_vect)
> {
>     uint8_t tmp = UDR0;
>     LightOn(LED_RESET);
> }
>

Womit wir wieder beim Punkt angelangt sind, dass der Name der ISR immer 
noch nicht stimmt.

Da ist deine Warnung, dass der Name nicht stimmt, denn eine ISR ist 
definitiv eine void Funktion.
Wenn der Compiler das nicht erkannt hat und auswirft
Control reaches end of non-void function
dann bedeutet das, dass er das als int Funktion ansieht. Woraus man 
schliessen kann, dass er das nicht als ISR anerkennt

[Karl H. (kbuchegg)]

cyblord ---- schrieb:
> Karl Heinz Buchegger schrieb:
>> Julian W. schrieb:
>>> Okay, hab ich mal geändert... aber darüber hat der Compiler eigetnlich
>>> nie gemekert.
>>> Einzigst was noch immer kommt:
>>>
>>> main.c|67|warning: control reaches end of non-void function|
>>
>> Schön.
>> UNd welches ist die Zeile 67?
>
> Das Ende der main wahrscheinlich. Die sollte int zurückgeben. Macht er
> aber nicht.

Muss er auch nicht.

Für main() gibt es eine Ausnahme :-)
main ist zwar eine int Funktion, aber wenn der Code selbst kein return 
enthält, muss sich der COmpiler ein
   return EXIT_SUCCESS;
dazudenken.

Frag mich nicht ....

[Julian W. (julian-w)]

ich weiß einfach nicht mehr weiter... hier der komplette Code fals es 
weiter hilft.

Hab das UART Signal mir mal mit dem Oszi angeschaut, das passt aber :(

[Thomas E. (thomase)]

Karl Heinz Buchegger schrieb:
>> ISR(USART_RX_vect)
Doch. Die stimmt jetzt.
Aber "LightOn(LED_RESET);" befindet sich noch immer zwischen den ersten 
beiden Punkten: [...]

mfg.

[Julian W. (julian-w)]

Thomas Eckmann schrieb:
> Aber "LightOn(LED_RESET);" befindet sich noch immer zwischen den ersten
> beiden Punkten: [...]

LightOn ist in der io.c und sieht wie folgt aus:

void LightOn(uint8_t led)
{
    PORTD &= ~(1<<led);
}

[Julian W. (julian-w)]

Waaahhhh... ich hab es....

es fehlte einfach nur

#include <avr/interrupt.h>

in der uart.h -.- Naja da war ich wohl sehr Betriebsbilnd. Doof das der 
Compiler nicht meckert.

Danke für die vielen und schnellen Antworten ;)

[Karl H. (kbuchegg)]

Thomas Eckmann schrieb:
> Karl Heinz Buchegger schrieb:
>>> ISR(USART_RX_vect)
> Doch. Die stimmt jetzt.
> Aber "LightOn(LED_RESET);" befindet sich noch immer zwischen den ersten
> beiden Punkten: [...]

Ich versteh nicht.

Die Fehlermeldung ist nicht typisch dafür.

[Karl H. (kbuchegg)]

Julian W. schrieb:
> Waaahhhh... ich hab es....
>
> es fehlte einfach nur
>

> #include <avr/interrupt.h>
>

>
> in der uart.h -.- Naja da war ich wohl sehr Betriebsbilnd. Doof das der
> Compiler nicht meckert.

Hat er doch :-)

Für den Compiler war das hier

ISR( UART_RXC_vect )
{
}

eine ganz normale C-Funktion.

OK. Der Compiler musste seinen Freiraum komplett ausnutzen, um daraus 
etwas Sinnvolles zu machen - in dem er alle unbekannten Datentypen als 
int annahm, aber ... das darf er.
Für ihn stand da

int ISR( int UART_RXC_vect )
{
  ...
}

und: diese Funktion hat keinen return, obwohl sie eine int-Funktion ist. 
UNd das hat er dir freundlicherweise mitgeteilt.

Erst durch den #include wurde dann aus "ISR" etwas ganz anders.

[Thomas E. (thomase)]

Karl Heinz Buchegger schrieb:
> Die Fehlermeldung ist nicht typisch dafür.
Doch wäre sie, wenn die Funktion nicht void wäre. Daß sie das ist, habe 
ich erst nachher gesehen.

Julian W. schrieb:
> es fehlte einfach nur#include <avr/interrupt.h>
Aber das erklärt den Fehler.

mfg.

[Karl H. (kbuchegg)]

Thomas Eckmann schrieb:
> Karl Heinz Buchegger schrieb:
>> Die Fehlermeldung ist nicht typisch dafür.
> Doch wäre sie, wenn die Funktion nicht void wäre. Daß sie das ist, habe
> ich erst nachher gesehen.

Ich hab dich immer noch nicht.
Die Fehlermeldung

control reaches end of non-void function|

an dieser Stelle

ISR(USART_RX_vect)
{
     uint8_t tmp = UDR0;
     LightOn(LED_RESET);
}     // <--------------

hat nichts mit der Funktion LightOn zu tun.

Aber egal.

[Thomas E. (thomase)]

Karl Heinz Buchegger schrieb:
> hat nichts mit der Funktion LightOn zu tun.
Der Fehler kam ja auch daher, daß der Compiler nicht wusste, was eine 
ISR ist. Deswegen gab es auch keine Warnung wegen dem misspelled 
handler.

Da ich aber weiß, was das ist, bin ich davon ausgegangen, daß dem 
Compiler das auch mitgeteilt wurde. Somit blieb aus der ISR heraus als 
nächste Funktion, die nichts zurück gibt die LightOn(...

Das ist eben das Resultat, wenn man aus Codefetzen, bei denen alles 
weggelassen wurde, woran es garantiert nicht liegt, versucht, sich etwas 
zusammen zu reimen.

mfg.