UART bei ATTINY AVR 1 Serie (ATTINY 412)

[Gnom67]

Wollte Dir nicht auf die Füße treten ...
Bleiben ja nicht mehr viele Möglichkeiten. Hab ehrlich gesagt den Port-MUX bei diesem Controller nicht ganz verstanden (War in früheren Atmel-DBs einleuchtender
formuliert). Evtl. muß der Port auf alternative Nutzung gesetzt werden: PORTMUX.CTRLB |= 1; ?

mfg
Achim

Es gibt zwar ein Register PORTMUX CTRLB USART0 - aber laut Tabelle gibt es keine alternativen Ports...

IRRTUM!!!

In Atmel Start kann man Ports PA1/2 oder PA6/7 konfigurieren. Und siehe da, im Start-Mustercode finde ich, dass 6/7 die Standardkonfiguration ist und 1/2 (die einzige, die im Datenblatt steht) ist die alternative... als, Stecker in Pin 2 statt Pin 4 und hurra - es blinkt am USB-UART...
Empfang funktioniert allerdings nur bei 300 Baud, obwohl ich die Rechnung mit 19200 gemacht habe... das deutet doch irgendwie drauf hin, dass die Formel nicht stimmen kann (was ja schon wunderlich wäre, wenn man wiee gesagt bei 20 Mhz eine minimale Baudrate von 70K hätte). Mit der Baudrate tüftel ich jetzt noch etwas rum...

Danke für die Hilfe. Achim, den Portmux hätte ich nicht in Frage gestellt, wenn du das nicht noch mal aufs Tapet gebracht hättest...


Letzter Stand: Die Formel Stimmt - aber das Ergebnis wird schlicht und einfach in das 16-Bit-Register geschrieben und nicht in die oberen 10 Bit. Was der Schwachsinn im Datenblatt soll mit den 10 MSB und den 6 LSB (Seite 252) ist mir rätselhaft. Dieses miserable Datenblatt hat mich nun zwei Tage meines Lebens gekostet (zum Glück nur zwei eh ziemlich öde Weihnachtsfeiertage ).

[oberallgeier]

.. Dieses miserable Datenblatt ..

Ich war auch schon mal recht erbost über ein Datenblatt von Microchip Technology, bei dem die im Vorgänger von Atmel herausgegebene Dokumentation an einer völlig unnötigen und unschönen Stelle gekürzt wurde - nämlich bei benummerten Namen von Registerbits, z.B. bei TCCR1A werden die lediglich als COM1 beschrieben, müssen aber als COM1A0/~1 bzw COM1B0/~1 programmiert werden. Zum Glück hatte ich noch die alte Version von ATMEL gespeichert . . . Mein Kommentar dazu am microchip blieb bis heute (ziemlich genau 1 Jahr) unbeantwortet . . .

[Gnom67]

Ärgerlich, sowas!!! Kann doch nciht so schwer sein, solche Sachen mal zu korrigieren. Ich hab das Datenblatt bei Microchip direkt von der Website geladen. Die könnten das ruhig mal aktualisieren.

[wkrug]

Ärgerlich, sowas!!! Kann doch nciht so schwer sein, solche Sachen mal zu korrigieren. Ich hab das Datenblatt bei Microchip direkt von der Website geladen. Die könnten das ruhig mal aktualisieren.

Na ja, die Microchip Jünger haben die ATMEL Leute ja immer belächelt, denn "Bei Microchip ist ja alles viel Professioneller".
Ich fürchte auch, das es das ATMEL Studio auch nicht mehr lange geben wird und das dann in irgendeiner Microchip Variante mit eingebunden wird.

[Gnom67]

Hab etwas rumgegoogelt. Der halbwegs vergleichbare Attiny202/402 hat wenigstens die korrekten Belgungen der Mux-Tabelle. Dafür ist dort PA1 auf Pin 5 und PA2 auf Pin 4 angegeben - es ist aber andersrum und der Quatsch mit dem 10 und 6 Bits steht da auch. (Der Faktor 64 in der Formel ist wohl genau dieses Shifting der 6 Nachkommastellen in die unteren 6 Bits - man kann es auch kompliziert machen!) Dafür stimmt wengistens die Pinanordnung in der Pinout-Grafik (in beiden Datenblättern).

Atmel Start liefert die Pindaten ebenso falsch, wenn man in der Konfiguration die alternativen Ports PA1/2 wählt und sich das dann in der Pinmux-Übersicht anschaut. Zwar stimmt die Zuordnung der PAn, aber die Pinnummern stimmen nicht und die Grafik ist falsch.

Falls also noch jemand mal den UART eines neueren Tiny nutzen will:

Die UART-Standardbelegung des Attiny412 ist
Tx = PA6 = Pin 2
Rx = Pa7 = Pin 3
Die alternative Pinbelegung ist:
Tx = PA1 = Pin 4
Rx = PA2 = Pin 5
(Rx hab ich allerdings in beiden Fällen noch nicht ausprobiert...)

Der Berechnete Wert BAUD = (64 * CLK_PER) / (S * fBAUD), im NORMAL MODE = 4 * CLK_PER / fBaud wird ganz einfach in das 16-Bit-Regsiter BAUD geschrieben.

- CLK-PER ist der durch den Prescaler PDIV runtergeteilte Systemtakt (Standard also 3333333, weil 20000000 durch den Standard-Prescaler 6 geteilt wird).
- S ist 16 im NORMAL MODE und 8 im CLK2X MODE (letzteres hab ich nicht probiert).
- fBAUD ist die gewünschte Baudrate (9600, ...). Maximal müsste der Tiny 20000000/16 = 1250000 schaffen (NORMAL MODE).

Ich habs bis 500000 probiert - mehr macht mein Serial Monitor nicht mit. Die übertragung läuft über 10 Meter dünnen Schaltdraht einwandfrei. Der Interne Taktgeber reicht dafür offenbar aus - in der Hinsicht sind die AVR-1-Serie Controller wohl echt besser als die alten.

[wkrug]

Der Interne Taktgeber reicht dafür offenbar aus - in der Hinsicht sind die AVR-1-Serie Controller wohl echt besser als die alten.

Bei den Alten war die Geschwindigkeit des internern Oszillators stark von der Temperatur abhängig.
Nicht, das Du Dir da das nächste Problem einfängst.

[Gnom67]

Bei den Alten war die Geschwindigkeit des internern Oszillators stark von der Temperatur abhängig.
Nicht, das Du Dir da das nächste Problem einfängst.

Die neuen AVR 1 Series haben eine Kalibrierung und sind angeblich recht genau. Außerdem ist die Temperaturabhängigkeit zwischen ca. 10 und 70 °C nach der Zeichnung im Datenblatt relativ gering. Damit sollte es deutlich weniger Probleme geben als mit den alten AVR.
Die ersten Testübertragungen mit 500000 Baud über 10 m lütten Schaltdraht haben jedenfalls schon mal gut funktioniert. Hoffen wir also das Beste.