ich habe mal eine Frage bezüglich des internen Taktes der AVR's Ich habe mir ein kleines Programm für einen Empfänger geschrieben der auf einem Bus mit lauscht. Es wird aufs Startbit gewartet danach wird ein Timer gestartet um alle 104µSek einen Pinzustand in ein Register zu schieben. Simulieren klappt super liege jeweils genau in der Mitte einer Bitzeit, bzw es schwankt abwechseln um +-125nSek. Da ich aber 3 bis 4 Bytes hintereinander empfange wollte ich fragen wie kritisch hier der interne Taktgeber der AVRs ist. Nicht das ich bei den letzen Bits mit der Abtastung daneben liege. +-5% bei 8 MHz wäre das eine mögliche Veränderung der Bitzeit von 98,9-109,2µSek da könnte es theoretisch von der Bitmitte aus schon nach dem 9 Bit daneben gehen. Die AVRs hängen alle an einer gemeinsamen Versorgungsleitung die Temperaturdifferenz im Haus würde ich auf max. 5° zw. den Zimmern schätzen. Wie kalibriert ihr das ganze soll ich auf allen AVRs einen 16bit Timer mit größtem Vorteiler laufen lassen und bei erreichen von FFFF eine LED leuchten lassen um dann die AVRs aufeinander abzustimmen, so das die LEDs also auf allen zum gleichen Zeitpunkt leichten, so wie ich das Datenblatt verstehe geht das in 2% Schritten was auch nicht gerade genau ist.
Da jedes Byte beim Startbit neu synchronisiert wird musst du auch nur einzelne Bytes betrachten. Wieviele hintereinander folgen ist irrelevant.
vorrausgesetzt das ich jedes Byte mit einem Startbit versehe. Ich wollte aber eher eine ganze Nachricht z.B. 3 Bytes am Stück rüberschieben. Evtl. muss ich mir da etwas ausgeklügeltes programmieren um mit übertragenen Bits den Timer etwas zu korrigieren.
Woher soll der Empfaenger ohne Startbit denn wissen wann es los geht? Volker
Thomas O. schrieb: > vorrausgesetzt das ich jedes Byte mit einem Startbit versehe. Bei asynchroner Übertragung ist das keine Option sondern zwingend notwendig. Das wird aber vom UART automatisch gemacht. Du schiebst nur nacheinander 3 Bytes oder auch 3 Millionen in das Senderegister. Der UART sendet dann 10 Bits. Startbit - 8 Datenbits - Stopbit mfg.
Thomas Eckmann schrieb: > Bei asynchroner Übertragung ist das keine Option sondern zwingend > notwendig. Nur wenn man irgendwo eine echte UART sitzen hat. Wenn man ausschliesslich zwischen den Controllers und mit Soft-UART kummuniziert, dann kann man die "Bytes" auch 24 Bits lang machen. Nur steigt mit jedem zusätzlichen Bit die Anforderung an den Takt.
A. K. schrieb: > Thomas Eckmann schrieb: > >> Bei asynchroner Übertragung ist das keine Option sondern zwingend >> notwendig. > > Nur wenn man irgendwo eine echte UART sitzen hat. Wenn man > ausschliesslich zwischen den Controllers und mit Soft-UART kummuniziert, > dann kann man die "Bytes" auch 24 Bits lang machen. Nur steigt mit jedem > zusätzlichen Bit die Anforderung an den Takt. Dann ist man aber auch nicht an 9600 bps gebunden und koennte was "taktkonformes" nehmen, oder? Volker
ich verwende keine Hardware UART. Alles per Software.
eigentlich wollte ich keine Diskussion wegen Start und Stoppbits usw. lostreten sondern nur mal höheren wie es um den internen Takt und dessen Kalibrierung bestellt ist.
Thomas O. schrieb: > Evtl. muss ich mir da etwas ausgeklügeltes programmieren um mit > übertragenen Bits den Timer etwas zu korrigieren. Wenn du konsequent per Soft-UART arbeitest, dann bist du nicht auf die Codierungmethode asynchroner Schnittstellen angewiesen, sondern kannst eine Übertragungsart verwenden, die jedes einzelne Bit synchronisiert und damit grosse Taktvariantionen verkraftet. Die wohl einfachste Form davon wäre PWM. Beispielsweise Pulsdauer 25% = 0, 75% = 1. Timer bei führender Flanke starten und nach 50% der Periode abfragen. Eine klassische Variante ist auch der Manchester-Code.
Wir beraten immer umfassend! ;) Wieso denn bei Nicht-Standard-Konformer-Software-UART dann genau 9600bps? Oder meintest Du gar wirklich (wie im Titel) 9600 kbps? Dann koennte es mit dem Takt tatsaechlich Probleme geben... ;) Volker
Manchester -> fertig, ohne Probleme, ohne Kalibrierungen.
sorry ich meinte natürlich 9,6 kBit/s. Ich werde mir das ganze mal ansehen, ist ne gute Idee habe ich schonmal bei einer IR-Fernbedienung gesehen das die 0 und 1 mit einem kurzen und einem langen Impuls dargestellt haben.
Kannst das von mir skizzierte Schema noch um eine zweite Schwelle erweitern. Der erwähnte 50% Timer kriegt auf seinem zweiten Komparator 150% der Periode eingestellt. Wenn dieser Komparator zuschlägt, dann ist Pause auf der Leitung und der bisherige Frame zu Ende.
Thomas O. schrieb: > sorry ich meinte natürlich 9,6 kBit/s. Dennoch bietet sich bei proprietaeren Loesungen dann natuerlich eine Datenuebertragungsrate an, die als Teiler der Taktfrequenz ein natuerliches Ergebnis bringt. 10kbps wuerden sich bei 1MHz Takt ja nahezu aufdraengen. Der Grundfehler liegt dann zumindest theoretisch bei 0. ;) Volker
Du kannst auch einen Code verwenden, der genügend Flanken für laufende Synchronisation enthält, z.B. durch Bit-Stuffing, falls die Daten zu viele 0-en oder 1-en in Folge enthalten.
Angehängte Dateien:
Es kommen 2 Drähte zum Einsatz weil ich differentiell übertragen will um evtl. Störungen draußen zu lassen. Manchester würde die Baudrate verdoppelt ohne mehr Informationen zu übertragen, Bitstuffing wollte ich eigentlich weglassen scheint aber im Moment die beste Lösung zu sein, da das nicht immer vorkommt, ein Startbit pro Byte aber immer zu buche schlägt. Hat schonmal jemand von euch den internen Taktgeber kalibriert? Nicht das ich es falsch verstehe ich kann damit nicht per Software den Hardwaretakt zw. 1, 2, 4 und 8 MHz verstellen sondern nur in 2 % Schritten den per Fuse programmierten Takt abgleichen. Wie ist das zu verstehen das das automatisch beim Reset durchgeführt wird? Habe mal einen Auszug vom Datenblatt eingestellt.
Thomas O. schrieb: > Hat schonmal jemand von euch den internen Taktgeber kalibriert? Wenn Du sowieso eine Soft-Uart verwendest kannst Du ja auch die Anzahl der Takte variieren. Bei meinen PICs zähle ich den Flankenabstand des ersten übertragenen Bytes (Initialisierungsbyte z.B. = 0x31 nach einem UART-break) in einer Schleife die 4 Takte a 1 us braucht. Der Trick ist daß ich jeztzt die Flanken in gleicher Richtung (also Bit 0 und Bit 4 mit 4 Bits Abstand) betrachte um Unsymmetrien durch ungleiche Flanken (bei mir wegen Optokoppler mit zu niedrigem Strom) auszuschließen. Die gezählten Schleifendurchläufe a 4 Takte sind bei Bit-Abstand = 4 dann die Bitzeit in Mikrosekunden die dann in Folge für die Delay-Schleife verwendet wird. Gruß Anja
Thomas O. schrieb: > Manchester würde die Baudrate verdoppelt ohne mehr Informationen zu > übertragen Wenn die Bandbreite Deiner Übertragungsstrecke am Anschlag ist, dann werden Deine Impulse verschliffen und die Erkennung aufeinander folgender Bits noch kritischer. Es kann daher durchaus sein, daß Manchester durch die Bitsynchronisation selbst bei doppelter Frequenz noch zuverlässiger ist. Die von mir verwendete Pulslängenmodulation hat obendrein noch den Vorteil, daß sie sehr wenig CPU-Overhead erzeugt. Das Senden erfolgt durch Toggle-Pin-On-Compare völlig jitterfrei und der Empfang durch den Pin-Change-Interrupt. Peter
Thomas, Du könntest es auch so machen wie bei LIN Bussen. Die sind so aufgebaut, dass aus Kostengründen keine Quarze in den Slaves benötigt werden. Gemacht wird das so, dass das erste Byte welches übertragen wird, immer 0x55 ist, also Bitmässig 01010101. Nun kann der Slave einfach die Zeiten ausmessen und sich darauf einstellen. Mit jedem Frame der Übertragung kann somit ein automatischer Abgleich erfolgen. Neuere Mikrocontroller können das sogar in Hardware, aber Du kannst das grundsätzlich auch einfach mit einem Timer und in Firmware lösen.
>Es kommen 2 Drähte zum Einsatz weil ich differentiell übertragen will um evtl. Störungen draußen zu lassen. Den GND aber nicht vergessen. Denn wenn der Empfaenger ausserhalb des Gleichtaktbereiches ist, geht auch nichts mehr. >Hat schonmal jemand von euch den internen Taktgeber kalibriert? Nicht das ich es falsch verstehe ich kann damit nicht per Software den Hardwaretakt zw. 1, 2, 4 und 8 MHz verstellen sondern nur in 2 % Schritten den per Fuse programmierten Takt abgleichen. Wie ist das zu verstehen das das automatisch beim Reset durchgeführt wird? Habe mal einen Auszug vom Datenblatt eingestellt. Ja. hab ich, auch synchronisiert. http://www.ibrtses.com/embedded/avrosccal.html Dafuer ist ja das Datenblatt da. Ich hab dann auch die Abhaengigkeit gemessen. Von der Temperatur und von der Versorgungsspannung. Die ist je nachdem so gross, dass man nachkalibrieren muss. Dh ohne 32kHz Quarz wird nichts. Die Frage ist dann allerdings, ob die Energieersparniss so wichtig ist, oder ob man nicht besser einen 4MHz oder so Quarz laufen lassen will.
also danke nochmal für alle Vorschläge, ich werde mir das alles mal mit Vor- und Nachteilen gegenüberstellen. Und auch ein paar praktische Versuche an der Busleitung unternehmen.
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.