Forum: Mikrocontroller und Digitale Elektronik ADM3072 Enable leitung


von Andreas A. (Gast)


Lesenswert?

Mit dem ADM3072 möchte ich über RS485 eine Telegramm empfangen und 
direkt eine Antwort zurücksenden. Das mache ich über 2 Leiter RS484 und 
einen GND Leiter. Die re und de Eingänge habe ich jeweils auf nur einen 
pin am Mikrocontroller gelegt, weil ich nur senden oder empfangen 
möchte. Ich teste das über einen China rs484 zu USB Adapter auf ftdi 
Basis. Leider muss ich beim umschalten von senden und empfangen fast 2ms 
warten, sonst kommt nur Müll am PC an. Das ganze ist terminiert mit 
120Ohm. Hat jemand Ideen? Ich fürchte ja fast das ist dieser billig ftdi 
Adapter.

von DerEinzigeBernd (Gast)


Lesenswert?

Andreas A. schrieb:
> Ich fürchte ja fast das ist dieser billig ftdi
> Adapter.

Die FTDI-Bausteine haben eine Hardwareunterstützung für die 
RS485-Sender/Empfänger-Umschaltung. Das wird nicht das Problem sein, 
auch in China kann man RS485-Treiber richtig anschließen.

> Leider muss ich beim umschalten von senden und empfangen fast
> 2ms warten,

Welche Baudrate, welcher µC und auf welche Art und Weise bestimmst Du 
nach dem Senden den richtigen Zeitpunkt, um auf Empfang umzuschalten?

von Andreas A. (Gast)


Lesenswert?

DerEinzigeBernd schrieb:
> Welche Baudrate, welcher µC und auf welche Art und Weise bestimmst Du
> nach dem Senden den richtigen Zeitpunkt, um auf Empfang umzuschalten?

Atmega328 mit 9600 baud. Am Ausgang des atmega habe ich mit dem scope 
gemessen das passt alles.

von Andreas A. (Gast)


Lesenswert?

Ich sende vom PC und der atmega ist die ganze Zeit auf Empfang. Wenn er 
sein Telegramm erkannt hat schaltet er auf senden um direkt nach dem 
letzten byte vom PC zu senden. Da ist natürlich noch etwas Zeit 
zwischen, die die CPU braucht.

von Georg (Gast)


Lesenswert?

Andreas A. schrieb:
> Wenn er
> sein Telegramm erkannt hat schaltet er auf senden um direkt nach dem
> letzten byte vom PC zu senden.

Aha - und wie und wann schaltet der PC auf Empfang?

Georg

von Andreas A. (Gast)


Lesenswert?

Ich weiß nicht welcher ftdi da verbaut ist aber bisher war es bei denen 
immer so, dass die permanent empfangen bis etwas im transmitter fifo 
ist.

von DerEinzigeBernd (Gast)


Lesenswert?

Andreas A. schrieb:
> aber bisher war es bei denen
> immer so, dass die permanent empfangen bis etwas im transmitter fifo
> ist.

So sollte es bei jedem RS485-Gerät sein, sonst wird durch den unnötig 
aktivierten RS485-Treiber der Bus blockiert.

Die in den üblichen FTDI-Bridges implementierte Variante funktioniert in 
allen mir bekannten Fällen äußerst zuverlässig. Da muss schon ein 
Schaltungsfehler vorliegen. Manche primitiv-Implementierungen von 
RS485-Treibern werden mit einer dafür zweckentfremdeten Handshakeleitung 
der seriellen Schnittstelle angesteuert, was dann die Software erledigen 
muss. Die FTDI-Briges haben dafür aber eine eigene Steuerleitung, die 
logischerweise auch verwendet werden sollte.

So eine Primitiv-Implementierung hat man aber auch, wenn man einen 
FTDI-Baustein mit RS232-Treibern verwendet, um damit wiederum einen 
RS232-zu-RS485-Konverter anzusteuern. Sowas sollte man tunlichst 
vermeiden.

Wenn man den Empfänger im RS485-Treiber im Sendebetrieb nicht 
deaktiviert, kann man auch die selbst gesendeten Daten als Sendeecho 
wieder empfangen, was im Busbetrieb hilft, Kollisionen mit falsch 
sendenden anderen Geräten zu erkennen, oder eben gestörten Bus durch 
nicht deaktivierte Sender.

Wenn das Sendeecho OK ist, besteht eine gewisse Chance, daß das zu 
sendende auch wirklich gesendet werden konnte.

Andreas A. schrieb:
> Atmega328 mit 9600 baud.

Taktquelle? Auch bei 9600 Baud ist der interne RC-Oszillator zu ungenau.

von Jens E. (Gast)


Lesenswert?

DerEinzigeBernd schrieb:
> Taktquelle? Auch bei 9600 Baud ist der interne RC-Oszillator zu ungenau.

Der interne RC für UART bei 9600 baud zu ungenau? Ich mach schon lange 
was mit den Prozessoren und das gab nie Probleme. Das muss was anderes 
sein.

von Gustav G. (gustavgggg)


Lesenswert?

DerEinzigeBernd schrieb:
> Taktquelle? Auch bei 9600 Baud ist der interne RC-Oszillator zu ungenau.

Kann ich mir kaum vorstellen. 9600 Baud sind gerundet 104µs pro bit. 
Wenn ein RC Oszillator eines Prozessors dafür zu ungenau ist hast du 
ganz andere Probleme. Der wird zu ungenau sei um damit für lange Zeit 
genaues Timing zu erreichen aber nach einem gesendeten Byte wird beim 
UART sowieso neu synchronisiert durch das Startbit also ist das bei der 
Geschwindigkeit zu vernachlässigen.

Bitte 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
Noch kein Account? Hier anmelden.