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.
Was ist das für ein "Zielsignal" das genau 20MHz haben muss?
Jedenfalls kann ich pfft nur Recht geben. Du musst das Grundübel beseitigen. Da irgendwas rumdoktern gibt nur Probleme.
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.
Oder eine mit 6 bit. Den Rest der Zeit mit Schieben verbringen... toll.
> 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.
Jetzt muss ich mal dumm fragen: Es gibt doch beim ATMega644 die Möglichkeit den Takt für die serielle extern einzuspeisen, oder?
Ach nee, das ist ja Slave-Betrieb. Das geht ja nicht wenn der Takt nicht wirklich vom Sender kommt. Mist.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.