Atmega32U4 USART als SPI Master

Mit dem Mega8 funktioniert das im Anhang.

...

Thomas Frosch schrieb:
> Wie ich sehe misst du die Zeit der Impulse die der LM rausgibt. Das
> machst du aber nur um zwischen Zeilen und VSyncs zu unterscheiden oder?

Ups, ich habe Dir versehentlich eine alte Version geschickt. Darin habe 
ich mir V-Sync selbst gebastelt, weil ich zu blöd war, Rset am richtigen 
Pin anzuschließen und daher kein V-Sync bekam.
In der neueren Version wird V-Sync berücksichtigt, Foto und Skizze 
enthält diese Drahtbrücke aber noch nicht. Siehe neuen Quelltext.

> Habe mir auch schon überlegt ob es daran liegt, dass der LM zu ungenau
> ist und je nach Eingangssignal seine Schwelle mal früher oder später
> überschritten wird und deshalb die Zeilen wackeln.

Nein, der LM1881 ist da recht genau. Etwas Jitter kann es durch die 
unterschiedliche Interrupt-Response-Time geben, das habe ich aber 
dadurch verhindert, dass der Interrupt den AVR immer im Sleep 
überrascht. Die übrigen Arbeiten werden grundsätzlich nur außerhalb des 
Bildaufbaus erledigt, also immer nach der letzten Zeile, und auch nicht 
zuviel auf einmal.

>
> Ist das Signal des LM's genau genug?

Ja, ist genau genug.

> Habe die Frage allerdings
> zurückgestellt, da es so aussieht als würde nicht eine komplette Zeile
> wackeln sondern die einzelnen Buchstaben je Spalte unabhängig
> voneinander.

Naja, ich nutze die SPI-Einheit und nicht USART. Diese braucht 16 Takte 
zum Ausschieben, das SPDR ist aber erst nach 2 weiteren Takten wieder 
beschreibbar. Das war mir aber recht, denn ich habe zusätzliche Takte 
eingefügt, um den Zeichenabstand zu vergrößern. Mein OSD wird im 
Amateurfunk (ATV-Relais) eingesetzt, da wird große, gut lesbare Schrift 
gebraucht. Der Textbereich wurde bewusst auf 10 Zeilen je 32 Zeichen 
begrenzt.

>
> Es handelt sich bei mir um ein Projekt, dass leider schon am Ende steht.
> Hardware ist bereits vorgegeben, kann also nicht auf anderen Aufbau und
> Software switchen. Software funktioniert bisher auch sehr gut. Das
> bewegen der Buchstaben ist meine einzige Sorge.

Nunja, Du benutzt USART, ich benutze SPI. Inwieweit USART für SPI taugt, 
weiß ich nicht, hat mich noch nie interessiert.

>
> Nochmal die Frage: Können Befehle aus irgendwelchen Gründen mal einen
> Takt länger brauchen?

Da ist mir nichts bekannt, zumindest, was ASM betrifft. Die 
Interrupt-Response-Time ist aber variabel, wenn sich die CPU nicht im 
Sleep befindet.

Du schreibst von Sperren des Interrupts durch cli() und sei(). Das mache 
ich nicht, Interrupt-Aufrufe sind immer erlaubt.

...

Thomas Frosch schrieb:
> Also ich benutze nicht direkt USART. Der Atmega32U4 bietet die
> Möglichkeit den UART als zusätzlichen SPI Master zu verwenden.

Das können die von mir verwendeten AVRs nicht, also kann ich dazu 
mangels Erfahrung nichts sagen. Ich werde mich auch nicht mit diesem U4 
beschäftigen, da ich ihn nicht auf selbstgeätzte Platinen löten kann. 
Man kann eben nicht alles haben...

> Ich
> benötige den normalen SPI noch damit ich das OSD als Slave ansprechen
> kann.
>
> Ich benutze auch den Sleep Modus!

Hmmm, das hier liest sich aber anders:

1

In der while Schleife des Programms wird ein Flag abgefragt. Ist dieses

2

1 wird angefangen eine Zeile zu schreiben. Das heißt einlesen eines

3

Bytes und senden per SPI und das ganze 40 mal hintereinander (per while

4

Schleife).

Das sieht bei mir anders aus. Der CPU-Takt ist aufgrund Sleep aus. Die 
Zeile wird per Interrupt vom H-Sync-Signal gestartet. Dadurch, dass die 
CPU im Sleep war, ist die Interrupt-Response-Time immer gleich. Würde 
der Interrupt während der Abarbeitung einer Endlosschleife auftreten, so 
wäre die Response-Time variabel, da ja die CPU erst ihren angefangenen 
Befehl fertig abarbeitet.

