-         

Ergebnis 1 bis 6 von 6

Thema: CAN-Bus zweckendfremden...

  1. #1
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    26.07.2004
    Beiträge
    274

    CAN-Bus zweckendfremden...

    Anzeige

    Hallo,

    ich überlege gerade wie Einfach es sein könnte, zwei uC (punk zu punkt) mithilfe von CAN-Transceiver in störungsbehafteter Umbegung miteinander zu verbinden!

    Ich habe mir überlegt den Transceiver direkt an den RxD/TxD des z.b. ATMegas zu hängen :



    Da ich gerade nur einen Tranceiver zur verfügung habe, und leider kein langes Kabel wo quer durchs Haus geht, kann ich leider nicht testen und wollte fragen wer sowas schon mal gemacht hat?

    Wie lang war dann sein Kabel, welche Geschwindigkeit und wieviel Fehler sind bei der Datenübertragung endstanden?

    Grüße
    Alex

  2. #2
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    17.08.2004
    Beiträge
    1.065
    also ich meine CAN-Bus ist für bis zu 1km Kabel gedacht, sehr störsicher. zumindest auf dem papier, aber es wird auch in der industrie benutzt, ich denke du solltest kein großes problem bekommen, das zu verlegen. allerdings bin ich mir nicht sicher, ob das so einfach geht, wie du willst. CAN bus braucht diverse header usw, die man erst schicken muss um den empfänger vorzubereiten. es ist wesentlich komplizierter als n einfacher RS232.
    Willst du denn das Kabel selbst einziehen oder ein vorhandenes nutzen?

  3. #3
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    26.07.2004
    Beiträge
    274
    Hallo,

    danke für die Antwort!

    CAN bus braucht diverse header
    Ja schon richtig! Aber ich lasse den CAN-Bus-Controller einfach weg!

    Und laut Datenblatt schaltet der Tranceiver einfach die Pegel um! Dem scheint es auch egal zu sein was da jetzt für Daten kommen, und von wem! Nur weis ich nicht wie Zeitkritisch das ganze ist.

    Grüße
    Alex

  4. #4
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    06.02.2005
    Ort
    Hamburg
    Alter
    31
    Beiträge
    4.255
    Wenn du sowieso noch Transceiver besorgen musst, könntest du auch RS422/RS485 verwenden. Da kannst du auf jeden Fall direkt an den AVR gehen, ohne noch irgendwelche Protokolle beachten zu müssen.

  5. #5
    Erfahrener Benutzer Begeisterter Techniker
    Registriert seit
    26.07.2004
    Beiträge
    274
    könntest du auch RS422/RS485 verwenden
    hmm, von der Funktion her macht der RS485-Transceiver das gleiche wie der für den CAN-Bus, nur der eine arbeitet mit 5V der andere mit 12V Leitungsspannung....

    beide haben 120Ohm Abschluss.

    12V ist natülich besser
    5V kommen aber einfacher von nem Spannungsregler als von nem 12V Bord-Netz..

    hmm, da muss ich wohl "ehne mene miste" anwenden...

    grüße
    Alex

  6. #6
    Erfahrener Benutzer Robotik Einstein
    Registriert seit
    17.04.2006
    Beiträge
    2.193
    Entscheidend ist nicht wirklich, womit Du einspeist, sondern wie die Schwellen Deines Empfängers liegen. Was Du vor hast ist natürlich kein CAN-Bus mehr, dazu gehört eine vollständige Implementierung dessen, was nach dem physical Layer folgt, dadurch bekommst Du erst die Störsicherheit. Um einfach nur Daten zu schieben reicht sicher RS422 (PtoP) oder RS485(PtMP), morgen werde ich dazu mal ein kleines Projekt auf meine Homepage stellen, es geht um die Anbindung einer Eumex-ISDN-Anlage zwecks Programmierung über 40-50m strukturierte Verkabelung. Diese Anlage muckt schon, wenn man die mitgelieferten 3m RS232-Leitung verdoppelt, daher diese Aktion.
    In meiner Studienarbeit habe ich ohne viel nachzudenken und nachzuprüfen einen RS485-Bus über ein freies Paar CAT5/6-Verkabelung geschickt, dabei konnte ich keine Probleme feststellen. Die Übertragungsrate ist bei 38400bps, beim vorgenannten TK-Anlagen-Projekt bei 115200bps. Fehlerkorrektur in der Software ist für sicherheitsrelevante Anwendungen unbedingt erforderlich!

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •