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

[Bumbum]

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:

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

[Hubert.G]

Hast du das schon mal ohne Kabel, also nur mit ganz kurzer Leitung probiert?
Die Spannung geht in welche Richtung und ist gut abgeblockt?

[Klebwax]

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

[Besserwessi]

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.

[Bumbum]

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