Taktstabilität beim Tiny 13

RS232 beim AVR ohne Quarz ist Lotto...

...

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

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

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.

@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