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
