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?
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 :-(
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.
@ 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
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....
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.
Schubs. Keiner von den Millionen Lindy-Nutzern hier? Im Moment interessiert mich nur noch das Echo-Problem.
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
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.
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
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)
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
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
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.
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.