www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Serielle Übertragung und Fehlerreduzierung


Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

baue hier mit einem ATmega 644P, 20MHz mit externem Quartz, und einem 
Lantronix Matchport. Beide sitzen jeweils auf ihrem Testboard (STK500, 
Matchport Demo Board) und sind zur seriellen Übertragung mit zwei 
Strippen (zwanzig Zentimeter Länge) aus einem Flachbandkabel (und 
einpoligen Pfostenbuchsen) zwischen den jeweiligen Ports direkt 
miteinander verbunden. Gesendet wird dabei Bulktransfer nur in eine 
Richtung, vom Matchport zum AVR.

Ich habe verschiedene Geschwindigkeiten und Übertragungsparameter 
ausprobiert:
Bei 57600 Baud ist die Übertragung fehlerfrei
Bei 115200 Baud hat sie ein paar Fehler (habe ich allerdings nicht 
gemessen).

Eine Übertragung von 230kBit mache ich mit dem AVR bei Divisor 10 (d.h. 
für 115200) und Dual Speed. Macht es eventuell Sinn den Divisor auf 5 
und Single-Speed einzustellen (im Datenblatt für den ATmega ist für die 
Rate der Divisor 4 vorgesehen und eine hohe Abweichung angegeben - 
warum?).

Bei 230400 Baud, 8N1 liegen die Fehler im Promillebereich. Eine Messung 
ergab dabei:
Uart0 Overflow 0
Byte Error 1668
Bytes Received 18739127

und bei
230400 Baud, mit 8N2 ergab die Messung
Uart0 Overflow 0
Byte Error 260
Bytes Received 1882049

Mehr Stopbits ergeben eine bessere Synchronisierung, wie man sieht. Aber 
vermutlich auch einen Verlust an Nutztransferrate von geschätzt 10%, da 
ein Kontrollbit mehr übertragen wird.

Der AVR braucht für ein Zielsignal genau den externen Takt von 20MHz, 
d.h. die Lösung einen Baudradenquartz zu verwenden kommt nicht in Frage.

Ich möchte Daten so schnell als möglich übertragen, d.h. 230 kbit wären 
schon gut. Allerdings möchte ich auch die Fehlerrate reduzieren, da ich, 
wenn ein Fehler auftritt, einen ganzen Datenblock von einem KB wegwerfen 
kann und außerdem noch wohl CRC übertragen müsste um das überhaupt 
herausfinden zu können.

Also:
Wie kann ich die Übertragungsfehler noch weiter verringern?
Welchen Einfluss hat der Wechsel von einer Strippenverbindung in einem 
Testsetup zu einer Leiterbahn auf einer Platine?
Was gibt es bei der Konstruktion einer Platine, die diese schnelle 
Übertragung möglichst fehlerfrei realisieren soll, zu beachten?

Hoffe, ihr könnt einem Softwerker mit Elektronikwissen weiterhelfen.

     Viele Grüße,
     Michael.

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das würde also bedeuten, dass, wenn ein Bit kippt, dann (meist) eines 
ganz am Schluss? Dann könntest du ja über alle letzten Bits einen 
einfachen Fehlerkorrekturcode implementieren.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm. Da ist wohl ein Fehler: In der 230kbit 8N2 Übertragung fehlt eine 
Stelle. Bei Bytes Received sollte es heissen: 1882049x, d.h. eine Stelle 
mehr. Die Messungen für 8N1 und 8N2 sind also vergleichbar.

Ansonsten komme ich wohl bei der geplanten Übertragung nicht ohne einen 
CRC aus, da ein Fehler den gesamten zu übertragenden Block kaputt macht.

Ob das Bit, dass kippt, ganz am Schluss ist? Könnte sein.

Ich denke mir, dass das Einfügen eines zweiten Stoppbits hilft, eine 
bessere Synchronisierung zu machen, d.h. wenn der Empfänger weiß, aha, 
zwei Stopbits sind leichter zu erkennen als nur eines, wird auch das 
Startbit besser erkannt.

Zitat Wikipedia (aus RS232):
Die Synchronisation des Abfragetaktes des Empfängers geschieht mit dem 
Start der Übertragung auf der Datenleitung. Der Empfänger synchronisiert 
sich in die Mitte des sogenannten Startbits (1 Bit vor den Datenbits) 
und taktet die folgenden Bits des Datenwortes mit "seiner" Baudrate ab.