>
> Nach langem rumprobieren scheint es, dass wenn man vor dem senden über
> die USART-SPI das TXFlag löscht es besser funktioniert! Die Buchstaben
> hibbeln nun nicht mehr aufeinander zu. Allerdings hibbelt es trotzdem
> weiter. Dies führe ich jedoch eher auf die Syncs einer Zeile zurück.
> Ganz sicher kann ich mir dabei aber auch nicht sein. Vorallem wenn du
> schreibst das Signal über den LM ist ziemlich genau. Die Frage ist
> wieviel Jitter ist für dich wenig?

Der LM1881 arbeitet vermutlich genauer, als es der AVR erfassen kann. 
Denn die I/Os und auch die externen Interruprs (zu denen auch ICP zählt) 
werden vom Takt gesteuert. Somit wird das Eingangssignal im Takt des 
AVRs gerastert. Ein AVR-Takt ist aber immerhin 1/16 der Zeichenbreite. 
Somit ist ein Jitter von 1/16 der Zeichenbreite hinzunehmen. Da H-Sync 
aber nicht auf das Zeichen wirkt, sondern auf die Pixelzeile, gibt es 
keinen Jitter zwischen den Zeichen, sondern zwischen den Zeilen der 
Zeichen.

Mit meiner Interrupt-Methode rastere ich auf den Controllertakt, also 
1/16 Zeichenbreite. In einer Warteschleife

Label:
 sbis pin_x,bit_y   ;2 Takte wenn Skip, sonst 1 Takt
 rjmp Label         ;2 Takte
 ;Zeile ausgeben...

kann das Signal nur in jedem dritten Takt erfasst werden. Somit erhöht 
sich der Jitter auf 3/16 der Zeichenbreite.

>
> Ich sehe das Bild in meinem Grafikartenmodus (also nicht OSD sondern
> eigene Syncerzeugung) und das steht ohne kleinstes zittern und dann
> schalte ich um auf OSD und es jittert etwas. Das nächste ist auch, dass
> ich um das Flag zu löschen nun natürlich etwas länger brauche und
> dadurch der Abstand zwischen den Buchstaben größer wird. Zudem kann ich
> natürlich auch nicht mehr soviel Zeichen in eine Zeile bekommen (Anfangs
> 42 nun noch 32). Ich lese über einige Pointer aus dem Programmspeicher
> da dort das Charset liegt.

Einige Pointer?
Der AVR hat nur einen Pointer, der aus dem Flash lesen kann, nämlich den 
Z-Pointer. Das Charset umfasst 256 Zeichen, diese sind so angeordnet, 
dass in jeder 256-Byte-Page eine Pixelzeile aller Zeichen enthalten ist. 
Somit entscheidet ZH über die Pixelzeile und ZL über die 
(ASCII-)Zeichennummer. Beide Bytes des Pointers werden separat gesetzt, 
der Zugriff erfolgt (per LPM) über nur einen Pointer. Da ist nix mit 
"lese über einige Pointer aus dem Programmspeicher".

> Das SPI mehr als 16 Takte braucht ist klar + 2 für das "9te" Pseudo Bit
>
> Also TXC1 aus UCSR1A löschen dann gehts wesentlich besser.
> Seltsam ist nur, dass das nur was ausmacht, wenn der externe Interrupt
> an ist, ansonsten nicht????

Bei mir ist während der Ausgabe einer Videozeile kein externer Interrupt 
an. Der ICP (auch nur ein externer Interrupt mit Zusatzfeatures) 
detektiert das H-Sync-Signal, die Ausgabe der gesamten Pixelzeile 
erfolgt in seiner ISR. Während der ISR ist der Aufruf weiterer 
Interrupts gesperrt, es ist alsi nichts da, was das Timing zwischen den 
Zeichen stören könnte.

>
> Du hast nicht zufällig ein Video von deinem OSD Bild? mich würde mal
> interessieren wie gut dein Jitter ist.

Nein, habe ich nicht. Werde ich auch nicht machen, weil ich keine 
Hardware mehr habe und deswegen auch keine neue Hardware aufbauen werde. 
Die Hardware habe ich dem Funkamateur übergeben, für den ich das 
Programm schrieb. Die Sache ist seit fast 3 Jahren für mich erledigt, 
ich brauche selbst weder ein OSD noch eine "Grafikkarte" für AVRs. Denn 
ich bastele nicht mit TV, Video und ähnlichen Dingen, das ist einfach 
nicht mein Gebiet.

> Vielleicht bin ich ja nur zu
> knausrig. Blöd ist halt der Vergleich zum Grakamodus. Da ists einfach
> perfekt.

Das ist ja kein Wunder. Da erzeugst Du ja das Timing selbst und musst 
kein externes Timing synchronisieren.

Überprüfe doch bitte nochmal, ob (wie Du sagst) die ganzen Zeichen 
gegeneinander zittern, oder ob die ganzen Pixelzeilen gegeneinander 
zittern. Denn dass die ganzen Zeichen gegeneinander zittern, halte ich 
für sehr unwahrscheinlich. Es werden wohl die Pixelzeilen sein, die 
Ursache liegt vermutlich in der verschenkten Auflösung aufgrund der 
Abfrage in der While-Schleife.

...