Hallo Leute, kurze Vorgeschichte: Ich wurde mit etwas beauftragt, von dem ich leider so ziemlich 0 Ahnung habe. Bin auch gerade erst aus dem Studium (Mikrosystemtechnik) raus und wurde jetzt direkt ins kalte Wasser geworfen. Es geht um ein Gerät, das für bestimmte Steueraufgaben zuständig ist, z.b. elektrische Magnetventile ansteuern. Zur Kommunikation besitzt dieser Controller einen CAN-Bus. Ich soll nun prüfen ob und wie ich diese CAN-Bus Schnittstelle möglichst einfach und wenn möglich auch kostengünstig auf eine RS485 Schnittstelle umrüsten kann...(einige Kunden hätten das wohl gerne so). Ich soll einfach nur schauen auf welche verschiedenen Arten das möglich ist und inwiefern das realisierbar ist, ich hab aber nur sehr wenig Ahnung von Bussystemen, nie im Studium gehabt. Ich hab schon Konverter von CAN <-> RS485 gefunden, diese sind aber wohl für große Stückzahlen viel zu teuer... Gibts vielleicht auch günstige irgendwo ? Mein Vorgesetzter meinte, dass man evtl auch einfach den CAN-Bus Treiber mit nem RS485 Treiber ersetzen könnte und das dann mit wenig Aufwand zum Laufen kriegen kann, weil das hardwaretechnisch sehr ähnlich ist ?! Ich wäre jedem dankbar, der mir da auch nur irgendwelche hilfreichen Tipps geben könnte. Würde mir sogar reichen wenn ihr mir sagen könntet, wie ich darauf kommen kann wie und ob das möglich ist ! (Wiki Bussysteme hab ich schon alles gelesen, hilft mir nich wirklich...) Danke !
*Gast* schrieb: > Mein Vorgesetzter meinte, dass man evtl auch einfach den CAN-Bus Treiber > mit nem RS485 Treiber ersetzen könnte und das dann mit wenig Aufwand zum > Laufen kriegen kann, weil das hardwaretechnisch sehr ähnlich ist ?! Was der Vorgesetzte alles so meint..... Dein Controller muss dafuer aber auch einen UART haben wo man den RS485 Treiber anschliessen kann, die CAN Anschluesse dafuer zu nutzen geht nicht. Dann muss 2. dafuer auch Software geschrieben werden vorallen muss man sich auf ein Protokoll bei der RS485 Schnittstelle einigen da ist naemlich ausser den Pegeln nichts genormt.
Du musst mal schauen was du für einen Treiber Baustein hast, Und ob der überhaupt hardware maßig geeignet ist Dann ist noch die Frage: Half Duplex / Full Duplex Wenn der Baustein Hardware Mäßig geeignet ist. Dann muss du nur noch das Protokoll anpassen damit es die eigenschaften Von der Rs485 Dein Chef hat schon recht,sind schon ähnlich, aber ob es passt ist wieder eine andere Geschichte. Gru?, Matthias K.
Helmut Lenzen schrieb: > Dann muss 2. dafuer auch Software geschrieben werden vorallen muss man > sich auf ein Protokoll bei der RS485 Schnittstelle einigen da ist > naemlich ausser den Pegeln nichts genormt. Ja, um die Software muss ich mir zum Glück keine Gedanken machen... Da würde sich die Software-Abteilung drum kümmern. Und genau die hat halt angefragt, ob das machbar ist bzw. wie. Die haben nämlich hardwaremäßig keine Ahnung...ich nur leider in dem Fall auch nicht. Da wurde ich jetzt drauf angesetzt 3 Lösungen zu finden, qualitativ sowie preislich top, mittel und ausreichend. Mikrocontroller bzw. UART sind auf dem Controller enthalten. Ich habe hier eine RS485 Interface Modul gefunden (siehe Link), wäre diese kleine Platine geeignet, wenn Software und Protokoll angepasst werden ? http://www.modtronix.com.au/product_info.php?cPath=107_176&products_id=355 Was gibt es denn allgemein für Möglichkeiten eine CAN Schnittstelle auf RS485 umzurüsten ? - Also Software und Protokoll müssen auf jeden Fall angepasst werden, richtig ? - Was muss noch auf jeden Fall gemacht werden ? Danke Euch erstmal ! Echt ätzend wenn man wirklich keine Ahnung von einem Thema hat...
Wie sieht denn die Lösung für das ACK aus, welches der CAN-Master direkt vom CAN-Slave erwartet? Die Übertragung des Signals über Deine RS485-Schnittstelle verzögert ja die direkte Antwort von Deinem CAN-Slave.
*Gast* schrieb: > Was gibt es denn allgemein für Möglichkeiten eine CAN Schnittstelle auf > RS485 umzurüsten ? Sinnvolle? Keine! Das einzige, was Sinn macht, wäre neben den CAN Transceiver (am an einem µC-internen oder externen CAN-Controller hängt) einen RS485-Transceiver auf die Platine zu pappen und diesen dann an den UART des µC anzuschließen. Noch eine Leitung für RX/TX-Umschaltung (falls das der UART nicht sogar selbst kann) und den Rest darf die Softwareabteilung erledigen. Für Dich bedeutet das: - RS485-Basics aneignen (z.B. http://de.wikipedia.org/wiki/RS485) - Datenblatt des µC lesen - Datenblatt eines RS485-Transceivers Deiner Wahl lesen (im Zweifelsfall MAX485) - drei Leitungen vom µC zum Transceiver legen Kostet n Euro für den Transceiver plus den gewünschten Stecker nach außen und einen beliebig großen Aufwand in der SW-Abteilung.
oder ... man nehme nen kleinen CAN-µC und hänge den zwischen 485 und CAN als Knoten ... natürlich inklusive Schnittstellenbausteine. Dann hätte der "nur" die Aufgabe wechselseitig die Protokolle zu übersetzen und durchzureichen. wäre zwar etwas teurer, dafür könnten bestehende Anlagen nachgerüstet werden und man hätte keine Großbaustelle aufzumachen. Mit einfach die Bustreiber aneinanderpappen wird nichts, weil RS485 normalerweise über die UART geht, also 8n1 9n1 etc.. Du müßtest bei den Slaves dann quasi nie Software-CAN schreiben ... so du Zugriff auf die darin laufende Software hast. Das ginge aber auch nur im Pollingbetrieb ... musst halt schauen ob das mit den Latenzen hinhaut ..., wenn das nach dem Schema CAN, wir schreien einfach hinaus und stören uns nicht drum ob da wer was mit anfangen kann, laufen soll, dann wirds n Busmaster ...
Martin schrieb: > > Das einzige, was Sinn macht, wäre neben den CAN Transceiver (am an einem > µC-internen oder externen CAN-Controller hängt) einen RS485-Transceiver > auf die Platine zu pappen und diesen dann an den UART des µC > anzuschließen. Noch eine Leitung für RX/TX-Umschaltung (falls das der > UART nicht sogar selbst kann) und den Rest darf die Softwareabteilung > erledigen. Ok, super ! Es würde deiner Meinung nach also mehr Sinn machen (preislich und vom soft-und hardwaretechnischem Aufwand) den CAN Transceiver einfach drauf zu lassen und zusätzlich nen RS 485 Transceiver drauf zu löten anstatt ihn zu ersetzen ? Soweit ich weiß gehört da ja auch immer noch ne kleine Schutzschaltung drum rum, die sich aber von CAN und RS 485 laut meinem Vorgesetzten kaum unterscheiden soll ?! Gibt es sonst noch Möglichkeiten das zu realisieren, auch wenns vielleicht nicht sinnvoll ist, um Alternativen anbieten zu können ? Ich hab wie gesagt schon Konverter gefunden, die aber n arsch voll Geld kosten..
Damit ist immer noch nicht geklärt, die die ACK's übertragen werden. Außerdem kann RS485 nicht so mit Kollisionen umgehen, wie es von CAN Protokoll erfordert wird. Das CAN Protokoll harmoniert nicht mit den elektrischen Eigenschaften von RS485.
Fhutdhb Ufzjjuz schrieb: > oder ... man nehme nen kleinen CAN-µC und hänge den zwischen 485 und CAN > als Knoten ... natürlich inklusive Schnittstellenbausteine. > Dann hätte der "nur" die Aufgabe wechselseitig die Protokolle zu > übersetzen und durchzureichen. wäre zwar etwas teurer, dafür könnten > bestehende Anlagen nachgerüstet werden und man hätte keine Großbaustelle > aufzumachen. Ok, das klingt auch interessant ! Da bräucht ich als Laie aber noch n paar anfängerfreundliche Infos. Also CAN Tranceiver etc. bleibt alles drauf ? Zusätzlich dann RS 485 Transceiver drauf und zwischen die beiden dann einen CAN-µC ? Was kostet sowas denn ? bzw. hättest du mal einen Link für einen solchen IC ? Und was für Schnittstellenbausteine braucht man dazu dann noch ? Das ganze soll nämlich auch keine Großbaustelle werden, von daher klingt das auch sehr vernünftig !
Stefan schrieb: > Damit ist immer noch nicht geklärt, die die ACK's übertragen werden. > Das CAN Protokoll harmoniert nicht mit den elektrischen Eigenschaften > von RS485. Davon hab ich leider 0 Ahnung, würd ich dir sonst gerne beantworten... Ich hatte gehofft, dass sich damit die Softwareabteilung auseinandersetzen muss. Ich will/muss denen nur hardwaretechnische Lösungen anbieten und dann wird geguckt ob sich der Aufwand lohnt, eine dieser Lösungen einzusetzen.
*Gast* schrieb: > Zur Kommunikation besitzt dieser Controller einen CAN-Bus. Dann besitzt er in der Regel auch eine UART. An diese kommt dann der RS-485 Transceiver (MAX485).
CAN und RS485 sind einfach zwei Paar Schuhe... Hardwaremäßig sind beide zwar sehr einfach gestrickt, aber auf der Protokoll-/Softwareseite steckt das Know-How. Einfach CAN-Transceiver runter und den für RS485 an dessen Stelle drauflöten mach zwar mechanisch gehen, ist aber Blödsinn. Also muss auf der Platine beides vorgesehen werden. Ob jetzt beides bestückt wird oder nur eine Variante, müsst Ihr einfach durchkalkulieren - je nach Stückzahl und Handling kann es durchaus günstiger sein, beides zu bestücken. Bei der Software müsste "nur" ein RS485-Interface mit einem zu definierendem Protokoll implementiert werden. Ein "Umsetzer" RS485-CAN ist natürlich auch möglich, aber deutlich aufwändiger. Einmal ist es zusätzliche Hardware mit einem eigenen µC. Zudem muss eine komplette Software dafür entwickelt werden mit dem o.g. RS485-Interface, der Gegenstelle für Euer bisheriges CAN-Interface und allem was sonst noch so dazu gehört.
> Davon hab ich leider 0 Ahnung, würd ich dir sonst gerne beantworten... > Ich hatte gehofft, dass sich damit die Softwareabteilung auseinandersetzen muss. Na dann könnt ihr die Aufgabe (noch) nicht lösen. Denn ein RS485 Bus ist einfach ungeeignet, um darauf das CAN Protokoll zu fahren. Frage bei den Softwareentwicklern nach, ob sie die Busteilnehmer so umprogrammieren können, dass sie RS485 nutzen können. Das heisst letztendlich, es wird nicht mehr CAN genutzt. Dazu müssen sie natürlich die elektrischen Eigenschaften und Unterschiede dieser beiden Busse verstehen.
Stefan schrieb: > Na dann könnt ihr die Aufgabe (noch) nicht lösen. Denn ein RS485 Bus ist > einfach ungeeignet, um darauf das CAN Protokoll zu fahren. Frage bei den > Softwareentwicklern nach, ob sie die Busteilnehmer so umprogrammieren > können, dass sie RS485 nutzen können. Das heisst letztendlich, es wird > nicht mehr CAN genutzt. Dazu müssen sie natürlich die elektrischen > Eigenschaften und Unterschiede dieser beiden Busse verstehen. Ja, CAN soll oder muss auch nicht mehr ge oder benutzt werden. Dafür soll halt RS485 rein. Aber danke erstmal für all eure Antworten. Ich werd mal schauen inwieweit ich damit vorran komme ;)
Ok, dann wird's warscheinlich einfach. Prüfe nach, ob die CAN Geräte Leitungen für die "Rohdaten" haben, als RxD und TxD mit Logik-Pegel von einem UART. Da kannst Du nämlich ganz einfach RS485 Transceiver anschließen. Du brauchst dann noch eine Steuerleitung, mit der Du die Sender Ein/Aus schaltest, denn nur ein Busteilnehmer darf zum selben Zeitpunkt senden.
Stefan schrieb: > Ok, dann wird's warscheinlich einfach. Prüfe nach, ob die CAN Geräte > Leitungen für die "Rohdaten" haben, als RxD und TxD mit Logik-Pegel von > einem UART. Da kannst Du nämlich ganz einfach RS485 Transceiver > anschließen. > > Du brauchst dann noch eine Steuerleitung, mit der Du die Sender Ein/Aus > schaltest, denn nur ein Busteilnehmer darf zum selben Zeitpunkt senden. Aha ok, also eventuell doch eine einfache Geschichte. Also im Datenblatt zu dem Controller hier seh ich im Schaltplan, dass vom Prozessor 2 Leitungen mit CAN_TxD und CAN_RxD in den CAN Transceiver führen. Die meinst du denk ich mal ?? Die Steuerleitung muss dann was genau mit wem verbinden ?
Ja, die meine ich. Du brauchst eine Steuerleitung, mit der die Software den RS485 Sender aus/ein schalten kann. Also irgendeine Leitung, die frei ist und auf High und Low umschaltbar ist.
*Gast* schrieb: > Also im Datenblatt zu dem Controller hier seh ich im Schaltplan, dass > vom Prozessor 2 Leitungen mit CAN_TxD und CAN_RxD in den CAN Transceiver > führen. Die meinst du denk ich mal ?? Natürlich nicht! Was ist daran nicht zu verstehen, wenn man Dir sagt, daß CAN und RS485 völlig verschieden sind? Nochmal, Du kannst nur die UART verwenden für RS485. Vergiß CAN. Man könnte die CAN-Anschlüsse bestenfalls als GPIO verwenden und die UART in SW nachbilden. Aber dann werden Dir die Programmierer die Hucke voll hauen.
Warum sagst Du Deinem Chef eigentlich nicht, daß Du davon keine Ahnung hast? Kein Kreuz, oder was? Washast Du eigentlich ausgefressen, um solche Aufgaben zu bekommen?
was muss man eigentlich studiert haben um nichtmal annähernd Wikipedia oder Suchmaschine bedienen zu können um sich die Basics zu besorgen? Politikwissenschaften, oder? Nee alle Anschllüsse mit CAN im Namen kannst Du knicken, RX und TX sind die zu suchenden Kürzel im Datenblatt. Oder Du gibst mal die Bezeichnung von dem Ding preis.
Fhutdhb Ufzjjuz schrieb: > was muss man eigentlich studiert haben um nichtmal annähernd Wikipedia > oder Suchmaschine bedienen zu können um sich die Basics zu besorgen? > Politikwissenschaften, oder? Du weist doch man kann von den Naturwissenschaften in die Politik gehen wenn man dort nichts zu Stande gebracht hat umgekehrt geht das allerdings nicht :=)
Fhutdhb Ufzjjuz schrieb: > Mit einfach die Bustreiber aneinanderpappen wird nichts, weil RS485 > normalerweise über die UART geht, also 8n1 9n1 etc.. *Gast* schrieb: > Soweit ich weiß gehört da ja auch immer noch ne kleine Schutzschaltung > drum rum, die sich aber von CAN und RS 485 laut meinem Vorgesetzten kaum > unterscheiden soll ?! Stefan schrieb: > Das CAN Protokoll harmoniert nicht mit den elektrischen Eigenschaften > von RS485. Stefan schrieb: > Na dann könnt ihr die Aufgabe (noch) nicht lösen. Denn ein RS485 Bus ist > einfach ungeeignet, um darauf das CAN Protokoll zu fahren. Hier geht so einiges durcheinander. EIA-485 (oder RS-485) definiert nur eine physikalische Übertragungsschnittstelle (das Phaysical Layer im OSI-Modell). Welches Protokoll darüber gefahren wird, ob nun mit dem Uart 8N1 oder 9Nx oder Interbus oder CAN oder Ethernet ist der Schnittstelle völlig egal. Bei CAN ist das anders. Der Standard definiert die physikalische Schnittstelle (das Physical Layer) und die sog. Sicherungsschicht (Data Link Layer). In diesem ist schon das Übertragungsprotokoll mit Identifier, CRC usw. definiert und dieses ist in Hardware im Controller implementiert. Dem CAN-Contoller ist allerdings komplett egal, welche physikalische Schnittstelle dahinterhängt (es gibt ja auch schon Ein-Draht-CAN), diese sieht er nicht. Elektrische Eigenschaften und Protokoll haben also gar nichts miteinander zu tun. Aufgrund der im Data Link Layer definierten Kollisionserkennung und Verhinderung funktioniert CAN nicht mit einem Halb-Duplex RS-485-Bus. Zur Kollisionserkennung hört der CAN nämlich beim Senden auf dem Bus mit und hört sofort auf zu senden, wenn sich gesendete Nachricht und ankommende Nachricht unterscheiden. Aus diesem Grund kann man einen CAN nicht über einen Halb-Duplex RS-485-Bus fahren. Nähme man einen Voll-Duplex RS-485-Treiber mit Driver Enable und Receiver Enable und würde abgehende Schnittstelle am Treiber direkt mit der ankommenden Schnittstelle verbinden, könnte man auch das CAN-Protokoll über die physikalische Schnittstelle RS-485 fahren. Man bräuchte nur einen geeigneten Mechanismus, der das Driver-Enable-Signal bei einer Kollisionserkennung wegnimmt. Für den Fall des TE ist das aber auch ungeeignet, da man auf der Gegenstelle das Data Link Layer inklusive der maximal zulässigen Verzögerungszeiten in Software nachbilden müsste, was wohl eher unmöglich ist. Es bleibt also nur die Variante UART und RS-485 Treiber, alles andere wird nicht funktionieren.
> Man bräuchte nur einen geeigneten Mechanismus, der das > Driver-Enable-Signal bei einer Kollisionserkennung wegnimmt. CAN ist elektrisch so konzipiert, dass bei einer Kollision die nachricht mit der höchsten Priorität vorrang hat. Diese eine Nachricht ist bei der Kollision nicht korrumpiert, wohl aber alle anderen. Deswegen ist bei CAN keine wiederholung der höchst priorisierten Nachricht notwendig. Bei RS485 wäre eine Kollision ein Kurzschluss - alle Nachrichten werden korrumpiert. Aber der TO hat inzwischen geschrieben, dass die Busteilnehmer umprogrammiert werden können. Jetzt braucht er nur noch eine passende UART Schnittstelle und eine Sender-Enable Steuerleitung, dann kann er die CAN Schnittstelle durch eine RS485 Schnittstelle austauschen. Das protokoll werden die Softwareentwickler umschreiben.
Also, ich versuch das nochmal kurz zu erklären..ich hab tatsächlich was naturwissenschaftliches studiert, ich komm nich aus der politik. Aber einfach noch nie was mit Datenbussen-/Signalen etc. zu tun gehabt. Und natürlich hab ich auch google schon angeschmissen und versucht die verschiedenen Schnittstellen so halbwegs zu verstehen... Dazu fehlt mir da aber glaub ich einfach zu viel Hintergrundwissen. Von daher sorry an alle, die sich wegen meiner Unwissenheit beleidigt fühlen und die Hände übern Kopf zusammen schlagen ;) Ich will es wirklich verstehen. Nochmal zum Thema: Dieser Controller, der umgerüstet werden soll, hat zur Kommunikation mit externen Geräten ne Rs232 und ne CAN schnittstelle(pca82C251). Desweiteren besitzt er einen 32-bit µC(mb91f362ga von Fujitsu). RS232 soll drauf bleiben, CAN soll möglichst einfach und kostengünstig ersetzt werden mit RS485. Das muss ich letztendlich hardwaretechnisch nicht mal selber machen, wird von ner externen Firma gemacht. Dazu soll ich nun "einfach" 2-3 hardwaretechnische Lösungen angeben, wie man das machen könnte und was dat kosten würde. Dazu widerrum muss ich das erstmal halbwegs verstehen. Jetzt hab ich nochmal ein paar Fragen. Vielleicht is der ein oder ander so nett und versucht es mir näher zu bringen =) - Wie genau funktioniert das mit den Protokollen ? Ich dachte eigentlich die sind komplett softwaremäßig implementiert. Is das korrekt oder Bullshit ? - Desweiteren hätte ich gedacht, zur Lösung des ganzen Problems nehme man einfach einen RS485 Transceiver -> rauf auf den Controller -> ein paar nicht benutzte Datenleitungen vom µC zum Transceiver, die vorher softwaretechnisch so "programmiert" werden müssen, dass die richtigen Signale am Transceiver ankommen -> Transceiver ausgänge über Steckverbinder nach außen -> fertig ? (geht hierbei nur ums Prinzip, der CAN Transceiver wäre hier ja dann weiterhin noch drauf, der soll ja eigentlich runter vom Controller und ersetzt werden). jetzt dürft ihr wieder auf mich einschlagen ! und LOS !
Du hast RS232? perfekt! Dann brauchst Du nurnoch n paar Widerstände, Dioden und einen IO-Pin vom Controller + MAX485 oder ähnlich und fertig ist die Laube ... oder ist die RS232 nur zur Kommunikation mit dem PC? Neee, RS485 ist nur die elektrische Seite der Übertragung, das Protokoll, bzw. die Informationen die übertragen werden haben damit primär garnichts zu tun. Protokolle gibts viele, schau Dir mal Modbus oder Profibus an, Man kann sich aber auch selber was stricken und einfach Strings mit Start- und Endzeichen Byteweise übertragen. Checksummen und Datenformat sind bei RS485 nicht definiert. Das giht bis zu DMX, da werden einfach die Bytes nacheinander rausgefeuert ohne Checksumme oder Prüfung, nur Simplexverbindung. Bei RS485 muss Du Dich um alles selber kümmern, da ist CAN deutlich komfortabler, man haut seine Information in den CAN-Controller, der macht dann den Rest (vereinfacht). Oft wird aber einfach die UART mit ihrer byteweisen übertragung verwendet ... allerdings nicht immer. Da Du aber nicht weißt welche Sprache die RS485 sprechen soll ist die Diskussion ziemlich unnötig. Ist in etwa so, als würde der Männerchor ohne Dirigent singen, jeder ein anderes Lied und die, die zufällig das gleiche Lied singen dann unterschiedlich schnell ... Aus eigener schmerzlicher Erfahrung, hab mich bei ner Projektierung auch mal drauf eingelassen möglichst alle Kundenwünsche zu realisieren, kann ich nur davon abraten. Zumindest bei mir war es so, das die ganzen gewünschten Features (inklusive RS485-Bus, Funkübertragung, Infrarotdatenübertragung, zusätzliche Schaltausgänge) schlussendlich von niemand verwendet wurde. Wenn ich das heute nochmal zu machen hätte würde ich einfach n paar Stiftleisten vorsehen im Design und bei Bedarf dann die Funktionen steckbar machen. Hätt ich damals einfach an den Leiterplattenrand ne 3-polige Klemme gesetzt, Aussparung ins Gehäuse und n Schildchen mit A-B-GND dran gepappt wär genausogut gewesen wie den ganzen Mist draufzupacken.
*Gast* schrieb: > - Wie genau funktioniert das mit den Protokollen ? Ich dachte eigentlich > die sind komplett softwaremäßig implementiert. Is das korrekt oder > Bullshit ? > Teils/Teils, bei CAN ist schon ein Teil davon in Hardware gegossen und ein Teil wird in Software gemacht. Bei RS485 ist nur die serialisierung in Hardware (UART) das Protokoll ist komplett in Software zu machen. Nur gibt es bei RS485 kein genormtes Protokoll jeder kocht hier sein eigenes Sueppchen. > - Desweiteren hätte ich gedacht, zur Lösung des ganzen Problems nehme > man einfach einen RS485 Transceiver -> rauf auf den Controller -> ein > paar nicht benutzte Datenleitungen vom µC zum Transceiver, die vorher > softwaretechnisch so "programmiert" werden müssen, dass die richtigen > Signale am Transceiver ankommen -> Transceiver ausgänge über > Steckverbinder nach außen -> fertig ? (geht hierbei nur ums Prinzip, der > CAN Transceiver wäre hier ja dann weiterhin noch drauf, der soll ja > eigentlich runter vom Controller und ersetzt werden). > Das geht zwar im Prinzip aber dein Programmierer erschlaegt dich dabei. Hardwaremaessig sollte schon ein UART vorhanden sein. > jetzt dürft ihr wieder auf mich einschlagen ! > und LOS ! Dreht dich rum und sag AUA.
Was die Protokolle angeht, da hast Du schon Recht, das ist Software, allerdings mußt Du auch schauen ob Deine Schnittstelle vom Controller da auch kompatibel ist. Ein CAN-Datenframe ist: Start of Frame (SOF) = ein dominantes Bit Arbitrierungsfeld, bestehend aus einem Identifier-Segment (11 Bit oder 29+2 Bit) plus einem RTR-Bit (Remote Transmission Request, siehe unten) Kontrollfeld (CTRL) = 6 Bit Identifier Extension (IDE) = 1 Bit reserved = 1 Bit Data Length Code (DLC) = 4bit (Anzahl der Bytes im Datenfeld) Datenfeld (DATA) = 0–64 Bit (in Einheiten von 8 Bit) Prüfsummenfeld (CRC) = 16 Bit (15 Bit CRC plus einem rezessiven CRC-Delimiter-Bit) Bestätigungsfeld (ACK) 2 Bit, bestehend aus einem ACK-Slot plus einem rezessiven ACK-Delimiter End of Frame (EOF) 7 Bit (rezessiv) Intermission (IFS – Intermission Frame Space) = 3 Bit (= min. Anzahl der Bits, die aufeinanderfolgende Botschaften trennt) Wenn Du damit auf die UART , die mit Paritybit, also z.b. 9e1 maximal 10 Bit hintereinander empfangen kann, gehst dann hustet die Dir was. Umgekehrt kann der CAN-Controller mit 9e1 auch nix anfangen. Wenn Du z.B. vom CAN auf Modbus-ASCII gehen willst, dann musst du obige Daten übersetzten in: Start, 1 Zeichen (:) Adresse, 2 Zeichen Funktion, 2 Zeichen Daten, n Zeichen LR-Check, 2 Zeichen Ende, 2 Zeichen (CRLF) Das passt dann auch zur UART
Alles was ich bisher gelesen hab, sieht nicht nach einer kardinellen Lösung aus, sondern nach sehr viel Detailwissen, dass völlig zusammenhangslos beigetragen wird. Wenn ich also man ordnen darf. Eine einfach Lösung mit Hilfe einfacher Pegelwandler oder Bus-Transmitter wird aus vielerlei Gründen nicht funktionieren. Einige der Probleme sind ja bereits sehr detailiert angegangen; andere fanden bisher noch keine Beachtung. Mir fallen spontan auch einige elektrische Probleme in den Sinn, die ich auch gar nicht beitragen will, da sie nicht zur Lösung beitragen. Also, da hätten wir die Forderung, ein CAN-Bus Gerät an einer Party-Line a la RS485 anzukopplen. Es wird ohne Microcontrollereinsatz nicht funktionieren. Die Gründe dafür sind bereits detailgetreu beschrieben. Nun würde ich mal ganz scharf in der Bucht sehen, was dort bereits an fertiger Hardware angeboten wird. Spontan würde ich ein STM32F103-Board nutzen. STM32Fx-Discovery hat sogar einen JTAG/SWD Programmierer mit USB drauf der sogar sehr potent debuggen kann und das Ding ist richtig schnell und hat genug Programmspeicher und RAM um ein CAN-Knoten zu implementieren und dazu die Apassungen an das bestehende RS485-Netz vorzunehemen. Zum Discovery würde man noch zwei Pegelwandler/Bus-Koppler brauchen. Ich hab mir den MAX3232 und einen CAN-Bus Treiber a la SN65HVD230 als fertige Platinen in der Bucht besorgt. Die Dinger kosten bei "Waveshare" unter €10.- und lassen sich schnell ankoppeln. Das Ganze muss noch programmiert werden. Der Aufwand dafür hängt sehr von der Komplexität ab. Mit der CoIDE (kostenlose IDE) werden auch einige Beispiele geliefert. Ich benutze das Keil-MDK und baue mir gerade ein Messgerät dass an den CAN-Bus soll. Dafür kommen bei mir genau die beschriebenen Komponenten zu Einsatz. Ich sende bereits mit auf dem Can-Bus und die RS422 arbeitet mit 115200bps und kann alles vom und zum CAN-Bus hin und her schaufeln. Da beide verwendeten Protokolle zu meinen Geräten passen muss, wird dir meine Softwarelösung kaum helfen. Sie zeigt aber auf, dass sowas sehr gut machbar ist. Einige Dinge sind jedoch zu beachten. Wo Licht ist, gibts auch Schatten. Je nach dem wo das Zeug eingesetzt werden soll, muss natürlich auf die Isolation geachtet werden. Es gibt Anforderungen die zwingend eine Potentialtrennung vorschreiben. Der CAN ist im Gerät, aber was ist mit dem RS485-Feldbus? Könnte es sein dass er besonderen Schutz bedarf? Ich denke an Anwendungen wie ein Zeiterfassungssystem, dass diesen Bus gern mal benutzt. Dafür gibt es ebenfalls Bus-Koppler/Treiber die den geforderten Schutz bieten. Soweit so gut - die Hardware sollte beschaffbar sein. Die Software ist von beiden Protokollen und dessen Aufgabe abhängig. Ich glaube nicht, dass man ein RTOS einsetzen muss - wenn doch, kann man ein freies benutzen. CoOS habe ich schon probiert und es funktioniert auf einem Cortex-M3 sehr gut. Ein Cortex-M4F kann es offiziell noch nicht - liegt an der fehlenden FPU-Unterstzung. So, soviel erstmal - bitte lese doch nochmal den Thread durch um dir einen Eindruck zu verschaffen, auf was du dich da einlässt. Wenn es alternativlos ist, würde ich mal auf den STM32F4Discovery (Cortex-M4) setzten. Der kostet unter €20.- und ist gut erhältlich. Juppeck
Thread beobachten
Seitenaufteilung abschaltenBitte 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.