Wiedermal RS485-Problem.

[H.Joachim S. (crazyhorse)]

Ich denke inzwischen, dass es am USB-Converter liegt

http://www.lindy.de/usb-rs485-konverter/42845.html

Halte ich an meinem Gerät den Treiber dauerhaft auf Senden, funktioniert 
es problemlos. Aber das ist ja nun mal nicht Sinn der RS485...
UART läuft im Interrupt, hab das Problem mal eingeengt, so tritt der 
Fehler genauso auch auf

RS485_direction=RECEIVE;
while (1)
      {delay_ms (100);
       printf ("\r\nTest%d", CANSendTimer);
       while (tx_counter);
       delay_ms(1);
       RS485_direction=RECEIVE;
       }
RS485_direction=SEND wird in der putchar-Routine gesetzt. Klappt auch, 
0x0D und 0x0A kommen ja.
Das Problem ist das Ende der Übertragung, dort kommt ein 0x00 dazu, 
woher auch immer. Baudrate, Datenbits, parity stimmen.
Wie gesagt, vor lauter Verzweiflung hatte ich die ganze 
Richtungssteuerung komplett raus geschmissen (dauerhaft auf Senden), 
null problemo. Kommt also irgendwie von der Umschaltung.
Ist ein MAX485, RE und TE gemeinsam an einem Portpin.
Ich habe keine Idee mehr, hat schon mal jemand diesen Konverter 
eingesetzt?

[H.Joachim S. (crazyhorse)]

Hm...
Noch einen MAX485 an den Bus gehängt, hört nur. Den Receiver auf nen 
MAX232 und diesen auf ne richtige COM-Schnittstelle, zweites 
Terminalfenster -> alles gut.
Damit steht nun der Konverter als Übeltäter fest :-(

[Purzel H. (hacky)]

Naja. Nicht wirklich. eher mangelndes Verstaendnis fuer die Vorgaenge. 
Der Konverter wird ein "ok" zurueckgeben bevor das Zeug wirklich 
draussen ist, dann wird umgeschaltet, und die Meldung somit abgewuergt.

[Falk B. (falk)]

@  H.joachim Seifert (crazyhorse)

>Ich denke inzwischen, dass es am USB-Converter liegt

Heute schon mal beim Arzt gewesen? Latenter Autismus oder so?
Kleiner Tipp: Netiquette.

>UART läuft im Interrupt, hab das Problem mal eingeengt, so tritt der
>Fehler genauso auch auf

>       while (tx_counter);
>       delay_ms(1);
>       RS485_direction=RECEIVE;

Ist tx_counter als volatile definiert? Siehe Interrupt

Das delay_ms(1) reicht max. für 1 Zeichen bei 9600 Baud. Wie schnell 
sendest du? Mit 57k6. Reicht also.

>Das Problem ist das Ende der Übertragung, dort kommt ein 0x00 dazu,
>woher auch immer.

Das liegt auch an deiner fehlenden/falschen Terminierung. Wenn man UART 
über RS485 betreibt, sollte man A unsd B vom Bus jeweils mit 390Ohm..1K 
gegen Vcc (A) und GND(B) ziehen. Damit ein High bei inaktivem Bus stehen 
bleibt.

>Ich habe keine Idee mehr, hat schon mal jemand diesen Konverter
>eingesetzt?

Millonen haben das.

MfG
Falk

[H.Joachim S. (crazyhorse)]

Boh, ist ja der Wahnsinn - vielen Dank für die Freundlichkeit....
@Langer Tag: was du da schreibst - ich versteh kein Wort davon. Könnte 
sein, das liegt an mangelndem Inhalt.

@Falk: Das Thema Netiquette solltest du dir selbst viellecht auch mal 
gründlich reinziehen...
Die 1ms ist nur dafür da, das letzte Zeichen auch wirklich zu senden, 
bevor der Transmitter abgewürgt wird, in der Originalsoftware geschieht 
das durch den Tx-complete-Interrupt. Aber es war ja auf jeden Fall 
ausreichend.
Terminierung nach + und Masse hatte ich drin mit 470R, nachdem das alles 
nichts so funktioniert hat wie gewollt.

Und jetzt die Lösung: Hab das Mistding ausgetauscht - läuft. Waren beide 
nagelneu....

[H.Joachim S. (crazyhorse)]

Jetzt wirds ganz verrückt....
Das Ding schickt ein Echo, selbst wenn gar nichts weiter am SUBD-Stecker 
dran dran ist???
Der eine Konverter liefert brav Zeichen für Zeichen das korrekte Echo, 
der andere hängt jedesmal noch ein Null-Byte an.
Also ich sende ABC, es kommt A<0>B<0>C<0> ..., verwirrend.
Haben die CAN-Treiber verbaut und ich muss mich ums Echo selber 
kümmern?? Kann ich mir nicht vorstellen.

Hat evtl. jemand so ein Teil von Lindy?

PS: Konsequenterweise leuchten auch Rx und Tx, wenn ich vom Terminal aus 
was auf den Wandler schicke :-)
Bei Empfang über RS485 leuchtet nur Rx.

