www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik MAX485 Schaltzeit verkürzen


Autor: Björn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich übertrage mit einem MAX485 Daten über das USART eines ATMega32. /RE 
und DE sind beide am gleichen Pin des AVR's. Die Sache ist, dass ich ca. 
3ms vor der Übertragung den DE auf high setzen muss, sonst gehen mir 
Daten verloren. Laut Datenblatt sollten das maximal 2µS sein.

Der AVR läuft mit 14 MHz, also dass der I/O zu langsam schaltet, kann es 
eigentlich auch nicht sein.

Habt ihr eine Idee wie ich das beschleunigen kann?

Danke.

Autor: avion23 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pin auf Ausgang gesetzt?
Wartest du, bis die daten alle aus dem avr uart raus sind? Wenn ja, wie?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ansatz: Die wirkliche Ursache des Problems finden. Denn die liegt 
wahrscheinlich woanders.

Ein Kandidat: Der Treiber den neuen Senders schaltet ein, bevor der 
bisherige Sender abgeschaltet hat. Oder der Sender schaltet ab, bevor 
wirklich alles raus ist.

Autor: Björn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wartest du, bis die daten alle aus dem avr uart raus sind? Wenn ja, wie?
ja, so:
while (!(UCSRA & (1<<UDRE))){}      //warten bis das letzte Byte 
gesendet wurde

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>while (!(UCSRA & (1<<UDRE))){}      //warten bis das letzte Byte

Falsch. Damit wartest du bis das Datenregister wieder frei ist. Da das 
aber gepuffert ist, kann aber zu der Zeit noch eine Übertragung 
stattfinden. Das Ende einer Übertragung wird durch TXC angezeigt.

MfG Spess

