RX-Interruptroutine wird fälschlicherweise ständig durchgelaufen

[Uart-Client (Gast)]

Hallo Leute.

Im meinem Programmcode bin ich von der Pollinverfahren auf interrupt 
umgestiegen, um das ganze effizienter zu gestalten.

leider  klappt es nicht so ganz. Die Routine wird ständig durchgelaufen 
obwohl von dem anderen Gerät am ende der leitung nichts gesendet wird.

Normaleweise sollte es wie es sich selber beschreibt nur laufen wenn 
etwas auf der leitung zu empfangenvorhanden ist.

Aber es macht das anscheinen nicht . Ich habe mal zum Teszwecke ein Port 
zum toggeln hinzugefügt und es toggelt nämlich nach jedem Ende der 
Transmitframe(wird gesendet nach jedem Sekunde).

was könnte da faul sein?

void uart_Init (void)
{
  unsigned int x;
      
DDRD |=(1<<DDD4);  // Treiber_Enable für RS485 als Ausgang

    // Baudrate Einstellung
    UBRR0H = (unsigned char) (TEILER>>8);
    UBRR0L = (unsigned char) TEILER;

    //Sender , Empfänger  und Datenempfanginterrupt ein
  UCSR0B |= (1<<RXCIE0)| (1<<TXEN0)|(1<<RXEN0);

    // Datenformats: 8 Datenbits, 1 Stoppbit
    UCSR0C |= (1<<UCSZ01)|(1<<UCSZ00);//|(1<<USBS0);
  x=UDR0;     // Empfänger leeren
}


ISR(USART_RX_vect)
{
  unsigned int data;
  data=UDR0;// Daten speichern
         PORTB ^= (1 <<DDB3);

}

lg

[Sascha W. (sascha-w)]

wie sieht deine Schaltung aus - RS485 halbduplex ?
Dann empfängst du evl. das was du sendest!

Sascha

[Uart-Client (Gast)]

Sascha Weber schrieb:
> wie sieht deine Schaltung aus - RS485 halbduplex ?
>
ja es ist in Halbduplex-Betrieb.


> Dann empfängst du evl. das was du sendest!

nein ich habe es mit dem Oszi überprüft es sind sehr schmale impulse , 
die in sehr unregelmässißen zeitabständen kommen. Ich lese aus die 
Register und bekomme immer Null.

[(prx) A. K. (prx)]

Abschluss?

[Uart-Client (Gast)]

A. K. schrieb:
> Abschluss?

Abgeschlossen ist es ja mit 120 Ohm

[Sascha W. (sascha-w)]

hast du für einen eindeutigen Buszustand gesorgt?
A über R an +5V, B über R an Masse oder dafür sorgen das immer einer auf 
senden steht. Sonst fängt man sich schnell irgendwas ein.

Sascha

[Uart-Client (Gast)]

Sascha Weber schrieb:
> dafür sorgen das immer einer auf
>
> senden steht.

ja das habe ich intern in dem µC implementiert. von der Seite ist alles 
Glatt.

ich bin noch dabei zu suchen was ich in der ISR falsch gemacht  oder 
initialisiert habe. aber ich sehe keinerlei Knickpunkte.

[Sascha W. (sascha-w)]

hast du am Rx-Pin den Pullup eingeschaltet? Wenn am RS485 Treiber der 
Empfänger aus ist, ist der Ausgang meist hochohmig.

Hast du beim Umschalten der Datenrichtung eine kleine Überlappung 
vorgesehen in der beide Kommunikationspartner auf Senden stehen? 
Ansonsten den Empfänger im µC ausschalten, dann am RS485-Treiber auf 
Empfang schalten und nach kurzer Verzögerung den Empfänger wieder 
einschalten.

Sascha

[Uart-Client (Gast)]

Sascha Weber schrieb:
> hast du am Rx-Pin den Pullup eingeschaltet? Wenn am RS485 Treiber der
>
> Empfänger aus ist, ist der Ausgang meist hochohmig


wenn man es schon in der Uart-initialisierung als Empfänger setzt, dann 
sie die Port abgeschaltet.  und man braucht meiner Kenntnisse nach es 
nicht mehr zu steuern(Pull up oder Pull douwn).

Sascha Weber schrieb:
> Hast du beim Umschalten der Datenrichtung eine kleine Überlappung
>
> vorgesehen in der beide Kommunikationspartner auf Senden stehen?

Das system erlaubt es nicht. in der RS485-treiber kommt es zu einem 
Kurzschluss, wenn beide auf Senden stehen.

ich weiß  weiterhin nicht wo der fehler liegt.

lg

[Läubi .. (laeubi)]

Welcher Controller?

Das:

ISR(USART_RX_vect)
{
  unsigned int data;
  data=UDR0;// Daten speichern
         PORTB ^= (1 <<DDB3);

}

Wird der Compiler zu

ISR(USART_RX_vect)
{
   PORTB ^= (1 <<DDB3);
}