[H.Joachim S. (crazyhorse)]

Schubs.
Keiner von den Millionen Lindy-Nutzern hier?
Im Moment interessiert mich nur noch das Echo-Problem.

[fchk (Gast)]

Dein Problem ist eine Frage der Beschaltung des RS485-Transceivers.

Beispiel: MAX3485E (den hab ich hier gerade da)
Der hat einen TE (Transmit Enable) und einen /RE (invertierter Receive 
Enable). Wenn Du was senden willst, ziehst Du den TE hoch, sendest, und 
nachdem das letzte Zeichen raus ist (dafür schaut man dann im UART nach 
und macht kein delay(1), nich wahr?), nimmst Du den TE zurück. So weit, 
so gut.

Jetzt zum /RE. Da gibts zwei Möglichkeiten. Verbindest Du den mit TE, 
wird der Receiver automatisch abgeschaltet, wenn der Transmitter 
aktiviert wird. Du bekommst also kein Echo.
Läßt Du den /RE auf Gnd, empfängst Du alle Zeichen, die Du gesendet 
hast. Das ist eigentlich sinnvoll, damit Du feststellen kannst, ob da 
nicht zwischendurch ein anderer Busteilnehmer reingefunkt hat.

So viel zum Echo.

Dann nochmal zum Problem mit dem Transmit Enable. Es ist wichtig, daß 
der TE punktgenau nach dem Senden des letzten Bytes wieder zurückgesetzt 
wird, um den Bus freizumachen.
Dazu fragt man den UART ab. Beim AVR gibts dafür das Bit TXC im UCSRA - 
Transmit Complete. Das pollst Du gefälligst, und setzt dann Dein TE 
zurück.

HAKEN: Beim UART des PC gibt es so ein Bit nicht. Man kann dort nicht 
abfragen, ob der Sende-FIFO leer ist. Der PC-UART ist eigentlich auch 
nicht für RS485 gedacht. Viele Adapter nehmen eine Steuerleitung wie 
RTS, um TE anzusteuern, aber das ist eigentlich Pfusch.

Bei USB-Adaptern gibt es aber auch welche, die ein echtes TE-Signal für 
einen RS485-Transceiver ausgeben, z.B. den FTDI FT232R. Das TE heißt 
dort TXDEN und kann per EEPROM-Programmierung auf einen der CBUS-Pins 
gelegt werden.

Im Zweifelsfall baust Du Dir einen USB-Adapter aus FT232R und MAX3485E 
selber zusammen. Dann weißt Du, was da passiert.

fchk

[H.Joachim S. (crazyhorse)]