Autor: Hans Josef (hjm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ja, genau wie mein Vorschreiber geschrieben hat mußt Du mit:
loop_until_bit_is_set(UCSRA, TXC);
auf die Meldung warten das das Schieberegister leer ist.

Mit:
while (!(UCSRA & (1<<UDRE))){}
wartest Du nur das der Sendepuffer frei wird. D.h. ein Byte ist gerade 
beim Senden und eines im Sendepuffer.

Wenn Du dann abschaltest gehen Dir also bis zu 2 Byte verloren.

Grüße

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Wenn Du dann abschaltest gehen Dir also bis zu 2 Byte verloren.

Nein. UDRE wird erst gesetzt, wenn das Byte im Schieberegister ist. Also 
geht maximal 1 Byte verloren.

MfG Spess

Autor: Björn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
also jetzt warte ich, wie vorgeschlagen, mit
loop_until_bit_is_set(UCSRA, TXC);
muss aber dennoch 200µS warten. Wenn ich nur 100µS warte geht es auch, 
auch wenn ich gar nicht warte, aber umso mehr Fehler kriege ich ich.

Auch beim Einschalten von DE muss ich warten, 300µS zur Zeit.

Seltsamerweise habe ich auch Resets des µC die direkt mir der 
Kommunikation des USARTS zusammen hängen. Je schneller die 
Kommunikation, desto mehr Resets. Ein weiteres Problem in der Praxis 
worauf ich in der Theorie keine Antwort finden kann. Mit deaktiviertem 
Brown out und WatchDog kann es ja im Grunde bloss ein 
Versorgungsspannungsproblem sein. Aber ob mit 100nF oder 100µF 
Kondensator zwischen VCC und GND, die Resets werden nicht reduziert. Der 
Reset ist auch nach Vorschrift beschalten. Ob die beiden Probleme 
zusammen hängen ist die andere Frage.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Björn (Gast)

>loop_until_bit_is_set(UCSRA, TXC);

>muss aber dennoch 200µS warten. Wenn ich nur 100µS warte geht es auch,
>auch wenn ich gar nicht warte, aber umso mehr Fehler kriege ich ich.

Mann, Mann, Mann. Ist es dir vielleicht mal in den Sinn gekommen, dass 
man soetwas NUR mit einem KOMPLETTEN Quelltext bewerten kann?

>Auch beim Einschalten von DE muss ich warten, 300µS zur Zeit.

Dann ist was faul. Ich tippe auf ein Softwareproblem. Z.B. Port nicht 
als Ausgang definiert, dann schaltest du nur den Pull-Up, un der ist 
schwach.

>Seltsamerweise habe ich auch Resets des µC die direkt mir der
>Kommunikation des USARTS zusammen hängen. Je schneller die
>Kommunikation, desto mehr Resets.

Stack Overflow durch zuviele Interrupts?

> Ein weiteres Problem in der Praxis
>worauf ich in der Theorie keine Antwort finden kann. Mit deaktiviertem
>Brown out und WatchDog kann es ja im Grunde bloss ein
>Versorgungsspannungsproblem sein. Aber ob mit 100nF oder 100µF
>Kondensator zwischen VCC und GND, die Resets werden nicht reduziert.

100nF MÜSSEN sein, ohne wenn und aber!

MFG
Falk

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich gehe jetzt einfach mal davon aus, dass die Software garnicht das 
Problem ist. Für eine komplette Bewertung braucht man nämlich in diesem 
Fall die Hardware und die Software.

Je schneller die Teilnehmer an einem RS485/422 Bus auf Input schalten, 
desto länger ist der Bus offen. Ein RS485 arbeitet aber mit 
differenziellen Pegeln ohne Bezug, wenn man ihn garnicht, oder nur 
einfach terminiert ( 120R zwischen A/B). D.h. er floatet, wenn kein 
Teilnehmer seinen Sender eingeschaltet hat. Eine Lösung wäre, dass der 
nächste Sender DE anlegt, bevor der letzte Sender DE abfallen lässt. 
Eine kniffelige Angelegenheit, vom Timing her.

Sinnvoller ist es, zusätzlich zwei Widerstände von A nach +5V und B nach 
GND zu schalten. Diese ziehen die Signalleitungen in einen definierten 
Zustand, wenn alle Teilnehmer auf Input stehen. Dies kann man entweder 
an jedem Teilnehmer oder nur an einem machen, bedingt aber dann die 
Weiterleitung von GND an alle Teilnehmer.

Quelle meiner Behauptung sind die RS422/485 Application Notes von TI, 
Analog Devices und, sehr schön erklärt, auch bei Maxim.

Gruß, Ulrich

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Ulrich P. (uprinz)

>einfach terminiert ( 120R zwischen A/B). D.h. er floatet, wenn kein
>Teilnehmer seinen Sender eingeschaltet hat.

Nöö, er geht auf LOW, durch sie 120 Ohm. Und das passt dem UART GAR 
NICHT!

> Eine Lösung wäre, dass der
>nächste Sender DE anlegt, bevor der letzte Sender DE abfallen lässt.
>Eine kniffelige Angelegenheit, vom Timing her.

Eben.

>Sinnvoller ist es, zusätzlich zwei Widerstände von A nach +5V und B nach
>GND zu schalten. Diese ziehen die Signalleitungen in einen definierten
>Zustand, wenn alle Teilnehmer auf Input stehen.

Genau so macht man das.

> Dies kann man entweder
>an jedem Teilnehmer oder nur an einem machen, bedingt aber dann die
>Weiterleitung von GND an alle Teilnehmer.

GND MUSS SOWIESO AN JEDEM TEILNEHMER VERBUNDEN WERDEN! NUR WEIL ES 
DIFFERENTIELL IST, IST ES NICHT WECHSELSPANNUNGSGEKOPPELT!

MfG
Falk

Autor: Stefan Wimmer (wswbln)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ten Ways to Bulletproof RS-485 Interfaces:
http://www.national.com/an/AN/AN-1057.pdf

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
>
> GND MUSS SOWIESO AN JEDEM TEILNEHMER VERBUNDEN WERDEN! NUR WEIL ES
> DIFFERENTIELL IST, IST ES NICHT WECHSELSPANNUNGSGEKOPPELT!
>
Hi Falk!

Schrei mich doch nicht gleich an :) Hast ja recht.
Ist bei den meisten Bastelprojekten durch die mitgeführte Versorgung der 
Peripherie aus einem zentralen Netzteil eh gegeben. Aber freut mich, 
dass Du in den meisten Punkten meiner Meinung warst.

