Guten morgen allerseits. Ich komme quasi direkt aus dem Studium (Mikrosystemtechnik), Bussysteme haben wir da aber leider nur sehr grob angeschnitten. Nun soll ich mich zur Einarbeitung in meiner neuen Firma mit "Machbarkeitsstudien" beschäftigen. Und zur Zeit hänge ich da an folgendem Thema. Ein bereits vollständig entwickelter Controller zur Steuerung eines bestimmten Gerätes besitzt zur Kommunikation mit diesem Gerät CAN und RS232. Viele Kunden hätten anstatt CAN aber gerne RS485 zu Kommunikationszwecken. Ich soll also herausfinden, ob auf einfache und günstige Weise(n) statt des CAN Busses, der RS485 Bus umgesetzt werden kann. Der Mikrocontroller ist ein MB91FV362GA (208PIN). Am einfachsten wäre natürlich wenn ich den CAN Transceiver mit dem RS485 Transceiver tauschen könnte (selber Footprint). Aber ist das überhaupt möglich "CAN"-TXD und "CAN"-RXD mit dem RS485 Transceiver zu verbinden, indem man dann vielleicht softwareseitig die Signale anpasst ? Oder ist es zwingend notwendig RS485 mit der UART zu verbinden ? Pegelwandler von CAN nach RS485 hab ich bislang auch noch nicht gefunden. Ziel ist natürlich, dass das ganze möglichst einfach und kostengünstig von statten geht. Sogar Bastellösungen sind erlaubt a la Beinchen hoch"klappen" um sie dann mit dem richtigen Signal zu verbinden, falls die Pinbelegung nur minimal unterschiedlich ist. Letztendlich benötige ich einfach 1-3 machbare Lösungen, wie ich das ganze umsetzen könnte (nicht super detailliert!). Vielleicht könnt ihr mir da n kleinen Schubs in die richtige Richtung geben. Schon mal Danke im Vorraus !
Angehängte Dateien:
-
Blockschaltbild__C.PNG
12 KB
RS-232 und RS-485 benötigen eine UART. Wenn Dein MC 2 UARTs hat, geht das. Die CAN-Pins sind dann nutzlos.
die wesentlichen unterschiede liegen im übertragungsprotokoll, RS485 ist da ehr RS232, als CAN google: CAN-Frame, RS232
Ja, der µC hat sogar 3 UART I/O's. Es ist aber also schwachsinnig, die Transceiver 1:1 zu tauschen weil die Protokolle unterschiedlich sind, richtig ? Oder lässt sich das softwaremäßig anpassen ? Was wäre eurer Meinung nach die einfachste/beste Lösung ? Die Platine ist leider schon ziemlich mit Bauelementen vollgeschustert. Viel Platz ist da nich mehr...höchstens ne Etage höher..
Wenn es nur um den physikalische Layer geht, kannst du tatsächlich erfolgreich einen RS485-Transciever am klassischen 2-Draht CAN betreiben. In den CAN-Anfängen hat man das auch tatsächlich so gemacht, da gab es noch keine speziellen CAN-Transciever. Das fand früher bei kleinen CAN-Inseln, z.B. bei industriellen Spezialmaschinen, auch Anwendung. Ich würde das aber heute nicht mehr uneingeschränkt gelten lassen, vor allem nicht beim Mix mit normalen CAN-Transcievern.
Du kannst mit dem CAN-Treiber direkt am RS485-Bus arbeiten.
Mal angenommen du findest einen CAN-Transciever oder einen RS485-Transciever, der für deine Anwendung den physikalischen Bereich abdeckt, dann kannst du doch einen µC wählen, der UART und CAN unterstützt. Lass den Transciever fix und verbinde per Lötbrücke entweder UART oder CAN-Ausgänge des µC auf den Transciever.
Angehängte Dateien:
-
MAX13085E_function_table.PNG
19 KB -
PIN_config_DTC.PNG
7,7 KB -
MAX13085E_PIN_config.PNG
6,3 KB
Ich hab mal die Pin Configs vom aktuellen CAN Transceiver und dem neuen RS485 Transceiver angehängt. Das heißt also ich kann den CAN Transceiver runter nehmen und an dessen Platz den RS485 Transceiver auflöten und muss nur PIN8 zum Beispiel durch Beinchen hochklappen, mit VCC verbinden ? Receiver und Driver Enable wären dann standardmäßig an. Laut der Funktionstabelle sollte das aber keine Probleme geben wenn ich das richtig sehe. Und schon läuft das ganze ?
Ich glaub du kapierst immer noch nicht, dass CAN und UART (RS232/RS485) zwei ganz verschiedene Sachen sind. Da ist nicht einfach nur ein Treiber IC zu tauschen. Die beiden Buse sind total unterschiedlich. Nur zu
Hans Peter schrieb: > Und schon läuft das ganze ? Und nicht vergessen: das ist nur die Hardware. Ein anderes Protokoll brauchst du natürlich auch. CAN ist völlig anders als RS485. Also: Software umschreiben.
Hans Peter schrieb: > Receiver und Driver Enable wären dann standardmäßig an Rate mal was der empfängt wenn der Drive enable immer an ist.
Antworter schrieb: > Hans Peter schrieb: >> Receiver und Driver Enable wären dann standardmäßig an > > Rate mal was der empfängt wenn der Drive enable immer an ist. ja ich tippe mal nichts bzw. irgendwas... Ich dachte die "X" wären don't care, macht aber nach kurzem Überdenken wenig Sinn ;) Ok, danke erstmal... Damit kann ich dann wenigstens von der 1:1 ersetzen Variante Abstand nehmen. Also einfachste Variante ist immer noch Platz auf Platine finden und RS485 Transceiver mit UART verbinden, richtig ? Dass die Protokolle unterschiedlich sind, war mir ja bewusst. Deswegen hatte ich selber und "ich" ja auch gesagt, softwäremäßig anpassen.
Bei deinem Kenntnisstand wuerde ich sagen vergiss das Ganze. Such dir ein Microcontroller der CAN und UART hat. Du musst ja nur einen von beiden gleichzeitig benutzen bzw auf der Platine bestuecken. Wenn du CAN in Software nachbilden willst wirst du nicht gluecklich. Nur zu
Nur zu schrieb: > Bei deinem Kenntnisstand wuerde ich sagen vergiss das Ganze. > Such dir ein Microcontroller der CAN und UART hat. > Du musst ja nur einen von beiden gleichzeitig benutzen bzw > auf der Platine bestuecken. > Wenn du CAN in Software nachbilden willst wirst du nicht > gluecklich. > > Nur zu CAN soll gar nicht mehr benutzt werden ! Dafür soll ja RS485 implementiert werden...
Und ich muss persönlich auch die Software nicht ändern, sondern nur hardwaretechnische Lösungen anbieten und Aufwand beschreiben etc. Also macht es letztendlich Sinn das überhaupt zu machen. Hätt ich vielleicht erwähnen sollen ;)
Selbst mal angenommen das geht so einfach den Physical-Layer zu tauschen. UART und CAN im Controller erledigen komplett unterschiedliche Jobs. Also entweder müsste dann der Controller rein zufällig auch eine UART alternativ an den gleichen Pins haben, es müsste für die Pins eine Software-UART geschrieben werden oder man legt per Konfigurations-Widerständen fest welche Pins vom Controller am Transceiver ankommen. Der PCA82C250 ist übrigens uralt und bei einem namhaften Automobil-Hersteller schon vor 10 Jahren aus der Liste der verwendbaren Bauteile geflogen. Als Ersatz bietet sich da der TJA1050 an.
Die Inkompatibilität von RS485 und CAN resultiert daraus, dass sie auf verschiedenen Layers des OSI Modells arbeiten. RS485 ist Layer 1 (physical) und CAN auf Layer 2 (Data link): http://prof.beuth-hochschule.de/uploads/media/AusarbeitungCAN-Bus.pdf Das bedeutet: bei RS485 muss sich die Software um Regelung der Konflikte und Übertragungssicherheit (Prüfsumme, Bestätigung, Wiederholung) kümmern, der CAN Bus macht das schon. Das bedeutet also, es hängt davon ab, ob CAN Tranceiver hier bedeutet, es ist nur die Layer 1 (und der uC macht Layer 2) oder ob es bereits beide sind. Ich kenne mich bei CAN nicht aus, kann also nicht sagen, ob es L1 Tranceiver gibt. Falls incl Layer 2, dann bedeutet das: Wenn Du den CAN Tranceiver rausnimmst, geht die Software weiterhin davon aus, dass Konflikte geregelt sind und dass Datenpakete sicher ankommen. D.h. Die Bedingungen, die die Software annimmt, sind nicht gegeben. In dem Fall, dass der CAN Tranceiver nur L1 wäre kümmert sich uC oder die Software um die Layer2, dann kannst Du die Layer 1 austauschen und obendrauf fährt weiterhin das CAN Protokoll.
Ok ok, wie gesagt. Das soll für mich einfach zur Einarbeitung in das Thema dienen, ich weiß, dass mir da noch sehr viel Wissen und Erfahrung fehlt. Dann nur einmal zum Abschluss.. Einfachste Lösung wäre RS485 Transceiver mit der UART zu verbinden oder fällt jemandem noch was praktikables ein oder das Layout der Platine großartig änder zu müssen ? Danach bin ich auch ruhig und sag artig danke für eure Geduld ;)
Der CAN-Transceiver macht nur Layer 1, also rein die Umsetzung auf die physikalische Schnittstelle. Der Unterschied ist im Controller, die CAN-Unit im Controller kümmert sich um die komplette Abwicklung, die wird mit Daten gefüttert und dann schmeisst die den CAN-Frame auf den Bus. Kollisions-Erkennung, CRC, alles inklusive. UART ist dagegen komplett stumpf, der Frame besteht ja nur aus einem Byte plus ein paar Bits, das ist normalerweise ja auch nur eine Punkt-zu-Punkt Verbindung. Gerade mal Parity nimmt einem die UART ab.
Rudolph schrieb: > Der CAN-Transceiver macht nur Layer 1, also rein die Umsetzung auf die > physikalische Schnittstelle. > > Der Unterschied ist im Controller, die CAN-Unit im Controller kümmert > sich um die komplette Abwicklung, die wird mit Daten gefüttert und dann > schmeisst die den CAN-Frame auf den Bus. Kollisions-Erkennung, CRC, > alles inklusive. > UART ist dagegen komplett stumpf, der Frame besteht ja nur aus einem > Byte plus ein paar Bits, das ist normalerweise ja auch nur eine > Punkt-zu-Punkt Verbindung. Gerade mal Parity nimmt einem die UART ab. Das würde ja bedeuten: ich kann jederzeit den Tranceiver in RS 485 tauschen, aber es ändert nicht das Protokoll, das auf der nächsten Ebenen läuft. Insofern ist die Frage, warum ich überhaupt auf RS 485 umstellen will, wenn ich nicht auch die Software vereinfache, um z.B. Clients an einen Master einfacher anzubinden, weil ich nicht CAN muss. Wie gleich oder unterschiedlich sind eigentlich die physischen Medien für beide, brauche ich für CAN mehr als für RS 485?
Ok, erstmal danke conny und rudolph. Wenn ich das richtig verstehe, bedeutet das, dass es theoretisch erstmal möglich ist, die beiden Transciever 1:1 zu tauschen, da sie beide layer 1 machen, korrekt ? Dann muss um RS485 zum laufen zu kriegen, also nur das Protokoll, dass von der CAN-Unit im µC "erstellt" wird, softwaremäßig angepasst oder bzw. neu geschrieben werden. Bitte korrigieren wenn ich Blödsinn rede ! Was wäre eurer Meinung denn die einfachste Lösung RS485 zu implementieren ?? Es muss nicht gezwungenermaßen der CAN Transceiver 1:1 getauscht werden.
CAN und 485 sind von der Hardware fast gleich. Der Hauptunterschied ist das bei 485 immer nur ein Teilnehmer Senden kann. Bei CAN hingegen kann es vorkommen das mehrere Sender gleichzeitig mit der Sendung beginnen. Dafür müssen die Treiber ausgelegt werden. Bei CAN ist eine "0" auf dem Bus dominant. Das müssen die anderen Sender auswerten und sich vom Bus zurückziehen. In der CAN Steinzeit hatte ich mal ein CAN Projekt mit 485 Treiber. Da wurde die "1" auf dem Bus durch Widerstände eingestellt. Das TX der Sender ging dann auf den Senderfreigabe PIN der Treiber die fest auf "0" eigestellt waren. So konnten die Treiber keinen Kurzschluss gegeneinander fahren.
Konrad S. schrieb im Beitrag #3582377:
> Du kannst mit dem CAN-Treiber direkt am RS485-Bus arbeiten.
Die Hardware ist ja nicht das eigentliche Problem. Lustig wird es erst wen euer Vertrieb Geräte mit 485 verkauft und dann erst feststellt das es ja nicht "das 485" Protokoll gibt. Warscheinlich weis der Kunde selber nicht mal was seine anderen Zukaufgeräte eigentlich sprechen. Da macht fast jeder Hersteller was eigenen, was oft auch nicht offengelegt wird. Viel Spaß damit.
Hans Peter schrieb: > Dann muss um RS485 zum laufen zu kriegen, also nur das Protokoll, dass > von der CAN-Unit im µC "erstellt" wird, softwaremäßig angepasst oder > bzw. neu geschrieben werden. Nein, eben nicht, die CAN-Unit im Controller kümmert sich um das Protokoll, das kannst Du in Software nicht so ändern, dass da kein CAN mehr rauskommt. Wenn der Kunde sich wünscht, die Daten auf der anderen Seite per RS485 zu empfangen wird er sicher von einer UART-Lösung ausgehen. Und er wird ganz sicher nicht CAN-Frames über den UART per Software bedienen wollen. Du musst den RS485 Transceiver an einen UART des µC klemmen UND die Software ändern.
Rudolph schrieb: > Hans Peter schrieb: >> Dann muss um RS485 zum laufen zu kriegen, also nur das Protokoll, dass >> von der CAN-Unit im µC "erstellt" wird, softwaremäßig angepasst oder >> bzw. neu geschrieben werden. > > Nein, eben nicht, die CAN-Unit im Controller kümmert sich um das > Protokoll, das kannst Du in Software nicht so ändern, dass da kein CAN > mehr rauskommt. > > Wenn der Kunde sich wünscht, die Daten auf der anderen Seite per RS485 > zu empfangen wird er sicher von einer UART-Lösung ausgehen. > Und er wird ganz sicher nicht CAN-Frames über den UART per Software > bedienen wollen. > > Du musst den RS485 Transceiver an einen UART des µC klemmen UND die > Software ändern. Und im Ergebnis könnte die Hardware einfach beides, weil CAN und RS485 dann zwei getrennte Ports sind. Und bei CAN wäre das Protokoll klar, bei RS485 müsste man eines definieren oder evtl. einen Industriestandard für die entsprechende Anwendung benutzen. Heisst also unter dem Strich: Die Schaltung müsste es in zwei Varianten geben oder sie muss beides können. Aber nur Tranceiver wechseln macht dann wohl keinen Sinn.
Ok, dann danke für eure Hilfe ! Hat ein bisschen Licht ins Dunkle gebracht ;)
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.