Kann natürlich sein, dass nicht nur eher die Bits am Ende kippen, 
sondern die ganze Stop-und-wieder-Start-Bit Synchronisierung den Bach 
runter geht und dann das ganze nachfolgende Zeichen weg ist.

Da müsste ich wohl noch weitere Untersuchungen machen, was für ein 
Fehler genau beim Empfang passiert.

Die Messung erfolgte so: Ich sende die vordefinierte Zeichenfolge 
0123456789 immer wiederholt. Der Empfänger synchronisiert sich auf das 
erste Zeichen dieser Folge und gleicht dann die folgenden empfangenen 
Zeichen mit der bekannten Folge ab.
Stimmt die empfangene Zahlenfolge nicht mit der definierten Folge 
überein, wird ein Fehler gezählt.

Was man jetzt machen kann ist, dass man eventuell schaut wie groß der 
Unterschied zwischen dem erwarteten Zeichen und dem tatsächlich 
empfangenen Zeichen ist.
Zwei Fälle fallen mir ein:
- entweder ein Zeichen wurde überhaupt nicht empfangen, d.h. das 
tatsächlich empfangene Zeichen ist erst das folgende in der Folge
- oder es ist ein ganz anderes Zeichen, d.h. ein tatsächlicher 
Bitkipper.

Vielleicht muss ich genau da nochmals besser hinschauen um zu sehen, 
woher die Fehler kommen. Eventuell muss ich auch meine vordefinierte 
Zeichenfolge überdenken. Wenn nur das letzte Bit kippt, heisst das ja 
praktisch gesehen +/- 1 für den Ascii-Wert (oder täusche ich mich da?). 
Was bedeutet +1 wäre genau das nachfolgende Zeichen (und die Messung 
dann nicht brauchbar).

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ob das Bit, dass kippt, ganz am Schluss ist? Könnte sein.

Der Empfänger tastet ja die hereinkommenden Bits mit einer bestimmten 
Abtastrate ab, abhängig von der Baudrate. Ausgelöst wird diese Abtastung 
jeweils durch das Ende eines Stopbits. Stopbit fertig, dann in fixen 
Zeitabständen 8 mal abtasten. Wenn die Abtastrate aufgrund leicht 
unpassender Baudrate aber nicht genau stimmt, dann verschiebt sich die 
Zeit der Abtastung bei jedem Bit leicht gegenüber dem empfangenen 
Signal. Also ist der Fehler beim letzten Bit am grössten. Dann könnte es 
sein, dass zu dem Zeitpunkt abgetastet wird, wenn das Bit noch nicht 
richtig gesetzt ist bzw. schon "fast" das nächste Bit kommt.

An deiner Stelle würde ich unbedingt mal prüfen, ob das letzte Bit 
signifikant häufiger betroffen ist. Wenn das der Fall ist, dann müsstest 
du die Fehlererkennung wirklich nur über dieses Bit machen.

Autor: Kopfnuss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe den Eindruck, das Du da in eine falsche Richtung gehst.

Was Du da z.B. als Synchronisierung bezeichnest, ist keine. 
Synchronisierung würde heissen, das der Empfänger sich die Bitbreiten 
anschaut und daraus den Takt ableitet. Das aber ist nicht der Fall. Der 
Takt bleibt fest, so, wie er durch den Baudraten-Generator vorgegeben 
ist.

Der Empfänger vom ARV wartet nur die Flanke vom Startbit ab und fängt 
dann mit dem Baudrate an jeweils bis zur Sample-Position an zu zählen.

Ergebnis: Es gibt keine "Synchronisation".

Das zwei Stop-Bits die Fehlerrate verringern kann sich durch dadurch 
ergeben, das sich die zusätzliche Verzögerung durch das weitere Stop-Bit 
günstig zu dem Fehler addiert, der schon in der Baudrate enthalten ist.

Darauf solltest Du Dich aber nicht verlassen. Nimm einen Baudratenquarz!
Du sagst, das ist nicht möglich. Nun gut. Dann bist Du auf die Baudraten 
beschränkt, bei denen der Fehler kleiner und für Dich akzeptabel ist.

Ein Weg wäre noch, die Baudrate von dem Bluetooth-Teil mit dem 
Oszilloskop nachzumessen.