Gruß, Ulrich

Autor: Björn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
leider kann ich mich mit dem Problem der langsamen Umschaltzeit gar 
nicht mehr befassen weil sich der µC schon fast Sekündlich resettet. Es 
liegt definitiv an der RS485 Kommunikation. Wenn ich den MAX485 trenne, 
gibts auch keine Resets mehr. Auch wenn ich an den Rx ein Rechtecksignal 
anlege um weiter Interrupts auszulösen nicht. Von daher vermute ich den 
Reset-Grund in einem Versorgungsspannungsproblem das direkt mit dem Max 
zu tun hat.

Die Frage ist nun, kann ich den µC vom Max sinnvoll entkoppeln? Nicht 
optisch meine ich, sondern mit Widerständen/Dioden einen Kurzschluss, 
oder was auch immer da geschehen mag, verhindern. Auf Schaltplänen habe 
ich immer nur direkte Verbindung gesehn, daher weiss ich nicht was ich 
tun kann ohne die Funktion zu beeinträchtigen.

ratlosen Gruß
Björn

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Björn (Gast)

>leider kann ich mich mit dem Problem der langsamen Umschaltzeit gar
>nicht mehr befassen weil sich der µC schon fast Sekündlich resettet. Es

Interrupts freigegeben aber nicht als ISR() vorhanden?

>Die Frage ist nun, kann ich den µC vom Max sinnvoll entkoppeln? Nicht

Ist nicht notwendig. Einfach normal verbinden. An jeden IC DICHT 100nF 
dran, dann sollte das passen.

MFG
Falk

Autor: Björn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>An jeden IC DICHT 100nF dran, dann sollte das passen.

genau das hatte ich gerade probiert. War zwar mehr oder weniger ein 
Schuss ins Blaue, aber der 100nF zwischen GND und RO scheint das Problem 
tatsächlich behoben zu haben. Ob damit auch das Geschwindigkeitsproblem 
verschwunden ist, muss ich erst noch testen.

Aber soweit schonmal vielen Dank für die Unterstützung.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> aber der 100nF zwischen GND und RO

WO?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  Björn (Gast)

>Schuss ins Blaue, aber der 100nF zwischen GND und RO scheint das Problem
>tatsächlich behoben zu haben.

AUA! Die 100nF gehören an GND und VCC!!!!

MFg
Falk

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Falk Brunner schrieb:
>> Schuss ins Blaue, aber der 100nF zwischen GND und RO scheint das Problem
>> tatsächlich behoben zu haben.
> AUA! Die 100nF gehören an GND und VCC!!!!

Das hattest du aber auch nicht ausdrücklich explizit erwähnt:
>>>> An jeden IC DICHT 100nF dran, dann sollte das passen.
Diese Aussage ist schon recht weit auslegbar ;-)

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit den 100nF hat meine Laune schon gerettet...

Aber das könnte auch aufzeigen, wo das problem liegt:
Wenn der RS422 Treiber so viel Strom zieht, dass er die Schaltung zum 
Absturz bringt, dann scheint mir das ein deutliches Zeichen dafür zu 
sein, dass er gegen einen anderen Treiber am Bus arbeitet. Sonst hätte 
er für die Stromaufnahme keinen grund. Hier liegt noch etwas mit der 
Richtungsumschaltung aller Beteiligten im argen.

Dass 100nF an RO das Problem eingrenzen, kann daran liegen, dass die 
Richtungsumschaltung nun langsamer geht und dadurch die Kurzschlussphase 
verringert wird.

