www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RS232<->RS485 kann sich das mal einer angucken?


Autor: Sascha (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Ich habe versucht einen RS232<->RS485 Konverter zu entwerfen. Ich bitte 
mal darum die Schaltung im Anhang zu prüfen und mir zu sagen, ob das so 
richtig ist oder ob ich irgendwo einen Fehler mache.

Vielen Dank für die Mühe,
sascha

Autor: Sascha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
oh.. IC1 ist ein MAX485

Autor: Rahul Der trollige (rahul)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sind C8 und C9 richtig herum? (Hab das Datenblatt gerade nicht zur 
Hand).
Dem Richtungssteuerpin des MAX485 könntest du noch einen Pull-down 
Widerstand spendieren.

Autor: Sascha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
jo... C8 und C9 stimmen so. Da Stecken dann die -12V bzw. +12V drin. 
Welchen Zweck würde der Pull-Down erfüllen?

Autor: Rahul Der trollige (rahul)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Welchen Zweck würde der Pull-Down erfüllen?

Der MAX485 würde nicht ungewollt ins Netz senden.
Bietet sich dann an, wenn der steuernde Portpin auch hochohmig werden 
kann.

(Ist nur ein Vorschlag)

Autor: Sascha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Bietet sich dann an, wenn der steuernde Portpin auch hochohmig werden
>kann.

Aber kann er doch nicht, oder? Also der Ausgang vom Max232 ist doch 
immer H oder L. Oder nicht?

Autor: Josef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Pin 2 und 3 vom Max 485 gehören gebrückt. Masse weg.


SG Josef

Autor: Sascha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Josef
Danke... das leuchtet natürlich ein. Darum ist einer auch invertiert.

Autor: Rahul Der trollige (rahul)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Pin 2 und 3 vom Max 485 gehören gebrückt. Masse weg.

Jein.
Wenn man die Daten empfangen will, die man sendet/gesendet hat, dann 
kann man den RE-Pin (oder war es der andere?) auch konstant grounden.

Autor: Sascha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja... das will ich ja net unbedingt. Das hätte ich dann in der 
Software "weggeschmissen".

Autor: Rahul Der trollige (rahul)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist interessant, wenn man auch Kollisionen auch erkennen kann. Dafür ist 
der MAX485 aber zu niederohmig.

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Software dazu ist interessanter. Ich habe festgestellt, daß unter 
Windows die Richtungssteuerung sehr träge ist. Wenn der PC ein 
Datenpaket sendet und der andere Teilnehmer (z.B. eine uC-Schaltung) 
sehr kurz danach seinerseits antwortet, hat der PC evt. noch nicht auf 
Empfang geschaltet. Da muß man sein Augenmerk drauf richten.

Besser geht das mit einem USB-RS232-Chip mit Richtungssteuer-Ausgang 
(z.B. FTDI).

Oder man macht die Richtungssteuerung in Hardware mit einer Art 
Monoflop, mit einem Timeout von etwas mehr als einer Zeichenlänge (dann 
muß man aber je nach Baudrate das Monoflop umschalten).

Autor: Sascha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Tip, aber da der Hersteller der Slaves auch einen solchen 
(teuren) RS232<->RS485 Wandler anbietet ist davon auszugehen, dass die 
Slaves sich ein wenig Zeit lassen, bis sie antworten.

Autor: jasmin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ günter....


das ist doch unsinn.... träge richtungssteuerung unter windows ???


dietmar

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@dietmar:

Nun, man muß natürlich die Programmierumgebung bzw. verwendete Sprache 
dazu betrachten. Ich verwende Delphi 5 (Object Pascal) und die 
Serial-Komponente CPORT von Dejan Crnila.

Bei einem Programm-Projekt wollte ich RS485-Betrieb realisieren und habe 
es relativ primitiv so programmiert, daß ich RTS aktivierte, dann den 
String sendete und danach RTS wieder inaktivierte. Was ich zunächst 
nicht bedachte, war, daß Windows solche übergebenen Daten ja mehrfach 
puffert und sie irgendwann an den Hardware-Treiber weitergibt, der die 
Zeichen dann rausbringt. Wie dazu aber das Setzen/Löschen von RTS 
korreliert, kann man u.U. schlecht abschätzen; jedenfalls war das 
Ergebnis, das ich erzielte, dermaßen schlecht, daß ich mir abgeschminkt 
habe, mit solch einfachen Mitteln einen RS485-Betrieb zu programmieren. 
Mit Turbo-Async mag's besser gehen, das habe ich nicht getestet.

Ich habe mir dann ein RS232-RS485-Interface mit Timeout-Monoflop 
selbstgebaut, damit funktioniert es perfekt, aber die Senderaktivierung 
wird damit ja in Hardware (und unabhängig von Windows) durchgeführt; das 
Programm weiß garnicht, daß RS485 stattfindet. Kleiner Nachteil meines 
Interfaces: ich muß die Baudrate dort einstellen.

Praktisch alle käuflichen Interfaces sind so aufgebaut, wie Sascha es 
gemacht hat, und die geben zwar damit an, sie seien baudratenunabhängig, 
aber sie haben halt alle den Nachteil, daß die RS485-Funktion davon 
abhängig ist, daß der UART bzw. das dahinter hängende Programm die 
Richtungssteuerung richtig bewerkstelligt. Man sollte somit (ggf. 
mittels Oszilloskop) mal danach schauen, wann vor dem Beginn des 
Datenpakets der Bus belegt wird, und wie schnell nach dem Ende des 
Datenpakets er wieder frei wird, sodaß andere Teilnehmer gleich danach 
senden können. Da kann man Überraschungen erleben ...



Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Günter R.

>es relativ primitiv so programmiert, daß ich RTS aktivierte, dann den
>String sendete und danach RTS wieder inaktivierte. Was ich zunächst
>nicht bedachte, war, daß Windows solche übergebenen Daten ja mehrfach
>puffert und sie irgendwann an den Hardware-Treiber weitergibt, der die
>Zeichen dann rausbringt. Wie dazu aber das Setzen/Löschen von RTS
>korreliert, kann man u.U. schlecht abschätzen; jedenfalls war das

Nun, dazu braucht man halt nen Kernel Driver. Nicht ganz trivial. Ich 
hab das vor längerer Zeit auch einfach per Hardware gelöst (AVR als 
Busmaster).

MFG
Falk


Autor: Severino (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Günter

Deine Sache mit dem Timeout-Monoflop interessiert mich sehr, da ich ein 
ähnliches Problem lösen will. Dabei geht es allerdings nicht um RS485, 
sondern um eine etwas spezielle Halbduplex-Kommunikation (proprietär; 
tut hier nichts zur Sache), wo ich ebenfalls mit RTS die 
Übertragungsrichtung setze. Der Sender muss vor dem Senden des ersten 
Bytes aktiviert werden und muss es bleiben, bis das letzte Byte gesendet 
wurde (dies ist übrigens ohnehin etwas knifflig, da der UART einem nicht 
mitteilt, wann ein Byte wirklich bis zum letzten Stopbit gesendet worden 
ist).
Die Beobachtung, dass unter Windows das Setzen von Handshake-Leitungen 
nicht zuverlässig mit dem Timing des Datenstroms synchronisiert ist, 
habe ich auch machen müssen. So will ich etwas realisieren, das 
unabhängig vom RTS funktioniert, wobei in meinem Fall die Baudrate fix 
ist.
Jedenfalls, da ich das RTS sicher VOR dem ersten Byte setzen muss, und 
auch die Elektronik nicht in die Zukunft sehen kann, ist mein 
Lösungsansatz wie folgt: Einen PIC in die Sendeleitung schalten, wenn 
der ein Byte empfängt, das Byte puffern, Sender einschalten, Byte 
senden, und natürlich in der Zwischenzeit weitere Bytes empfangen. Am 
Schluss nach einem Timeout in der Länge eines Bytes den Sender wieder 
ausschalten.

Wenn es Dir nichts ausmacht, würdest Du Deine Monoflop-Lösung posten?

Vielen Dank
Severino

Autor: jochen_str (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem das Günther beschreibt, ist genau mit diesem Pull-Down 
widerstand zu lösen da der Max485 sehr träge umschaltet sofern man den 
Driver-Enable nicht über einen Widerstand runter auf Masse zieht.

Schaltpläne für solche Wandler gibts auf meiner HP:

http://www.rs485-hausbus.de.vu


Gruss
Jochen_str

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@jochen_str

>Das Problem das Günther beschreibt, ist genau mit diesem Pull-Down
>widerstand zu lösen da der Max485 sehr träge umschaltet sofern man den
>Driver-Enable nicht über einen Widerstand runter auf Masse zieht.

Das wage ich zu bezweifeln. Der MAX schaltet schon sehr schnell (ein 
paar dutzend Nanosekunden) um, man muss aber schon den Steuereingang 
(Driver enable) auch mit einem Logikausgang schalten, und nicht in der 
Luft hängen lassen. Ausserdem sprach Günther doch wohl eher von 
Softwareproblemen (schlecht definiertes Timing bei Zugriff von 
Userprogrammen auf RS232 Port).

MfG
Falk

Autor: Sascha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn ich euch und eure teils kontroversen Meinungen richtig 
verstehe, dann sollte meine Schaltung prinzipiell funktionieren. Wenn 
beim Schnittstellen-Zugriff über die Windows API Timing-Probleme 
auftauchene, dann muss ich mir eben doch die "Last" eines 
Kernel-Mode-Treibers aufladen.

Autor: Jochen S. (jochen_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich verwende für eine Pc seitige Steuerung auch das RTS-Signal, 
welches  ich über Visual Basic (welches nicht direkt auf die Kernal 
zugreift, sondern ein Basic-Modul das übernimmt) die Zwei Steuereingänge 
des MAX485 sind zusammengeschaltet und laufen auf den MAX232 der das RTS 
signal umsetzt, von +-12v auf 5 bzw 0 v und dann braucht man denoch 
einen R der mir den DE auf masse zieht weil er sonst nicht gescheit 
umschaltet. Wenn man einen Avr zum schalten  nimmt ist das genauso.

Mit dem Widerstand schaltet der sofort um.

Mir ist noch nie die "Antwort" eines Busteilnehmers entgangen der 
antwortet nach wenigen ms.

gruss Jochen

Rs485-hausbus.de.vu

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sascha

>Also wenn ich euch und eure teils kontroversen Meinungen richtig
>verstehe, dann sollte meine Schaltung prinzipiell funktionieren. Wenn

Ja.

>beim Schnittstellen-Zugriff über die Windows API Timing-Probleme
>auftauchene, dann muss ich mir eben doch die "Last" eines
>Kernel-Mode-Treibers aufladen.

Ja.

@Jochen S.

>signal umsetzt, von +-12v auf 5 bzw 0 v und dann braucht man denoch
>einen R der mir den DE auf masse zieht weil er sonst nicht gescheit
>umschaltet. Wenn man einen Avr zum schalten  nimmt ist das genauso.

Du sprichst in Rätseln. Wozu soll ich an DE nochmal nen Pull-down 
dranmachen, wenn DE und RE verbunden sind und von einem ordentlichen 
Digitalausgang (vom MAX232) gesteuert werden?

>Mir ist noch nie die "Antwort" eines Busteilnehmers entgangen der
>antwortet nach wenigen ms.

Das sind ja auch Ewigkeiten. Auf nem AVR bzw. mittels Kernal Driver kann 
man wenige Microsekunden nachdem das letzte Byte gesendet wurde den 
Treiber abschalten.

MFG
Falk

Autor: Jochen S. (jochen_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Falk: Um ehrlich zu sein am Anfang habe ich mir das auch gedacht, 
musste dann aber feststellen es ging nicht. Dann habe ich 
rumexperimentiert und habe zur Kontrolle eine LED zwischen DE und GND 
geschaltet und siehe da schon lief die Musik, da der DE über die LED auf 
Masse ging: LED weg Problem wieder da. Ich dachte auch immer das mir der 
MAX232 eine saubere Null liefern würde aber habe das Gefühl er lässt den 
Ausgang einfach in der Luft hängen.

Autor: Falk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jochen S.

>Masse ging: LED weg Problem wieder da. Ich dachte auch immer das mir der
>MAX232 eine saubere Null liefern würde aber habe das Gefühl er lässt den
>Ausgang einfach in der Luft hängen.

Welcher Ausgang? MAX defekt? Die Ausgänge vom TTL MAX232 sind keine Open 
Drain (und gerader der müsste ein sauberes LOW liefern). Ich tippe auf 
defekten IC oder Verdrahtung.

MfG
Falk

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Falk:

Das sehe ich genauso. Der MAX232 hat Push-Pull-Ausgang, der zu jedem 
Logikpegel sauber und schnell durchschaltet.

@Severino:

Klar kann ich meine Monoflop-Lösung hier posten, nur nicht sofort, da 
ich die Schaltung nur als Schmierzettel-Handskizze habe (und sie davon 
auf ein Veroboard verdrahtet habe), die ist z.Zt. nicht reprofähig. Ich 
werde sie mit Tippex etwas verschönern und dann scannen und stelle sie 
dann hier rein.

Aber die Schaltung ist sehr einfach: nach üblicher Manier sind ein 
MAX232 und ein MAX487CPA miteinander verbunden (Pin 11 des MAX232 mit 
Pin 1 des MAX487, dazu ein Pullup von 10k, sowie Pin 12 des MAX232 mit 
Pin 4 des MAX487), RE und DE verbunden = Pins 2 und 3, nur eben diese 
nicht an RTS gelegt, sondern mit dem Ausgang eines Monoflops CD4528 
verbunden (Q-Ausgang, Pin 10). Der A-Eingang (Pin 12) liegt an GND, der 
B-Eingang (Pin 11) ist mit dem Receive-Ausgang des MAX232 (Pin 12) 
verbunden. Das ist schon der ganze Witz.

Die kleine Schwierigkeit liegt in der Timeout-Zeit des Monoflops; hier 
habe ich ein 4-poliges Mäuseklavier (für 4 einstellbare Baudraten 9600, 
38400, 57600 und 115200 bps) zum Umschalten; dieses schaltet 
RC-Kombinationen an den CD4528; der Widerstand ist immer ein Fest-R mit 
3.3k und ein Poti mit 10k in Serie und wechselnde Kondensatoren (also 
insgesamt 4 * 3.3k und 4 * 10k-Poti und 4 Kondensatoren):

9600 bps:     C = 470 nF   Timeout 1,56 ms    Bit-Zeit 104,16 us
38400 bps:    C = 150 nF   Timeout 390 us     Bit-Zeit 26,05 us
57600 bps:    C = 100 nF   Timeout 260 us     Bit-Zeit 17,37 us
115200 bps:   C = 33 nF    Timeout 130 us     Bit-Zeit 8,68 us

Beim Protokoll 8-E-1 hat ein Zeichen 11 Bits, ich habe mich für eine 
Timeoutzeit von 15 Bitzeiten entschieden (könnte man noch etwas kleiner 
machen, aber: Temperaturdrift u.ä. beachten, besser ein wenig Toleranz 
lassen).

Den Poti-Abgleich für jede Baudrate macht man mit dem Oszilloskop; den 
Mono mit einer Rechteck niedriger Frequenz triggern und die Eigenzeit 
auf die genannten Timeouts einstellen.

So müßte es gelingen. Schaltung folgt irgendwann (aber nach der 
Beschreibung kannst Du's ja eigentlich aufbauen).

Günter

Autor: Jochen S. (jochen_s)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist doch eine verfeinerte Version aus einer alten elektor, da war 
das genauso, ich konnte mir nur nie vorstellen, dass das läuft hatte 
immer Angst das erste bit geht verloren, da der MAx485 oder welcher auch 
immer erst auf senden schaltet wenn das erste bit kommt. Muss hier im 
Protokoll was geändert werden so erst eine bit schicken zum umschalten 
dann eigentliche Nachricht oder klappt das so??

Autor: Severino (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Günter

Vielen Dank für die Beschreibung. Alles klar, Du brauchst für mich kein 
Schema zu posten.

Ich schaue jetzt mal, ob sich das für meine Zwecke verwenden lässt.

Nochmals besten Dank

Severino

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jochen:

Das klappt schon; der Treiber wird ja innerhalb von Nanosekunden 
eingeschaltet, da fängt das Startbit ja gerade erst an; am Protokoll muß 
man nichts ändern. Interessant, daß es dies im Elektor gab; ich habe den 
Elektor, habe mir die o.g. Schaltung aber selbst zusammengezimmert; sie 
ist ja auch relativ trivial, da braucht's nicht viel.

Autor: Günter R. (galileo14)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
@Severino:

Hab' meine Handskizze jetzt doch mal gescannt; sieht gekritzelt aus (ist 
sie ja auch), aber ich denke, man erkennt, wie die Schaltung aufgebaut 
ist.

Autor: Günter R. (galileo14)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
... und noch ein Foto dazu.

Autor: Sebastian E. (der_andere_sebastian)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Zwar ist der Thread schon etwas betagt, aber ich hoffe, das macht 
nichts.

Ich habe den monoflop-basierten RS232-RS485 Wandler laut Schaltung von 
Günter R. (in diesem Diskussionsfaden zu finden) nachgebaut. Mein 
Timing-Kondensator ist jedoch 1000 nF (Tantal), da ich primär niedrige 
Baudraten benötige.

Das Problem sieht man im Anhang: Ähnlich wie schon von Jochen S. 
befürchtet, geht mir bereits bei 2400 Baud ungefähr das halbe Startbit 
verloren.
An 9600 ist da gar nicht mehr zu denken.

(gelb: RS232-TX nach Pegelwandler am DI Pin des MAX485, grün: 
RE/DE-Signal)

Ist eine solche Verzögerung beim Triggern des Monoflop (MC14528BCP) 
normal? Oder sind die 1uF-Kondensatoren schuld?

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sebastian E. (der_andere_sebastian)

>Das Problem sieht man im Anhang: Ähnlich wie schon von Jochen S.
>befürchtet, geht mir bereits bei 2400 Baud ungefähr das halbe Startbit
>verloren.
>An 9600 ist da gar nicht mehr zu denken.

Da ist was faul.

>Ist eine solche Verzögerung beim Triggern des Monoflop (MC14528BCP)
>normal? Oder sind die 1uF-Kondensatoren schuld?

Wahrscheinlich. Mach mal lieber 10 nF (NANO) und dafür den Widerstnad um 
den Faktor 100 grösser.

MFG
Falk

Autor: Sebastian E. (der_andere_sebastian)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Tip. Die Richtung stimmt, schon mit 47nF ist das Problem 
praktisch gelöst. Leider sind mir eben nacheinander schon vier SP232 
kaputt gegangen, aber ich glaube nicht, daß der Kondenastor daran schuld 
ist. Vermute eher Latch-Up beim Einschalten oder so etwas.

Autor: Sebastian E. (der_andere_sebastian)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag: Alles ok, das angehängte Bild zeigt nun das Signal bei 2400 
Baud, Verzögerungszeit des MF nach Augenmaß abgeglichen.
Da die Flanken am Anfang der Signale jetzt praktisch zusammenfallen, 
sollte auch ein Betrieb bei höheren Baudraten möglich sein. 
Offensichtlich war der Tantalkondensator zu hochohmig, oder 1uF eben 
einfach zu viel.

Nebenbei gesagt habe ich jetzt einen MAX202 eingesetzt. Der scheint 
unempfindlicher zu sein.

Vielen Dank nochmal für die schnelle Hilfe.

Autor: Günter R. (galileo14)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sebastian E. wrote:
> Das Problem sieht man im Anhang: Ähnlich wie schon von Jochen S.
> befürchtet, geht mir bereits bei 2400 Baud ungefähr das halbe Startbit
> verloren.
> An 9600 ist da gar nicht mehr zu denken.

Hast Du beachtet, daß meine Schaltung baudraten-abhängig ist und man für 
jede Baudrate einen genau abgestimmten Kondensator und die 
Trimmereinstellung benötigt? Deswegen gibt es ja den DIP-Schalter, mit 
dem man 4 verschiedene Baudraten auswählen kann. Diese Schaltung 
funktioniert bestens, ist aber unkomfortabel, weil man ggf. die Baudrate 
umstellen muß; läßt sich aber nicht (!) vermeiden.

Eine bessere Lösung für PC-Anwendungen ist ein USB/RS485-Wandler mit 
einem FT232RL; dieser hat einen RS485-TxE-Ausgang, mit dem der Treiber 
gesteuert werden kann. Aber an diesem Chip wird die Baudrate letztlich 
(über den UART) auch eingestellt.

Meine Schaltung brauchte ich als Nachsetzer für ein Nicht-PC-Gerät, bei 
dem keine Eingriffe möglich waren.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Günter R. (galileo14)

>jede Baudrate einen genau abgestimmten Kondensator und die
>Trimmereinstellung benötigt?

Schon klar, es geht aber um die Verzögerung des Monoflopausgangs, NICHT 
die Pulsbreite.
Und mehr als 100us sind da viel zu viel.

MFg
Falk

P.S. Das mit dem Trimmer ist überflüssig. Es reicht praktisch, wenn die 
Pulszeit vom Monoflop ca. 15 Bitzeiten lang ist +/- 20%. Mit 1% 
Metallfilmwiderständen und 10% Folien/Keramik-kondensatoren schaft man 
das problemlos.

Beitrag "Re: RS-485 erweitern"

Autor: Sebastian E. (der_andere_sebastian)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, klar. Deswegen habe ich auch dieses Konzept übernommen, jedoch nur 
mit einem Jumper zum Umstecken und 2 R/C-Kombinationen. Ich brauche 
bestenfalls 1200 und 2400 Baud.

Ich wußte ja gar nicht, daß der FT232RL einen passenden Steuerausgang 
hat. Und der muß nicht extra per Software gesteuert werden? Das wäre 
langfristig eine Lösung für mich, da ich auf dem PC eine fertige 
MODBUS-Master-Software benutze, die die RTS-Leitung nicht steuert.

Danke übrigens für die Schaltung! Um auch etwas beizutragen, würde ich 
auf Wunsch die Eagle-Dateien dazu einstellen. Allerdings braucht mein 
Layout vier Drahtbrücken.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Sebastian E. (der_andere_sebastian)

>Ich wußte ja gar nicht, daß der FT232RL einen passenden Steuerausgang
>hat.

Hat er, sogar standardmässig aktiviert.

> Und der muß nicht extra per Software gesteuert werden?

Nein.

>Danke übrigens für die Schaltung! Um auch etwas beizutragen, würde ich
>auf Wunsch die Eagle-Dateien dazu einstellen.

Tu das.

> Allerdings braucht mein Layout vier Drahtbrücken.

Werden wir verschmerrzen können ;-)

MFG
Falk

Autor: Sebastian E. (der_andere_sebastian)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Bitteschön. Die vier Leitungen im Top-Layer können natürlich als 
Drahtbrücken ausgeführt werden. Bohrerdurchmesser 0,6 für normale 
Bauteile empfohlen, 0,8 für Jumper und 0,95 für die 
Wago-Federkraftklemme.
Sicherlich kann man das Layout noch wesentlich verbessern. Aber für eine 
kleine Testschaltung reicht es.

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.