Autor: pfft. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also. Der Mechanismus ist eigenlich klar. Wenn die Baudraten nicht 
aufeinanderpassen gibt's Fehler. Ich wuerd meine Zeit nicht mit Checks 
vertun, sondern mit dem Anpassen der Baudrate. Falls man nun auf der 
anderen Seite zugriff auf die Baudrate haette ... Falls dort ein AVR 
auch mit einem 20MHz Quarz waere... Sonst koennte man sich auch 
synchrone Kommunikation (SPI) vorstellen, wenn die Systeme schon 
nebeneinander sind.

Autor: Kopfnuss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist das für ein "Zielsignal" das genau 20MHz haben muss?

Autor: Kopfnuss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jedenfalls kann ich pfft nur Recht geben. Du musst das Grundübel 
beseitigen. Da irgendwas rumdoktern gibt nur Probleme.

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bleibe bei meiner Meinung, dass das Problem nur beim letzten Bit 
liegen kann. Dann könnte man ja einfach eine 7-Bit-Übertragung machen.

Autor: pfft. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder eine mit 6 bit. Den Rest der Zeit mit Schieben verbringen... toll.

Autor: Lothar Miller (lkmiller) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Allerdings möchte ich auch die Fehlerrate reduzieren...
Das ist an sich eine gute Idee, meine Übertragungen auf dem Labortisch 
haben 0 Fehler (über die Nacht). Erst dann habe ich ein gutes Gefühl 
:-/

Mir scheint, du hast irgendwo ein Problem, das sich hier nur gut hinter 
anderen Symptomen versteckt. Wie sieht denn die Signalqualität auf der 
Leitung aus (Oszi)? Tritt der Fehler bei bestimmten Zeichen (Bitfolgen) 
öfter auf? Hast du irgendeine Art von Terminierung auf der Leitung 
vorgesehen?