Gruß, Ulrich

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das hattest du aber auch nicht ausdrücklich explizit erwähnt:
> >>>> An jeden IC DICHT 100nF dran, dann sollte das passen.
> Diese Aussage ist schon recht weit auslegbar ;-)

Zu Wissen, daß Abblockkondensatoren nötig sind, und wie mit ihnen 
umzugehen ist, wird von vielen als so selbstverständlich wie das Atmen 
angesehen.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte auch schonmal ein lustiges Problem mit RS485 mit einem
M16C. Der hat auch ein Bit das anzeigt ob das letzte Bit schon
raus ist. Das setzt der Prozessor aber wohl bereits wenn er
noch mittem im letzten Bit ist.
Wenn ich dann sofort den Bustreiber abgeschaltet habe dann war das
letzte Bit so zu 50-70% draussen. Das fuehrte dazu das es oft, aber
nicht immer funktioniert hat. Noch dazu Abhaengig davon was man sonst
alles am Bus hat.
Wenn man dann noch etwas im IRQ laufen hat dann kann
es noch sein das die Funktion gerade guenstig unterbrochen wird und
dann manchmal doch noch letzte Bit vollstaendig raus geht. Aber halt
auch nicht immer!

Jetzt ist das natuerlich ein ganz anderer Controller, aber gerade vor
dem Hintergrund das es mit den 100nF an der Datenleitung funktioniert 
hat,
wuerde ich mal dringendst empfehlen den Oszi oder Logicanlyzer auf
die Leitungen zu klemmen und sich das mal GENAU anzuschauen.

Olaf

Autor: Björn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ein Kondensator zwischen GND und VCC des Max hat nichts gebracht, C 
zwischen RO und GND hat das Problem des Resettens komplett behoben. Und 
da ich persöhnlich Lösungen bevorzuge die zu Efolg führen statt "by the 
Book" sind, kann ich die ganzen Aufschreie nicht ganz verstehn.

Dass das letzte Bit nicht raus kann, kann es auch nicht sein, da ich 
sowieso noch 100µS warte, bevor ich ich den Driver auf Low ziehe.

Ich werde sicher zu einem späteren Versuch noch an den Timings rum 
spielen und versuchen zu optimieren, aber das Wichtigste ist, dass es 
jetzt schon fehlerfrei funktioniert und das muss im Augenblick reichen.

Danke soweit.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Und da ich persöhnlich Lösungen bevorzuge die zu Efolg führen statt "by the 
>Book" sind, kann ich die ganzen Aufschreie nicht ganz verstehn.

Ich schon. Liegt vielleicht daran, das die anderen ( und ich auch) der 
Meinung sind, das du ein Symptom und nicht die Ursache beseitigt hast.

MfG Spess

Autor: Björn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>das du ein Symptom und nicht die Ursache beseitigt hast.
mag sein, aber solange ich die Ursache nicht kenne bleibt mir ja nichts 
anderes Übrig. Dass der Max einen Spannungseinfall verursacht der den µC 
resetten lässt schließe ich aus, da der Kondensator am µC den 
absorbieren müsste. Ich bin nach wie vor der Meinung, dass der RO einen 
HF Anteil mit sich bringt der dem µC nicht gefallen hat und der jetzt 
weg gefiltert wird. Da ich aber weder Speicheroszi noch Spektrumanalyzer 
habe, bleibt es bei einer Vermutung.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du mal eruiert, was laut Controller solch einen Reset ausgelöst 
hat? Steht in MCUCSR oder so drin. Auslesen, löschen(!), anzeigen.

Was die Kondensatoren angeht: Am Controller selbst sind hoffentlich auch 
welche, und zwar dicht dran, nicht 4cm Leitungslänge entfernt, und 
jeweils einer pro VCC/GND Paar.

