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.
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.
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).
> 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.
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.
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.
> 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?
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.
>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.
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)
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?
@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.
@ 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 :-).
>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.
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.
>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
