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?
1
voiduart_Init(void)
2
{
3
unsignedintx;
4
5
DDRD|=(1<<DDD4);// Treiber_Enable für RS485 als Ausgang
6
7
// Baudrate Einstellung
8
UBRR0H=(unsignedchar)(TEILER>>8);
9
UBRR0L=(unsignedchar)TEILER;
10
11
//Sender , Empfänger und Datenempfanginterrupt ein
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.
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
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.
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
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
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?
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
> verwursten.
Nein, denn UDR0 ist volatile, deshalb wird daraus eher so was:
1
ISR(USART_RX_vect)
2
{
3
UDR0;
4
PORTB^=(1<<DDB3);
5
}
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".
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 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
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.
> 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.
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
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
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???
> Ü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.
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
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.
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
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.
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.)