Danke schon mal.
Selber bauen kommt nicht in Frage, davon werden ziemlich viele 
benötigt...
RE und DE werden bei dem Teil von getrennten I/O des FT232BM gesteuert.
Insofern denke ich, dass es schon möglich sein sollte, das Echo auch 
abzuschalten.
Ich war auch nicht so glücklich mit der Installation des ganzen (der war 
direkt mit der schon vorhandenen eines RS232-Adapters zufrieden), fragt 
nicht nach der Handhabung des Rx.
Delay...steht auch weiter oben schon, das das mit dem TxC-Interrupt 
gemacht wird.
Prinzipiell könnte ich mit dem Echo leben - muss das dann aber in der 
Software berücksichtigen. Ich seh da aber massive Probleme auf mich 
zukommen, wenn sich das Teil mal so oder so verhält.
Deswegen such ich immer noch Leute, die so ein Gerät haben.
Auf MC-Seite habe ich kein Probleme, das ist alles sonnenklar.
Das ganze ist ein System zur Vernetzung von Pumpen. Da sollen 
Betriebsparameter eingestellt, Störmeldungen und geloggte 
Betriebszustände abgefragt werden. Das ganze läuft im Normalfall ohne 
PC, aber der soll natürlich auch angeschlossen  werden können.
Das Schlimmste bei der ganzen Sache: es lief schon im Prototypen-Status 
mit CAN. Und dann haben die Kaufleute zugeschlagen und sich an den 2-3€ 
pro Pumpe für CAN-Controller/Transceiver aufgegeilt. Ok, CAN für PC ist 
auch etwas teurer als RS485. Eh die Zusatzkosten für die 
Softwareumstrickerei auf RS485 wieder eingespart ist, müssen die schon 
ne Menge davon verkaufen. Aber ok, das ist akzeptiert worden.

[fchk (Gast)]

Der FT232BM hat einen dedizierten Pin für TXDEN.

Hast Du mal die Programmierung der EEPROMS überprüft? Dafür gibts bei 
FTDI ein passendes Tool.

Sag mal: welcher Transceiver ist in dem Adapter, und an welchen Pins des 
FT232BM sind die TE und RE Pins angeschlossen? TE vom Transceiver müßte 
an Pin 16 (TXDEN) des FTDI angeschlossen sein. Stimmt das? Wo ist RE?

fchk

[H.Joachim S. (crazyhorse)]

RE hängt an Pin15, TE an Pin16.
Hab mich jetzt nicht weiter mit der Innenschaltung beschäftigt. Ist für 
mich ein Software/Treiberproblem.
Werd morgen mal die Leutchen von Lindy ein wenig nerven.
Dank dir auf alle Fälle.

Schon komisch, wie arrogant hier manche auftreten (und nur heisse Luft 
dahinter)

[Arc N. (arc)]

H.joachim Seifert schrieb:
> Danke schon mal.
> Selber bauen kommt nicht in Frage, davon werden ziemlich viele
> benötigt...

Die gibt's auch fertig von z.B. http://www.spectra.de (Art.Nr. 112887, 
war früher zumindest ein FTDI drauf) oder direkt von FTDI 
http://apple.clickandbuild.com/cnb/shop/ftdichip?op=catalogue-products-null&prodCategoryID=78&title=USB-RS485 
bzw. http://www.ftdichip.com/Products/EvaluationKits/USB-RS485.htm

[fchk (Gast)]

Pin 15 ist /PWREN.

"Goes Low after the device is confi gured via USB, then high during USB 
suspend. Can be used to control power to external logic using a 
P-Channel Logic Level MOSFET switch. Enable the Interface Pull-Down 
Option in EEPROM when using the PWREN# pin in this way."

Daß da Echos kommen, wundert mich nicht.

Wie gesagt, lade mal das FT_PROG runter und schau, ob sich die Adapter 
in der Programmierung unterscheiden.

http://www.ftdichip.com/Resources/Utilities/FT_PROG%20v1.3.1.zip

[H.Joachim S. (crazyhorse)]

EEprom sieht gleich aus, bis auf die Seriennummer. Das letzte Byte 
dürfte die Checksumme sein, also auch i.O. wenn die sich da 
unterscheiden.
Der linke ist der, der immer noch ein Nullbyte hinten dran hängt.

Den schick ich jetzt zurück, bei Lindy weiss keiner was über das Echo 
:-), weder ob es da sein soll oder nicht noch wie man das evtl. selbst 
einstellt.
Dann mach ich jetzt erst mal weiter und lebe mit dem Echo.