|
|
Forum: Mikrocontroller und Digitale Elektronik Taktstabilität beim Tiny 13Hallo, weiß jemand wie genau der Takt eines Attiny 13 wirklich ist ? Hintergrund: Ich versuche Daten seriell (9600,8,N,1) zu empfangen mit einem Tiny 13 per Software zu empfangen. Hier die Schleife für ein halbes Bit:
Einige Tiny 13 empfangen bei b=17 und einige bei b=18. Kann man den Takt uC ohne Quarz genauer einstellen ? Gruß Guenter > weiß jemand wie genau der Takt eines Attiny 13 wirklich ist ?
So genau wie das frequenzbestimmende Bauteil (Quarz, RC-Kombi.,...).
Hi
>Kann man den Takt uC ohne Quarz genauer einstellen ?
Ja, über das OSCCAL-Register. Damit lässt sich die Frequenz des internen
RC-Oszillators einstellen.
MfG Spess
aber auch OSCCAL hilft nix gegen Temperaturunterschiede. Die lassen den Takt manchmal ganz nett abwandern. bye Frank Ich sende immer nur 7 Zeichen. Diese werden dann von 3 Tiny13 empfangen. Die (noch) 3 hängen an der gleichen Spannungsversorgung und stecken direkt nebeneinander und sind aus einer Lieferung. Deshalb wundern mich diese Taktunterschiede. Ich wollte eine Art Hausbussystem aufbauen. Eventuell werde ich die Geschwindigkeit drosseln müssen. Gruß Günter >Eventuell werde ich die Geschwindigkeit drosseln müssen.
die baudrate hat nichts mit dem fehler zu tun. 2% abweichung sind 2%
abweichung. egal ob bei 100baud oder bei 1000000baud.
@ Guenter Bru >Ich wollte eine Art Hausbussystem aufbauen. >Eventuell werde ich die Geschwindigkeit drosseln müssen. Du wirst eine Quarz einsetzen müssen. Wenn du es nicht glaubst, lies und rechne hier nach. http://pdfserv.maxim-ic.com/en/an/AN2141.pdf MFG Falk Quarz muss nicht unbedingt, aber zumindest ein Keramikresonator sollte es sein. Die sind billig, praktisch (bei den 3beinigen Typen sind die Kondensatoren schon drin) und für RS232 mehr als ausreichend genau, allerdings nicht so genau wie Quarze. Es wird regelmässig probiert, RS232 mit dem internen Osz. zu machen, regelmässig fallen die Leute auf die Schnauze damit, regelmässig gibts hier die selben Antworten dazu, und ebenso regelmässig kommen Leute hinzu, die behaupten, dass klappt bei ihnen prima, muss also gehen. Ja, es geht, auf dem Basteltisch und mit dem PC als Gegenstelle (der hält die Baudrate sehr genau ein, man hat also den vollen Bereich, in dem man selbst daneben liegen kann. Treffen 2 solcher Wackelkandidaten aufeinander, wirds philosophisch. Also nimm was besseres als einen RC-Osz. oder benutz eine synchrone Verbindung, das klappt dann auch, braucht aber ne Leitung mehr (bei RS232 ist die Zeit die zusätzliche Leitung :-) oder nimm eine Manchester-Codierung, da hat man das Taktsignal im Datenstrom schon mit drin. Braucht allerdings die doppelte Bandbreite und kommuniziert nicht mit den üblichen PC-Schnittstellen. Für eigene Sachen aber ganz gut geeignet. Bei nur 6 IO-Pins, ist ein Quarz unschön, dann sind ja nur noch 2 Pins übrig. Man kann aber eine automatische Baudratenerkennung benutzen. Hier mal eine recht sichere Funktion: Beitrag "ATtiny45 Bootloader" Peter Oder die bits pro Übertragung reduzieren. Bei 4bit hast du nur noch den halben Fehler. Automatische Baudratenerkennung wie von Peter Dannegger vorgeschlagen ist natürlich schöner.. @ Peter Dannegger >Bei nur 6 IO-Pins, ist ein Quarz unschön, dann sind ja nur noch 2 Pins >übrig. Dann nimmt man eben einen erxteren Quarzoszillator, entweder einen normalen fix und fertig oder selbst gestrickt mit Inverter + Quarz. Barucht nur ein Pin am uC. (Jaja, bei dem Platzverbrauch kann man auch gleich nen 20pinnigen AVR nehmen ;-) >Man kann aber eine automatische Baudratenerkennung benutzen. >Beitrag "ATtiny45 Bootloader" Hmm, ich hab mal reingeschaut. Ohne den Soft-UART nun ins Detail analysiert zu haben, wie löst er deiner Meinung nach das Problem der Quarzungenauigkeit? Uns selbst wenn es funktionieren sollte, so braucht man doch zumindest (periodisch) eine Art Neusynchronisierung, um Effekte durch Temperaturdrift etc. zu kompensieren. MFG Falk Die automatische Baudratenerkennung scannt zu Beginn der Übertragung die RX-Impulsbreite, calibriert den Oszi auf eine brauchbare Frequenz und bestätigt per TX, dass sich der Teilnehmer "synchronisiert" hat. Erst dann geht's zur Tagesordnung... ... @ jmoney (Gast) >>Oder die bits pro Übertragung reduzieren. Bei 4bit hast du nur noch den >>halben Fehler. Das hilft garnichts. Bei 4 Bit halbiert sich die Fehlerrate nur dann wenn du auch nur die halbe Menge an Daten überträgst. Überträgst du aber zb. 1Kb an Daten, entweder in 4Bit oder 8Bit Packeten so wird die Fehlerrate bei den 4Bit Packeten eher höher sein als geringer. Gruß Hagen Doch, kürzere "Bytes" funktionieren sehr wohl besser, da mit jedem Startbit der Takt neu synchronisiert wird. Die Anforderung an die Taktgenauigkeit wächst mit der Anzahl nicht selbst synchronisierender Bits. Hagen Re wrote: > @ jmoney (Gast) >>>Oder die bits pro Übertragung reduzieren. Bei 4bit hast du nur noch den >>>halben Fehler. > > Das hilft garnichts. Bei 4 Bit halbiert sich die Fehlerrate nur dann > wenn du auch nur die halbe Menge an Daten überträgst. Überträgst du aber > zb. 1Kb an Daten, entweder in 4Bit oder 8Bit Packeten so wird die > Fehlerrate bei den 4Bit Packeten eher höher sein als geringer. Nö. Wenn ein Frame nur 4 anstatt 8 Bit hat, kann das sehr wohl die Übertragungssicherheit erhöhen bzw. die Fehlerwahrscheinlichkeit reduzieren, weil eben nicht erst nach 8 Bit neu synchronisiert wird (Startbit) sondern schon nach 4 Bit. Bei einem kleinen Unterschied in der Taktrate ist nach 8 Bit der Fehler doppelt so groß wie nach 4 Bit. @ Johannes M. >Nö. Wenn ein Frame nur 4 anstatt 8 Bit hat, kann das sehr wohl die >Übertragungssicherheit erhöhen bzw. die Fehlerwahrscheinlichkeit >reduzieren, weil eben nicht erst nach 8 Bit neu synchronisiert wird >(Startbit) sondern schon nach 4 Bit. Bei einem kleinen Unterschied in >der Taktrate ist nach 8 Bit der Fehler doppelt so groß wie nach 4 Bit. Das klappt aber nur, wenn du per Soft-UART ein "neues" RS232 Format realisierst, welches nur 4 Datenbits hat. Dann geht deine Netto-Datenrate aber von 8/10 (80%) auf 4/6 (60%). Mal abgesehen davon, dass man das mit einem normalen PC nicht direkt senden und empfangen kann. Soviel Stress um einen Quarz einzusparen? MFG Falk @Falk: Es ging mir auch nur darum, die Behauptung zu widerlegen, dass sich mit einer geringeren Framebreite die Übertragungssicherheit nicht erhöhen lässt. Dass 4 Bit-Frames von Hardware-UART nicht unterstützt werden, steht auf einem anderen Blatt... Jeder PC kann so einen Frame empfangen, wenn der Absender genug Stopbits hinterherschiebt. Klar wird das langsamer. Wenn's um Tempo geht ist das Unfug. Wenn's um Zuverlässigkeit geht, kann das eine Lösung sein. Wo bitte soll ein Tiny13 die Datenmengen für Highspeed-UART auftreiben? Falk wrote: > wie löst er deiner Meinung nach das Problem der > Quarzungenauigkeit? Gar nicht. Der Witz ist ja, das man den internen RC-Oszi nimmt, d.h. ein Quarz ist nirgends nicht angeschlossen. > Uns selbst wenn es funktionieren sollte, so braucht > man doch zumindest (periodisch) eine Art Neusynchronisierung, um Effekte > durch Temperaturdrift etc. zu kompensieren. Es versteht sich von selbst, daß man das Autobauding zyklisch wiederholt, wenn die Verbindung längere Zeit besteht. Z.B. sendet der Master alle 10min ein Break (überlanges 0-Byte) und danach das Zeichen zum Autobauding. Oder wenn Übertragungsfehler auftreten (CRC-Check). Peter Hannes Lux wrote: > Die automatische Baudratenerkennung scannt zu Beginn der Übertragung die > RX-Impulsbreite, calibriert den Oszi auf eine brauchbare Frequenz und > bestätigt per TX, dass sich der Teilnehmer "synchronisiert" hat. Erst > dann geht's zur Tagesordnung... Das ist sehr unpraktisch, da Du von Atmel keine definierte Funktion f = f(OSCAL) kriegst. Du mußt also mehrere Sync-Bytes senden und der Slave muß dann mit Trial&Error den richtigen Wert umständlich ausprobieren. Deshalb mache ich es so, daß ich die Bitzeit ausmesse und dann direkt für die Baudrateneinstellung verwende. Dann ist es auch egal, ob ein Slave mit 9,6 und ein anderer mit 4MHz nominaler Frequenz läuft. Die ausgemessenen Bitzeiten sollten nur über 100 Zyklen liegen, damit der Timerfehler <1% ist. Z.B. für 4MHz max 40kBaud. Peter @Peter: Danke für die Aufklärung. Ich hatte mich mangels Notwendigkeit noch nicht intensiver damit beschäftigt. Für "Eindraht"-Kommunikation zwischen kleinen AVRs benutze ich ein eigenes Protokoll, dass ähnlich dem OWI aufgebaut ist, aber bedeutend langsamer taktet, damit es als State-machine im Timer-Int nebenher arbeiten kann. Es hat ein Richtungsbit (Senderecht-Zuteilung), 8 Datenbits und eine Bitzeit Pause zur Byte-Synchronisation und rattert ("stolpert", da je jeder zehnte Takt fehlt) mit 1kHz (Int. alle 0,25ms). Ich nutze es hauptsächlich zum gelegentlichen Parametrieren kleiner Steuerungen auf Tiny13 mit einem "Terminal", bestehend aus Tiny2313, LCD und ein paar Tastern. Das Terminal ist dabei Slave. Die (spartanischen) LCD-Texte und die Menüführung befinden sich in den Tiny13-Geräten. ... @Hannes Was ist OWI ? Läuft dein Protokoll zuverlässig und wie ist es aufgebaut ? Auf Geschwindigkeit kommt es mir nicht so an. Mehr auf Zuverlässigkeit. Gruß Günter OWI ist das One Wire Interface, das die Dallas-Sensoren bzw -Speicher verwenden. Es ist rechtlich geschützt, man darf keine Slaves dafür nachbilden. http://www.mikrocontroller.net/search?query=owi&forums%5B%5D=1&forums%5B%5D=9&forums%5B%5D=10&forums%5B%5D=2&forums%5B%5D=4&forums%5B%5D=3&forums%5B%5D=6&forums%5B%5D=17&forums%5B%5D=11&forums%5B%5D=8&forums%5B%5D=12&forums%5B%5D=14&forums%5B%5D=7&forums%5B%5D=5&forums%5B%5D=15&forums%5B%5D=13&forums%5B%5D=16 Mein Telegramm besteht aus 9 Impulsen und einer Pause von der Zeit eines Impulses. Die Bit-Information steckt im Tastgrad der Impulse (25% / 75%). Das erste Bit gibt (bei mir) die Datenrichtung an, es teilt dem Slave also mit, ob er zuhören muss oder senden darf. Muss er zuhören, dann sendet der Master 8 Datenbits, deren Impulszeit die Information enthalten. Die Periodenzeit ist (bei mir) immer 1ms. Darf der Slave senden, so generiert der Master nur kurze (25%) Impulse und fragt bei 50% den Portpin ab, ob der Slave den Impuls verlängert hat. Der Slave witd durch jeden Impulsbeginn synchronisiert und fragt (bei Empfang) bei 50% der Bitzeit den Portzustand ab. Falls er senden darf und eine 1 senden muss, aktiviert er selbst den Impuls und hält ihn bis 75% der Bitzeit auf L. Die Impulse sind L-aktiv, die Portbits sind open-Drain mit externen PullUp-Widerständen. Ich habe (wenn ich mich jetzt nicht irre) kurz für 0 und lang für 1 definiert. Für meine Zwecke läuft es sehr stabil, die AVRs dürfen um mehr als 20% im Takt driften, es passt aber aufgrund der Datenrate von 100 Bytes pro Sekunde nicht richtig in die heutige Zeit. Da ich nicht weiß, ob ich damit irgendwelche Patentrechte verletze, habe ich es nicht auf meiner HP veröffentlicht. ... Hannes Lux wrote: > OWI ist das One Wire Interface, das die Dallas-Sensoren bzw -Speicher > verwenden. Es ist rechtlich geschützt, man darf keine Slaves dafür > nachbilden. ich weiß nicht, ob man das im Privaten so eng sehen muß. Allerdings hat man nur bei Maxim (Dallas) die Gewähr, daß keine Adresse doppelt vergeben wurde, die dürfen also nur 2^56 1w-ICs herstellen. Peter Sind sogar noch weniger, da 8 Bits als Typcode verbraten werden. Pro Typ sind also nur 2^48 = 281 Billionen Exemplare möglich. ;-) Beliebt ist auch das 25/75 Protokoll. D.h. 0 = 25%, 1 = 75% Tastverhältnis, dann die Zeitschwelle auf 50% legen und schon hat man das Bit eingefangen. Es ist eigentlich so offensichtlich (trivial), daß daran keiner irgendwelche Rechte haben kann. Bei IR-Fernbedienungen sieht man es häufig. Peter Peter Dannegger wrote: > Beliebt ist auch das 25/75 Protokoll. > > D.h. 0 = 25%, 1 = 75% Tastverhältnis, dann die Zeitschwelle auf 50% > legen und schon hat man das Bit eingefangen. So mache ich es doch. Nur eben so langsam, dass es im Timer-Int nebenbei läuft, ohne merklich Rechenzeit zu beanspruchen. Und um mir weiteren Protokoll-Overhead für die Senderechte zu ersparen, habe ich das Richtungsbit (Startbit, da erstes Bit) eingefügt. Um die Bytes sauber (mittels Timeout) trennen zu können, lasse ich nach jeweils 9 Bit einen Impuls ausfallen. > Es ist eigentlich so offensichtlich (trivial), daß daran keiner > irgendwelche Rechte haben kann. Ja, es ist trivial, aber mit den Rechten weiß man ja nie... Ich nutze es für mich muss es aber nicht für Andere zum Standard erklären. > Bei IR-Fernbedienungen sieht man es häufig. Mit IR-Fernbedienungen habe ich recht wenig zu tun, da fehlte das Interesse, abgesehen vom Umbau des Pollin-Bausatzes. Märklin-Digital macht auch sowas ähnliches, nur eben nicht bidirektional. Ich mag dieses 25/75-Protokoll (wusste nur nicht, dass es so heißt), da sich Master und Slave bei jedem Bit neu synchronisieren. Dabei habe ich bisher auf automatische Erkennung der Taktfrequenz verzichtet. > Peter Gruß, Hannes, und danke für Deine vielen guten Beiträge, aus denen ich viel gelernt habe. @all Ich bedanke mich auch für die zahlreichen Beiträge. Gruß Günter Bitte 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
Noch kein Account? Hier anmelden.
|
|
Thread beobachten
Seitenaufteilung abschalten