Autor: space (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,

ich sehe es auch wie einige Vorschreiber: das Problem muss am
der Wurzel beseitigt werden.
1. Die Baudrate wird von der Taktfrequenz abgeleitet. Hast Du
schon mal versucht die Taktfrequenz so zu kalibrieren, dass
der Fehler minimiert wird?
2. Du überträgst die Daten mit 8N1 oder 8N2. Hast Du schon
mal versucht das Paritätsbit zu nutzen?
Viel Erfolg wünscht
Stefan

PS: Bei meinem Schneider CPC664 hatte ich das selbe Problem.
Ein separater Takt für die Schnittstelle schaffte Abhilfe.

Autor: pfft. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>PS: Bei meinem Schneider CPC664 hatte ich das selbe Problem.
Ein separater Takt für die Schnittstelle schaffte Abhilfe.

Wir reden nicht von einer externen schnittstelle, leider.

Autor: Kopfnuss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt muss ich mal dumm fragen: Es gibt doch beim ATMega644 die 
Möglichkeit den Takt für die serielle extern einzuspeisen, oder?

Autor: Kopfnuss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ach nee, das ist ja Slave-Betrieb. Das geht ja nicht wenn der Takt nicht 
wirklich vom Sender kommt.
Mist.

Autor: pcb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich würde halt probeweise den "richtigen" Quarz einsetzen(und 
minimalster Softwareänderung) den gleichen Test nochmal laufen lasse. 
Wenn der Fehler immer noch da sind, dann sind all die Leute, die nach 
einem anderen Quarz schreien, schon mal ruig, wenn nicht: hatten sie 
Recht und du die Ursache.
(ist zwar immer noch keien Lösung, aber immerhin eine Ursache)

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Okay, gute Diskussion. Mir geht es einfach darum, das Problem genauer zu 
beleuchten und eventuell zu einer brauchbaren Lösung zu kommen.

@Kopfnuss:
Ich möchte auf dem 2. Uart des 644P eine serielle Übertragung mit genau 
250 kbaud ohne Abweichung erzeugen (insofern sind die 20MHz schon ein 
Baudratenquarz ;-). Die 20MHz sind einfach fix dafür.

Prinzipiell war meine ursprüngliche Frage, wie man das elektrische 
Signal "besser" machen kann. Die Fehlerrate ist ja durchaus schon 
niedrig, d.h. es geht, aber eben noch nicht gut genug.

Was vielleicht sein könnte ist, dass - ich bin kein E-Technik-Experte 
und zitiere jemand anderen - der Matchport mit Signalpegeln von max 3.3V 
operiert (allerdings am Eingang 5V tolerant ist), während der AVR bei 
20MHz mit 5V betrieben wird.

Also:
Matchport (3.3V) ---- sendet massenhaft Daten ---> AVR (5V)
                 <--- sendet wenig Feedback ------
Der Matchport ist 'ne Blackbox in gewisser Hinsicht, da habe ich ein 
paar Standardübertragungsraten u.a. die o.g.

Kann das eventuell einen Einfluss auf die Qualität des Signals bzw. auf 
die Qualität der Signalerkennung haben? Bringt eventuell ein 
Pegelwandler ein besseres Signal für den AVR?

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@pcb:
Das mit dem passenden Quartz, d.h. 18.432 MHz, hatte ich schon 
ausprobieren wollen, allerdings ist der bei Conrad besorgte nicht mehr 
funktionsfähig ;-(.
Werde wohl einen neuen besorgen müssen, um das mit weniger Abweichung 
zumindest mal getestet zu haben.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Lothar Miller
Die Überprüfung der Signalqualität mit dem Oszi kann ich nicht selber 
machen, geht also nicht sofort (d.h. jetzt am Wochenende).

Aber das mit der Bit-Überprüfung, d.h. ob meistens das letzte Bit falsch 
ist, werde ich morgen mal angehen. Das interessiert mich auch :-).

Autor: Kopfnuss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich möchte auf dem 2. Uart des 644P eine serielle Übertragung mit genau
>250 kbaud ohne Abweichung erzeugen (insofern sind die 20MHz schon ein
>Baudratenquarz ;-). Die 20MHz sind einfach fix dafür.
Ja gut. Das ist aber nach wie vor ein Widerspruch. Wenn Du auf einem 
Port gerade passen 250kBaud erzeugst, dann wird der andere mit 230400 
eine Abweichung haben. Du kannst nicht beides zugleich präzis haben.

>Prinzipiell war meine ursprüngliche Frage, wie man das elektrische
>Signal "besser" machen kann. Die Fehlerrate ist ja durchaus schon
>niedrig, d.h. es geht, aber eben noch nicht gut genug.
Bis zu diesem Moment konnte man davon ausgehen, das die Fehler 
hauptsächlich auf die Abweichungen von der "richtigen" Baudrate beruhen.
Nun aber lesen wir folgendes (und fühlen uns ein wenig verschaukelt)

>Was vielleicht sein könnte ist, dass - ich bin kein E-Technik-Experte
>und zitiere jemand anderen - der Matchport mit Signalpegeln von max 3.3V
>operiert (allerdings am Eingang 5V tolerant ist), während der AVR bei
>20MHz mit 5V betrieben wird.
Das kann durchaus eine wesentliche Rolle für die Störsicherheit spielen.
Bis zu diesem Zeitpunkt war nicht klar, das Du KEINE Pegelwandler 
einsetzt.
Das wäre eigentlich normal. Eigentlich sollte das auf einige Zentimeter 
auf der Platine noch nicht so dolle was ausmachen, aber es lohnt den 
Versuch, denn wir kenne ja auch Deine Störumgebung nicht (und können 
anscheinend nichts voraussetzen).

>Matchport (3.3V) ---- sendet massenhaft Daten ---> AVR (5V)
>                 <--- sendet wenig Feedback ------
>Der Matchport ist 'ne Blackbox in gewisser Hinsicht, da habe ich ein
>paar Standardübertragungsraten u.a. die o.g.

>Kann das eventuell einen Einfluss auf die Qualität des Signals bzw. auf
>die Qualität der Signalerkennung haben? Bringt eventuell ein
>Pegelwandler ein besseres Signal für den AVR?

Sicher. Siehe oben.

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
War nicht meine Absicht jemanden zu verschaukeln. Mache eben eher in 
Software... und hatte ganz verdrängt, dass man mit einer korrekten 
Signalanpassung ein besseres Signal bekommt. Trotzdem scheinen die 
Auswirkungen davon nicht so hoch zu sein, wie man es vielleicht erwarten 
würde.

Trotzdem vielen Dank für die Meinungen. Ich werde die möglichen 
Varianten ausprobieren und sehen, was dabei herauskommt.

Autor: Hagen Re (hagen)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Der Empfänger vom ARV wartet nur die Flanke vom Startbit ab und fängt
>dann mit dem Baudrate an jeweils bis zur Sample-Position an zu zählen.
>Ergebnis: Es gibt keine "Synchronisation".

Das Warten auf das Startbit ist eine Synchronisation.

Gruß Hagen

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.