Hallo,
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:
1
.equ b =17 ;9600 bps @ 1.x MHz ATTiny13 ohne Quarz
2
UART_delay: ldi temp,b
3
UART_delay1: dec temp
4
brne UART_delay1
5
ret
Einige Tiny 13 empfangen bei b=17 und einige bei b=18.
Kann man den Takt uC ohne Quarz genauer einstellen ?
Gruß
Guenter
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
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
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.