USART atmega32 mit Interrupt

[walterk]

Hallo Forum,

möchte ein Byte von der seriellen Schnittstelle eines PC auf einen Atmega32 mit einem Interrupt übertragen.

Die Interruptroutine bleibt in der gekennzeichneten Stelle //verharrt hier stehen und die Variable Empfang wird nicht mehr auf 1 gesetzt.

Die Wertzuweisung a = UDR; arbeitet im Pollingbetrieb einwandfrei, auch Hardwareinterrupts funktionieren.

Umgebung: RN-Control 1.4, Ausgabe auf 8 LEDs, AVR-Studio 4.18. Suche im Forum und Tutorials waren leider nicht hilfreich.

Wo soll ich weitersuchen?

Danke für die Antworten.



#include <avr/io.h>
#define F_CPU 8000000UL
#include <util/delay.h>
#include <stdlib.h>
#include <avr/interrupt.h>

unsigned char a;
unsigned char empfang = 0;

ISR(USART_RXC_vect){

//PORTC = ~'D'; //verharrt hier während des delay

a = UDR;
empfang = 1;
}

int main(void){

sei();
//Schnittstelle parametrisieren
UBRRH = 0;
UBRRL = 51;
//Empfang, Senden, Empfangsinterrupt
UCSRB = (1<<RXEN) | (1<<TXEN) | (1<<RXCIE);
//Defaultwerte zementieren, 8N1
UCSRC |= (1<<URSEL) | (3<<UCSZ0);

DDRC = 0xff;


while(1){

PORTC = ~empfang; //wird nicht ausgeführt
_delay_ms(1000);

PORTC = ~'E'; //wird ausgeführt
_delay_ms(1000);

if(empfang){


PORTC = ~a;
empfang = 0;
}
}
}

[Ceos]

verwende doch bitte erstmal die [c o d e] - tags für den quellcode, macht das ganze übersichtlicher

dann zu folgenden zeilen ein paar fragen

PORTC = ~empfang; //wird nicht ausgeführt

wie kommst du auf die aussage ?

PORTC = ~'D'; //verharrt hier während des delay

WELCHES delay ?

also nur mal so vom programmablauf, du setzt PORTC auf 0 oder 'E', ein interrupt kommt, logischerweise springt die anzeige sofort auf 'D' ... dann kommst du in deine if-abfrage, zeigst das empfangene byte für ein paar µS an und löscht es dann sogleich wieder mit

PORTC = ~empfang;

nimm einfach mal alles was du mit PORTC machst raus und belasse es mal bei der if abfrage mit

PORTC = ~a;

[sternst]

Das ganze "wird ausgeführt ja/nein" ist mit Sicherheit nur Simulator/Debugger-Verwirrung, die daher rührt, dass bei eingeschalteter Optimierung keine eindeutige Zuordnung von C und ASM Code mehr möglich ist.

Dass der Code nicht macht was du willst, liegt an zwei vergessenen volatiles.

[walterk]

Danke an Ceos und sternst für die schnelle Hilfe!

Funktioniert nun.

Die beiden volatile habe ich nach einigem Probieren wieder rausgelöscht und viel zu kompliziert gedacht ==> Fehler

[Ceos]

hmmm beides sind doch unsigned char, da sollte volatile doch überflüssig sein ?! oder kann es im ungünstigen fall zur überschreibung des wertes aus dem stack kommen ?!

[sternst]

hmmm beides sind doch unsigned char, da sollte volatile doch überflüssig sein ?!

Was soll das eine mit dem anderen zu tun haben?

oder kann es im ungünstigen fall zur überschreibung des wertes aus dem stack kommen ?!

Hä? Was für ein Wert auf dem Stack?

[Besserwessi]

Ohne Optimierung geht es fast immer auch ohne volatile, aber mit optimierung sollte das volatile schon rein. Nach den Sprachdefintionen gehört das volatile auch hin, denn der Compiler weiß sonst nicht, das sich im Hauptprogramm was an "a" und "empfang" ändern kann. Ohne Optimierung wird GCC das noch nicht ausnutzen, mit Optimierung wahrscheinlich schon.

[Ceos]

@sternst zu 1. die variablen können in einem zug gelesen werden(8bit), deshalb sind sie generell unkritisch beim zugriff

zu 2. bin ich mir nicht ganz sicher ob während eines interrupt veränderte variablen nicht eventuell durch den stack des unterbrochenen programms überschrieben werden, wenn der interrupt beendet ist und die variiable nicht volatile deklariert ist

[sternst]

@sternst zu 1. die variablen können in einem zug gelesen werden(8bit), deshalb sind sie generell unkritisch beim zugriff

zu 2. bin ich mir nicht ganz sicher ob während eines interrupt veränderte variablen nicht eventuell durch den stack des unterbrochenen programms überschrieben werden, wenn der interrupt beendet ist und die variiable nicht volatile deklariert ist

Offenbar vermischt du hier ganz kräftig "volatile" und "atomarer Zugriff". Auch wenn beides gerne im Doppel auftritt, sind es doch verschiedene Sachen. Die Notwendigkeit für "volatile" hat prinzipiell nicht das Geringste mit dem Datentyp zu tun. Am besten schaust du nochmal genau nach, was das volatile überhaupt macht.

Aber auch in Bezug auf "atomarer Zugriff" stimmt die Aussage "zu 1" nicht. Read-Modify-Write-Zugriffe (z.B. x++) sind bei 8-Bit-Variablen ebenso kritisch (und entsprechend zu schützen), wie bei größeren Datentypen.

[Ceos]

volatile sagt dem compiler, dass die variable direkt aus/in dem spiecher geladen werden muss nach/vor jedem bearbeiten ich dachte dass das gerade mit dem atomaren zugriffen in zusammenhang steht aber solche ++ operationen sind ja nicht atomar, da hab ich etwas zu blauäugig gedacht ^^ recht haste

aber in dem obigen fall sind es doch atomare zugriffe! eine vergleichsoperation und eine zuweisung, also defakto kein volatile nötig oder ?