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.
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?
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.
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.
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
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.
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.
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.
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.