-
        

Ergebnis 1 bis 5 von 5

Thema: 5m Datenübertragung am AVR-IO-Pin: Welcher Busabschluß?

  1. #1
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    02.08.2006
    Ort
    Würzburg, Germany
    Beiträge
    672

    5m Datenübertragung am AVR-IO-Pin: Welcher Busabschluß?

    Anzeige

    Hallo Leute,

    ich möchte von einem ATmega8 zu einem ATmega644 Daten übertragen. Es geht dabei um 4 Byte, die ich etwa 10x die Sekunde aktualisieren möchte. Also kein Geschwindigkeits-Rekord. Ich habe am ATmega8 direkt an zwei Portpins eine Buchsenleiste. In dieser steckt ein ca. 5m langes Kabel. 4x dünn, ich schätze 0,34mm². Darüber gehen über zwei Adern die Versorgungsspannung (5V) und über die anderen zwei Adern die Daten (Data und Clk). Zum senden verwende ich folgenden Code:

    Code:
    U8 i1;
    for (i1 = 0; i1 < 4; i1++)
    {
      U8 sendByte = sendData[i1];
      U8 i2;
      for (i2 = 0; i2 < 8; i2++)
      {
        if ((sendByte & 0b10000000) == 0)
          Data0;
        else
          Data1;
        _delay_ms (1);
        Clk1;
        _delay_ms (1);
        Clk0;
        _delay_ms (1);
      }
    }
    Im ATmega644 habe ich einen Interrupt (PCINT22) auf die steigende Flanke des Clk-Signals programmiert und schiebe die Daten dort wieder in die 4 Datenbytes. Das ganze funktioniert ein paar Sekunden und dann ist der Bus durcheinander. Mir ist klar, dass da noch Start- und Stop-Bedingungen, und eine Prüfsumme, etc. dazu kommen sollten, aber grundsätzlich dachte ich sollte es vorher so zumindest fast gut funktionieren, sonst sind die Controller mehr mit Fehlerbehandlung beschäftigt wie mit Datenaustausch.

    Ein verlängern der Delays in der Sende-Schleife auf bis zu 20ms zum testen hat keine Besserung gebracht. Ich habe hier mal gelesen, dass es auch gar nicht daran liegt, sondern daran wie schnell der Sender den Ausgangspin wechselt. Der ATmega8 läuft am internen RC-Oszillator, also ca. mit 1MHz.

    Leider verstehe ich nicht viel von solchen Datenbussen und die dabei entstehenden Reflektionen bei schnellem Wechsel der Pegel und den dafür nötigen Abschluß. Ich habe zum testen auf die Empfängerseite jeweils von Data auf Masse und von Clock auf Masse 4k7 Widerstände verbaut, aber das hat leider nichts gebracht.

    Auf der Empfängerseite muss ich mit Interrupts arbeiten, da der Controller viele Aufgaben gleichzeitig abbarbeiten muss und auch in der Hauptprogramm-Schleife recht beschäftigt ist. Ein pollen der Daten nach dem erkennen einer Start-Bedingung kann ich also nicht umsetzen. Die 3 Timer sind wegen dem Multitasking leider auch schon alle belegt. Zur Not müsste ich mal schauen, ob ein Timer grob im benötigten Clk-Frequenz-Bereich liegt und dann das Delay auf dem ATmega8 anpassen.

    Aber das wäre alles ein Workaround und nicht die Ursache des Problems behoben. Also: Wer hat einen Tipp für mich, wie ich den Bus abschließen muss, damit die Übertragung gut funktioniert?

    Viele Grüße
    Andreas

  2. #2
    Erfahrener Benutzer Robotik Visionär Avatar von Hubert.G
    Registriert seit
    14.10.2006
    Ort
    Pasching OÖ
    Beiträge
    6.183
    Hast du das schon mal ohne Kabel, also nur mit ganz kurzer Leitung probiert?
    Die Spannung geht in welche Richtung und ist gut abgeblockt?
    Grüsse Hubert
    ____________

    Meine Projekte findet ihr auf schorsch.at

  3. #3
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    07.03.2011
    Beiträge
    1.400
    Zitat Zitat von Bumbum Beitrag anzeigen
    Aber das wäre alles ein Workaround und nicht die Ursache des Problems behoben. Also: Wer hat einen Tipp für mich, wie ich den Bus abschließen muss, damit die Übertragung gut funktioniert?
    Hast du, außer "hab mal gelesen" weitere Hinweise, daß ein schlechter Busabschluß dein Problem ist? Wenn es schon Hardware sein soll: wie wäre es mit Cross Talk?

    MfG Klebwax
    Strom fließt auch durch krumme Drähte !

  4. #4
    Erfahrener Benutzer Robotik Visionär
    Registriert seit
    26.11.2005
    Ort
    bei Uelzen (Niedersachsen)
    Beiträge
    7.942
    Eine normale Leitung, also 2 Leiter etwa in einem Telefonkabel hat etwa 100 Ohm Wellenwiderstand. Der Abschluss um Reflexionen zu vermeiden wäre damit 100 Ohm - allerdings ist das für den AVR eine zu große Last, und mit Abschluss auch auf der Senderseite hätte man zu wenig Amplitude. Eine Möglichkeit wäre den Abschluss nur auf der Empfängerseite und auch nur AC gekoppelt für die höheren Frequenzen (so ab etwa 1 MHz) zu machen. Das wäre dann ein Widerstand von etwa 100-150 Ohm und ein Kondensator von 1 - 5 nF in Reihe.

    Ein Alternativ wäre es das Signal gleich auf der Senderseite so langsam zu machen, dass erst gar keine so steilen Flanken auftreten: also etwa 1 K als Serienwiderstand und dazu ein Kondensator von vielleicht 10-50 nF nach Masse - der kann auch gut auf der Empfängerseite sein. Wobei ggf. auch ein RC Filter auf der Empfängerseite hilfreich wäre um kurze Störungen die erst auf der Leitung reinkommen zu reduzieren. Also etwa 100 Ohm noch auf der Empfängerseite in Reihe.

    Die Beschriebenen Störungen müssen auch nicht von Reflexionen kommen. Die Gefahr ist vor allem das kurze Störungen auf der Taktleitung die Zählung durcheinander bringen. Da ließe sich relativ gut in Software abfangen: wenn das Datenbit ausgewertet wird, muss die Taktleitung noch auf High sein, sosnt war es eher nur eine Kurze Störung auf der Leitung. Vor allem wenn man den Niderohmigen Abschluss wählt hat man auch ein Übersprechen zwischen den beiden Datenleitungen über die gemeinsame Masse. Da wäre es ggf. sogar von Vorteil das Signal nicht über 2 Leitungen sondern etwa als 1-Wire Protokoll über unterschiedlich lange Pulse (also etwa 50 µs bzw. 200 µs ) zu senden. Das erfordert etwas mehr Aufwand beim Empfänger, ist aber bei der geringen Geschwindigkeit kein Problem.

  5. #5
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    02.08.2006
    Ort
    Würzburg, Germany
    Beiträge
    672
    Hallo,

    ich muss mich entschuldigen. Es war tatsächlich noch ein Software-Fehler auf der Empfängerseite. Der Code dazu ist keine 10 Zeilen lang und sehr überschaubar. Und wurde natürlich 1000x von mir überprüft. Trotzdem sieht man oft den Wald vor lauter Bäumen nicht.

    Ich habe ein uraltes Oszi zur Verfügung, das hätte ich als nächstes rausgekramt, um mir das Signal mal anzuschauen udn am Busabschluß zu experimentieren. Aber vorher wollte ich mir Lösungen und Vorschläge von euch einholen, damit ich grob die Richtung weiß, in die ich suchen muss.
    Aber nun läuft es ja zum Glück einwandfrei.

    Das mit den 100 Ohm habe ich mir mittlerweile auch schon "ergoggelt", da dies gerne als Abschlußwiderstand für Flachbandleitungen genommen wird. Ich denke mein Leiterabstand im Kabel ist ähnlich. Das meine 4k7 völlig falsch waren leuchtet mir jetzt ein. Ich hatte bei den 100R aber Bedenken, dass der AVR das treiben kann und mir schon Datenblätter zu Bustreibern angesehen. Zum Glück ist das jetzt alles nicht mehr notwendig.

    Nur der Vollständigkeit halber, weil es gefragt wurde: Die 5V Versorgung kommen vom Empfänger und sind auf der Sender-Seite noch mal mit 10µF gepuffert; außerdem natürlich die obligatorischen 100nF am ATmega8. Außer dem Controller gibt es nur 4 Potis mit 10k an Last. Die 10µF sollte also ausreichend sein.

    Viele Grüße
    Andreas

Ähnliche Themen

  1. Welcher Pin für PWM Signal?
    Von datatom im Forum AVR Hardwarethemen
    Antworten: 5
    Letzter Beitrag: 18.01.2012, 22:16
  2. Welcher Pin auf RN-Control2560
    Von datatom im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 8
    Letzter Beitrag: 24.07.2011, 22:50
  3. Antworten: 0
    Letzter Beitrag: 13.04.2008, 22:01
  4. Tiny24/44/84 ISP - Welcher Pin ist SCK?
    Von OnkelTobi im Forum AVR Hardwarethemen
    Antworten: 2
    Letzter Beitrag: 06.09.2006, 01:00
  5. Serielle Datenübertragung von mehreren Quellen auf einen Pin
    Von Dane im Forum Basic-Programmierung (Bascom-Compiler)
    Antworten: 7
    Letzter Beitrag: 15.03.2006, 20:33

Berechtigungen

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