Ein Bild von Schaltung und vom Layout wäre auch kein Fehler.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>Ich bin nach wie vor der Meinung, dass der RO einen
>HF Anteil mit sich bringt der dem µC nicht gefallen hat und der jetzt...

Sehr gewagte Annahme. Einerseits würde das die generelle 
Funktionsfähigkeit des MAX485 in Frage stellen, andererseits halte ich 
es (aus eigener 12-jähriger Erfahrung mit AVRs) für unwahrscheinlich, 
das ein Signal, das sich innerhalb der elektrischen Spezifikationen der 
AVRs bewegt, an einem Port einen Reset hervorruft. AVRs reagieren da 
eher gutmütig.

MfG Spess

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:

> es (aus eigener 12-jähriger Erfahrung mit AVRs) für unwahrscheinlich,
> das ein Signal, das sich innerhalb der elektrischen Spezifikationen der
> AVRs bewegt, an einem Port einen Reset hervorruft.

Ein vorstellbares Szenario hätte ich dafür: Wenn dieses RO/RXD-Signal 
gegen einen Ausgang vom AVR ankämpft (z.B. Lötbrücke) und der 
entstehende sehr schnelle Stromanstieg den nicht sauber mit Cs 
geblockten Controller kurz verhungern lässt. Der 100nF reduziert dann 
die Steilheit.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

>> es (aus eigener 12-jähriger Erfahrung mit AVRs) für unwahrscheinlich,
>> das ein Signal, das sich innerhalb der elektrischen Spezifikationen der
>> AVRs bewegt, an einem Port einen Reset hervorruft.

>Ein vorstellbares Szenario hätte ich dafür: Wenn dieses RO/RXD-Signal
>gegen einen Ausgang vom AVR ankämpft (z.B. Lötbrücke) und der
>entstehende sehr schnelle Stromanstieg den nicht sauber mit Cs
>geblockten Controller kurz verhungern lässt. Der 100nF reduziert dann
>die Steilheit.

Da Björn in punkto Schaltbild, Quellcode und Aufbau totale 
Geheimniskrämerei betreibt, fällt das alles hier eigentlich nur unter 
Spekulation. Eigentlich sinnlos sich da noch Gedanken zu machen.

MfG Spess

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
spess53 schrieb:
>
> Da Björn in punkto Schaltbild, Quellcode und Aufbau totale
> Geheimniskrämerei betreibt, fällt das alles hier eigentlich nur unter
> Spekulation. Eigentlich sinnlos sich da noch Gedanken zu machen.
>

Deswegen schau ich hier auch nur noch hin und wieder mal vorbei. Raten 
ist so mühsam...

Gruß, Ulrich

Autor: Uwe (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
Falk Brunner schrieb:
>
> GND MUSS SOWIESO AN JEDEM TEILNEHMER VERBUNDEN WERDEN! NUR WEIL ES
> DIFFERENTIELL IST, IST ES NICHT WECHSELSPANNUNGSGEKOPPELT!
>
Das ist falsch. Die Teile arbeiten rein differentiell und benötigen
nicht zwangsläufig eine Masseverbindung.
Ja, das kann sogar schädlich sein was mein letzter Blitzschlag beweist.
Ich habe hier 11 Scannermodule am laufen welche über eine 100m Halle
verteilt sind und sich über RS422 unterhalten. 1 weiteres befindet sich
in einer anderen Halle, Kabellänge ca.180m. Die 11 in der einen Halle
werden über das Kabel mit Ub versorgt, das andere hat eine eigene
Wandwarze. Letzte Woche, kurze heftige Beleuchtung, gefolgt von lautem
Grollen und 9 von 11 Scannmodulen waren futsch.
Das Eine, weit weg, geht noch.
Nunja, die Masse war nur einseitig aufgelegt.
Also immer schön vorsichtig mit solchen Behauptungen.
Es wird zwar dazu geraten die Massen zu verbinden, aber von "MUSS"
steht bei mir nichts.

Einen schönen Tag noch, Uwe

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.