verwursten. Außerdem versteh ich nicht so genau was du jetzt meinst: 
Wird das Toggeln korrekt ausgeführt und eine (irgenwie ominöse Routine) 
ständig durchlaufen oder geht das toggeln auch nicht korrekt und ie 
Routine ist deine ISR?

[Michael U. (amiga)]

Hallo,

Uart-Client schrieb:
>> Dann empfängst du evl. das was du sendest!
>
> nein ich habe es mit dem Oszi überprüft es sind sehr schmale impulse ,
> die in sehr unregelmässißen zeitabständen kommen. Ich lese aus die
> Register und bekomme immer Null.

Da ist mir was unklar: Ruhezustand des UART-RX ist ja H-pegel. Startbit 
ist L. Wenn also ein Spike, dann müßte es ja ein kurzer L-Impuls sein, 
der als Startbit interpretiert wird und Du müßtest als Empfangsdaten 
0xFF lesen.

Wenn Du 0 liest müßte es ja auf L bleiben und als Break gemelder werden 
bzw. einen Frame-Error erzeugen, weil kein Stoppbit erkannt wurde?

Gruß aus Berlin
Michael

[Stefan E. (sternst)]

> Das:

ISR(USART_RX_vect)
> {
>   unsigned int data;
>   data=UDR0;// Daten speichern
>          PORTB ^= (1 <<DDB3);
> 
> }

> Wird der Compiler zu

ISR(USART_RX_vect)
> {
>    PORTB ^= (1 <<DDB3);
> }

> verwursten.

Nein, denn UDR0 ist volatile, deshalb wird daraus eher so was:

ISR(USART_RX_vect)
{
   UDR0;
   PORTB ^= (1 <<DDB3);
}

Das ist also nicht die Ursache des Problems. Wobei ich aber auch sagen 
muss, dass ich auch noch nicht wirklich verstanden habe, was denn nun 
konkret das Problem ist, denn die Aussagen dazu sind ja doch ein wenig 
"verwirrend".

[Thilo M. (Gast)]

Ist die Masse zwischen Sender und Empfänger sauber verbunden?
Oder sind Potentialunterschiede vorhanden?
Ich hatte das Problem bei einer langen RS232-Verbindung, 50Hz 
eingekoppelt und der RX-INT war auf Dauerfeuer. ;)

[Sascha W. (sascha-w)]

> Sascha Weber schrieb:
>> Hast du beim Umschalten der Datenrichtung eine kleine Überlappung
>>
>> vorgesehen in der beide Kommunikationspartner auf Senden stehen?
>
> Das system erlaubt es nicht. in der RS485-treiber kommt es zu einem
> Kurzschluss, wenn beide auf Senden stehen.
wenn keiner sendet, dann sind die Pegel gleich und es gibt auch keinen 
Kurzschluss, mach ich bei mir auch so.
Zusätzlich hab ich bei der Umschaltung auf Empfang bei mir eine kleine 
Warteschleife eingefügt die den Rx-Pin per polling prüft und wartet bis 
für einige 100µs stabil H-Pegel anliegt. Erst danach schalte ich den 
UART-Rx wieder ein.

Sascha

[Uart-Client (Gast)]

Läubi .. schrieb:
> Außerdem versteh ich nicht so genau was du jetzt meinst:
>
> Wird das Toggeln korrekt ausgeführt und eine (irgenwie ominöse Routine)
>
> ständig durchlaufen oder geht das toggeln auch nicht korrekt


Die ISR wird durchgelaufen obwohl keine Daten zu empfangen vorhanden 
sind.
Das Toggeln vom LED da einfach zum bedugen, hat keinen relevanten 
Einfluss auf die Funktinalität des ganzen.

Michael U. schrieb:
> Da ist mir was unklar: Ruhezustand des UART-RX ist ja H-pegel.

ja stimmt so wie du es meint. aber bei mir bleibt der RX-leitung auf 
Low, was total unnormal ist.   Wenn ich Reset drücke, gehen zuerst 
beide(Tx,Rx) auf Low dann bleibt Tx ständig auf High.  RX erzeug nur 
eine kleine Implus von ca 10ms dann bleibt ewig weiter auf LOW.
Warum das denn ? bin ich auf überfragt.  das Problem könnte daran 
liegen.

Und vielleicht weil es ständig auf Low bleibt , wird die ISR  ständig 
durchgelaufen.

Thilo M. schrieb:
> Ist die Masse zwischen Sender und Empfänger sauber verbunden?


die Massen sind sauber verbunden.

[Hc Z. (mizch)]

> ja stimmt so wie du es meint. aber bei mir bleibt der RX-leitung auf
> Low, was total unnormal ist.

Womit dann auch logisch ist, dass bei jedem Einschalten des Empfängers 
(also nach jedem Senden) eine Break_condition (ein NUL Character) kommt. 
Vermutlich fragst Du den Framing Error nicht ab, um die Break-Erkennung 
zu komplettieren.  Und für dieses eine NUL kommt natürlich auch ein 
Interrupt.

