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.
Pin auf Ausgang gesetzt? Wartest du, bis die daten alle aus dem avr uart raus sind? Wenn ja, wie?
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.
>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
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
Hallo, ja, genau wie mein Vorschreiber geschrieben hat mußt Du mit:
1 | loop_until_bit_is_set(UCSRA, TXC); |
auf die Meldung warten das das Schieberegister leer ist. Mit:
1 | 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
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
also jetzt warte ich, wie vorgeschlagen, mit
1 | 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.
@ 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
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
@ 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
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
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
@ 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
>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.
@ 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
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 ;-)
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
> 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.
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
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.
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
>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.
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.
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
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.
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
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
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.