Also doch ein Hardware-Problem.

[Sascha W. (sascha-w)]

Hc Zimmerer schrieb:
>> ja stimmt so wie du es meint. aber bei mir bleibt der RX-leitung auf
>> Low, was total unnormal ist.
dann steht deine Gegenstelle nicht auf senden!

Sascha

[klaus (Gast)]

Uart-Client schrieb:
> Im meinem Programmcode bin ich von der Pollinverfahren auf...

welcher? Sen oder Jun
http://www.pollin.de/shop/images/pollin-sen+pollin-jun.jpg

[Uart-Client (Gast)]

klaus schrieb:
> welcher? Sen oder Jun
>
> http://www.pollin.de/shop/images/pollin-sen+pollin-jun.jpg

ist nicht gut sich über anderen Lustig zu machen , wenn sie hilfe 
brauchen.

[Uwe (Gast)]

Hi!
>wenn man es schon in der Uart-initialisierung als Empfänger setzt, dann
>sie die Port abgeschaltet.  und man braucht meiner Kenntnisse nach es
>nicht mehr zu steuern(Pull up oder Pull douwn).
Da wäre ich mir jetzt nicht so sicher, ein hochohmiger Eingang fängt 
allen Mist auf. Wenn Rx_en = 1, bedeutet es nicht das der Pullup=1 ist.
Schalte ihn ein oder hänge extern einen drann und teste. Ich denke es 
geht dann.

Viel Erfolg, Uwe

[Uart-Client (Gast)]

Uwe schrieb:
> Schalte ihn ein oder hänge extern einen drann und teste. Ich denke es
>
> geht dann.

das habe ich gemacht. ohne Erfolg. Bei diesem einstellung folgt es sogar 
den Pegel des enable-leitung vom RS485.
Sowohl mit interne oder mit externe Pull Up bekomme ich immer am Ende 
einer Übertragung über sein TX diese 10µs Impuls am Rx-eingang. Dies 
wird dann bei der Interrupt Routine als Starbit annerkannt.(obwohl nur 
Mist ist).

Übrigens meine Rx-Leitung ist Ständig auf Low. weiß einer wieso???

[Hc Z. (mizch)]

> Übrigens meine Rx-Leitung ist Ständig auf Low. weiß einer wieso???

Irgendwie schrieb ich schon oben zu genau diesem Thema "Womit dann auch 
logisch ist ..."

Vielleicht schaust Du erstmal nach Deiner Hardware und schließt einen 
Fehler dort nicht kategorisch aus.  Deine RX-Leitung am IC hat im 
Ruhezustand High zu sein.  Sonst ist nämlich logisch ... aber das 
schrieb ich schon.

[Uart-Client (Gast)]

Hc Zimmerer schrieb:
> Womit dann auch logisch ist, dass bei jedem Einschalten des Empfängers
>
> (also nach jedem Senden) eine Break_condition (ein NUL Character) kommt.
>
> Vermutlich fragst Du den Framing Error nicht ab, um die Break-Erkennung
>
> zu komplettieren.  Und für dieses eine NUL kommt natürlich auch ein
>
> Interrupt.

ok. wie kann man es bitte abfragen , wenn ich das wüsste vielleicht 
würde ich in diese Panne seit paar Tage nicht stehen .

danke

[Hc Z. (mizch)]

Abfragen ... meintest Du "abfangen"?

Du musst dafür sorgen, dass Deine Hardware empfangen kann.  Dazu gehört, 
dass im Ruhezustand am RxD-Pin eine 1 gemessen wird.  Wie die 0, die Du 
misst, zustande kommt, kannst (bisher, die Verschaltung wurde nicht 
erwähnt) nur Du wissen.  Also miss nach, woher die 0 kommt.

[Uart-Client (Gast)]

Hc Zimmerer schrieb:
> Wie die 0, die Du
>
> misst, zustande kommt, kannst (bisher, die Verschaltung wurde nicht
>
> erwähnt) nur Du wissen.

hier in anhang die Beschaltung . alles richtig

[Uart-Client (Gast)]

auf dem STK500 ohne weitere externen beschaltung, bekomme ich auch 
kontinuerlich nur ein Low Pegel auf der RX-pin zu sehen.
Wie ist es zu erklären?

[Uart-Client (Gast)]

Ich habe noch am Master am R1  Pin A ein 470Ohm Pull-Up , und Pin B ein 
470Ohm Pull-down dran gehängt.  damit wenn nichts ankommt , die 
Rx-Leitung auf High bleibt. Das bringt aber kein ergebnis. Die 
RX-Leitung ist immerhin LOW.

[Hc Z. (mizch)]

Die Pull-Ups/Downs sind richtig.  Kann es sein, dass ein Slave dauernd 
treibt (seine OE-Leitung dauerhaft high hat)?  Kannst Du die Slaves 
irgendwie abtrennen, um deren Einfluss zu unterbinden (abstecken)?

(EDIT: OE ist high aktiv.)