Hallo Benedikt

Respekt !!

Dein Programmcode ist wirklich sehr kurz, gefällt mir.


Bernhard

>Insgesamt stecken da bestimmt schon >100h Arbeit dahinter.

Bei mir ebenso,

hab' gerade mal in Deinen Thread geschaut

http://www.mikrocontroller.net/forum/read-1-290388.html

Dort stellte ich meine erste peinliche Frage, das war vor ca. 4Wochen.

Dein Thread inspirierte mich nicht nur, sondern half mir auch weiter.


>Irgendwann baue ich da noch "Big Numbers" ein, die gefallen mir bei
>deiner Software

Ja ja, die "Super Big Numbers" , die haben Ihre Vorteile, besonders
bei Präsentationen ;)





Bernhard

Mit der bisherigen Version geht das nicht, aber mit der Version im
Anhang sollte das möglich sein.

Ich hab da was relativ ähnliches gemacht, nur bin ich schon recht früh
auf den ATMega16 umgestiegen.

Die Idee mit dem SPI ist schon sehr schick. Ich habe das noch mit
Schiebebefehlen erledigt. Nur schade, dass der SPI nicht auch mit einer
höheren Taktrate laufen kann.

Das mit der Jitterkorrektur ist auch toll.

Mein ähnliches Projekt ist hier:
Beitrag "Bild und Ton mit ATMega16"
Es funzt aber nur auf dem ATMega16 weil mein Programm inzwischen zu groß
geworden ist.

Es hoffe es stört Dich nicht wenn ich den Algorithmus unter
Namensnennung in mein kleines GPL-Projekt übernehme. Du kannst ja auch
meinen Tonerzeuger übernehmen.

Farbe müsste übrigens, ganz grob skizziert so gehen:


hloop:                                          ;Loop f<FC>r 1 Zeile
        ld ZL, X+                               ;ASCII aus RAM lesen
2
        lpm tempi, Z                    ;Byte aus CGROM lesen   3
        SBRC tempi,7 ; Skip wenn Bit 7 nicht gesetzt
        OUT PORTC,tempi
        out DDRB, spiaus                ;SPI aus, Port an
1
        out SPDR, tempi                 ;Byte ausgeben
1
        out DDRB, spian                 ;SPI an, Port aus
1


An die untersten Bits hängst Du dann eine Schaltung dran, die die Farbe
macht. Die erhält 7 Bits, sowie das Ausgangsbit deines SPIs.
Die Farbe schaltest Du mit einem Byte im Speicher um, welches Bit 7
gesetzt hat. Natürlich kannst Du das noch quasi beliebig verfeinern.

Kannst du kurz nen Schaltplan dazu zeichnen wie das ausehen müßte?

Ach ja hat jemand das ganze schon für den Mega16 portiert?
Im Prinzip müßte amn doch nur die Pins für OCRA und für das SPI anpassen
oer gibts noch mehr zu beachten?

So etwa. Leider hat der ATMega8 nur einen Port C. (Port D benutzt du ja
schon wahrscheinlich) Grob gesagt kommt in die einen 3 Bit die
Vordergrundfarbe, in die anderen die Hintergrundfarbe.
Die Schaltung gibt dann RGB an den Ausgängen ganz rechts aus. Jedes
neuere Farbfernsehgerät hat die entsprechenden Eingänge an der
SCART-Buchse.

Möchtest Du PAL haben, so wird das etwas schwieriger. Du müsstest
eventuell noch einen Port dafür opfern. Und Du bräuchtest einen
Oszilator, der auf der Farbunterträgerfrequenz, oder einem Vielfachen
dieser Frequenz schwingt.

Warum wird denn eigentlich so lange gewartet? Eigentlich könnte man doch
das nächste Zeichen schon nach 16 Taktzyklen an das SPI schicken? Oder?

Du meinst, wiso erst nach dem 18. Takt ein neues Byte rausgeschoben wird
?
Das SPI Interface braucht leider 18 Takte. Schreibt man das Byte zu
früh, wird es ignoriert.

Hmm, das lässt meine Träume von der perfekten Bildwiedergabe wieder
platzen. Und wahrscheinlich ist das letzte Bit dann auch noch high und
deshalb machst Du die Klimmzüge mit dem 2. Port. Naja, mit der
Ausgangselektronik kann man ja deinen Port invertieren, so dass man high
als Hintergrundfarbe hat.

Naja, mehr als mit meiner Lösung ginge jedenfalls.

Genau so ist es.
Anfangs hatte ich deshalb einen Inverter dran, aber um Bauteile zu
sparen schalte ich den Ausgang auf den anderen Port um.
Besser als mit einem AVR geht es mit einem ARM von Philips/NXP: Dieser
besitzt eine 16bit SPI Schnittstelle die lückenlos Daten ausgibt.
Zusätzlich gibt es noch ein FIFO. Durch die 16bit und das 8Word FIFO
kann man auf einmal  128 Pixel schreiben die dann von alleine ausgegeben
werden.

Man könnte eventuell sich Speicher sparen, in dem man ein
"newline"-Zeichen einführt. Wird dieses Zeichen gelesen, so wird
nachgeschaut, ob man denn in der letzten Zeile der Textzeile ist, wenn
nein, so wird der aktuelle Zeilenstart zurückgesetzt, wenn ja, so lässt
man die aktuelle Position auf dem nächsten Zeichen und springt aus der
ISR. Im RAM hättest Du dann so etwas ähnliches wie eine Textdatei.
Halbvolle Zeilen brauchen dann auch viel weniger Speicher.

Ich hoffe, dass ich im Februar dazu komme, da etwas rumzuspielen.
Was gehen sollte ist etwa das:
* 8 Vordergrund Farben
* 8 Hintergrund Farben
* Blinken
* Doppelte Höhe
* Doppelte Breite
* Benutzerdefinierte Zeichen

Grob gesagt sollte man einen kompletten "Videotext"-Dekoder damit machen
können. (zumindest die Textdarstellung davon)

Naja, die ARM-Prozessoren wären da schon ziemlich schick, wobei man das
dann da schon fast interruptgesteuert machen müsste. Der Vorteil an den
Prozessoren ist dann halt, dass man auch gleich Linux darauf laufen
lassen kann. :)

Und gut, wenn der SPI 9 Bit an Zeit braucht, dann machen wir halt einen
9 Pixel Font. :)

Hmm, gut, dann gingen also doch 8 Pixel pro Zeichen. Mir geht es darum,
dass ich eine Anzeige mit 320x240 Pixeln habe und darauf 40 Zeichen pro
Zeile darstellen möchte. Eventuell 40x15 Zeichen mit einer schönen 8x16
Schriftart.

Die 8 Zeichen funktionieren nicht so richtig, man bekommt nach jedem
Schiebevorgang eine Lücke, und zwar aus folgendem Grund:
Sagen wird mal man schaltet das SPI nach 16 Takten aus, und anschließend
wieder ein, dann hat man 2 Tajte für das aus und einschalten benötigt.
Man benötigt also immer 2*n+2 Takte, egal ob mit oder ohen Ausschalten.
Man kann so 6+1 Pixel darstellen, erhält aber nach dem 6. Pixel dann
eine Lücke von 1 Pixel.
Das einzige was funktioniert: Das Interface nach 7 Takte ausschalten,
und den 8. Pixel per Software auf den Port legen.

Jungs, macht doch das SPI zu Fuß ...
dann könnt Ihr die Zeichen ausgeben wie Ihr wollt.
4 Bit , 8 Bit , 9 Bit oder 21 Bit.
So schwer isses ja nich

@stephan
Wenn du in der Lage bist ein Programm zu schreiben, dass jeden 2. CPU
Takt ein Bit an einen Port legt, gleichzeitig noch alle 16Takte ein Byte
aus dem RAM läd, dann dieses als Offset benutzt und so ein Byte aus dem
Flash läd, ohne dass die Datenausgabe jeden 2. Takt unterbrochen wird,
dann kannst du es  so machen. Wir können das aber nicht...

Wenn alle Pixel gleich breit sein sollen, braucht man 4 Takte je Pixel,
braucht man nur reine Textdarstellung, kann man das lpm in den dunklen
Zwischenraum legen und braucht nur 3 Takte je Pixel. Wenn man auch noch
das  Laden aus dem RAM in den Zwischenraum legt, braucht man zwar nur 2
Takte je Pixel, die Abstände sind aber dann so groß, dass mehrzeiliger
Text nicht mehr angenehm lesbar ist.

Stephan Henning wrote:
> Jungs, macht doch das SPI zu Fuß ...

So mach es ich im Moment. Das funktioniert recht gut. Man bräuchte
jedoch 3 Taktzyklen pro Pixel um perfekte Pixel auszugeben. Meine Lösung
braucht 17 Taktzyklen für 8 Pixel.

Der Vorteil an der SPI-Lösung ist aber, dass man sehr viele freie
Taktzyklen hat. Man kann wirklich was machen und nicht nur einen Wert
aus dem Speicher laden. In diesen Taktzyklen kann man Dinge wie Farbe
unterbringen, oder auch andere Effekte.

Zum (ungefähren) Messen der CPU-Belastung ist es am einfachsten, zu
Beginn der Interrupt-Routine einen Pin auf 1 zu setzen und vor dem RETI
wieder zu löschen. Mit einem einfachen Vielfachinstrument die Spannung
am Pin messen und mit 20 multiplizieren...

Das mit dem Pin ist die einfachste Möglichkeit, so messe ich es auch
meistens. In diesem Fall habe ich aber gerechnet:
Pro Bildzeile werden 45us lang Daten ausgegeben, das macht etwa  70%
Aulastung.
Von den 312,5 verfügbaren Bildzeilen werden nur etwa 250 genutzt.  Das
macht 20% nahezu komplette Freizeit für den uC (bis auf dem HSync). Dazu
kommen nochmal die 30% Freizeit während der Bildausgabe. Macht also
etwas über 40% Freizeit für den uC. Demzufolge hat der uC etwa 60%
Auslastung.

Hallo Benedikt

Wirklich super dein Videogenerator,
Leider für mich als Anfänger etwas sparsam dokumentiert ;)

Ich habe noch ein Carriage Return Funktion mit Reingebastelt.

Ups... Habe eine Verzweigung falsch geschrieben...

Hier die korrigierte Fassung

Grüße
Björn

noch ein paar Bugfixes..

Und die Cursorposition ist jetzt Sichtbar :)

Da ich leider gerade keinen Mega8 zur Hand hab das ganze aber doch mal
gern Probieren wollte, mal meine Frage, was muss man tun um das ganze
für den Mega16 anzupassen?

Läubi Mail@laeubi.de wrote:
> was muss man tun um das ganze
> für den Mega16 anzupassen?

Wahrscheinlich sehr wenig. Du musst nur bedenken, dass der die Pins wo
anders hat.

Ja also seh ich das richtig das nur die SPI Pins wichtig sind, der Rest
halt Variabel? Weil zwei pins sind ja zusammengeschltet und mir ist
nicht ganz klar ob da ein belibiger Pin genommen werden kann.

Nur das SPI ist fest, SS sollte noch auf Ausgang stehen, der rest ist
variabel.

Letzter Stand:
Das ganze ist jetzt ein brauchbarer Bildschirmeditor geworden.
Die Cursortasten werden jetzt auch abgefragt (VT100)
Weitere kleine Bugfixes und Optimierungen
Die Zeilen sind fast alle kommentiert

Danke Dir Benedikt, für dieses Projekt. Das ist zum Assemblerlernen für
mich genau das richtige :)

Was ich noch plane:


Scrolling

Senden des Bildspeichers über UART (Hardcopy)

Befehlsinterpreter um die Ausgänge von Port B zu steuern oder den ADC
auszulesen (...naja muss ich noch viel lernen)

Portierung auf Mega16

Grüße
Björn

Björn Wieck wrote:
> Was ich noch plane:

> Scrolling

Das mache ich über Zeiger, die auf die einzellnen Zeilen zeigen, dadurch
muss ich nur wenige Bytes rumschieben.

> Senden des Bildspeichers über UART (Hardcopy)
>
> Befehlsinterpreter um die Ausgänge von Port B zu steuern oder den ADC
> auszulesen (...naja muss ich noch viel lernen)

Da gibts Forth Compiler für den ATMega 16.
Die laufen dann direkt auf der Kiste.

Habs jezt mal "portiert"...
Leider ist das Ergbniss nicht so überzeugend, frage liegt das an mir
oder mag meine TVKarte das nicht so?

Habe im Quellcode aus tvtext.zip nur folgendes geändert:
;PortB
.equ   DOUT  =3
.equ   Sync  =5
.equ   MOSI  =5
.equ   MISO  =6
.equ   SCK  =7
Ansosnten mich an den Schaltplan gehalten, auser das ich nen 16mhz
Ozilator benutze. (CLK FUses 0000 beim Mega16)

Bild vergessen...

Läubi Mail@laeubi.de wrote:
> Habs jezt mal "portiert"...
> Leider ist das Ergbniss nicht so überzeugend, frage liegt das an mir
> oder mag meine TVKarte das nicht so?

Ich glaube dein Timing ist falsch.

Naja ich hab ja sosnt nix verändert an der Schaltung :(
Deswegen frag ich ja ob meine "portierung" so in Ordnung ist?

OK, dann überprüf das Bild mal mit einem normalen Videomonitor. Ist da
das Problem auch so? TV-Karten sind in der Regel nicht wirklich für das
geeignet. Du kannst aber auch probieren die TV-Karte bewusst auf PAL
einzustellen.

Eigentlich sollte das Timing sich nicht durch die Portierung ändern. Die
Controller sind sehr ähnlich.

Habe leider keinen Fernsehe... Habs mal an den Vidorecorder gehängt und
dann über Antennenausgang auf die TVKarte... selbes Problem :(

Wenn du Sync und MOSI auf den selben Pin legst ist das kein Wunder...

Ach ja schreiben ist schwer, dafür siehts jezt so aus.
immerhin schonmal nen Fortschritt... hab nochmal überprüft obs auf
Externen Ozilator gestellt ist sieht in Ordnung aus... hm..

hab mal alle rjmp durch jmp ersezt... hat jezt leider auch nix bewirkt

Beschreib mal die Schaltung die du verwendest hast (an welchem Pin hängt
was und schreib nochmal die Belegung von PortB in der Software.

Okay.

- Mega16 mit normaler Beschaltung und 16Mhz Quarzozilator
- Softwareänderung
 ;PortB
 .equ   DOUT  =3
 .equ   Sync  =4
 .equ   MOSI  =5
 .equ   MISO  =6
 .equ   SCK  =7
- Hardware:
 Ein Chinchkabel zum Videorecorder AV-In
 ein 100 Ohm zwischen GND und Signal
 330 Ohm von Pin6 (PB5 MOSI) zum Signal
 1k Ohm von Pin5 (PB4 SS) zum Signal
 eine Brücke von Pin4 (PB3) zu PB5

Alles noch son bischen zusammengebastelt aufm Lochraster.

Anscheinend sind der Mega8 und der Mega16 im Timing doch
unterschiedlich.
Ich habe jetzt mal das ganze in einen Meag16 geflasht
Pinbelegung und .def wie bei Läubi und das Bild ist stark verzerrt und
läuft durch...

Muss mal an den Widerständen experimentieren. Eventuell liegts ja daran

Grüße
Björn

Vieleicht hab ich beim konvertieren auch einfach blödsinn gemacht oder
irgenwas nicht beachtet BAS ist leider nicht mein Gebiet :-\

Kann es ggf an den Timern liegen?
Wobei ja beide Timer1 bei Mega8 und Mega16 gleich sind (zumindest macht
es den Anschein)

Ich hab sowieso nochmal zwei fragen zum code:

ldi temp, (1<<WGM12)|1 ;10bit PWM bei 16MHz: 15,625kHz

Sezt das nicht temp auf 0xFF ??

ldi temp, (1<<SPE)|(1<<MSTR)|(1<<CPHA)  ;fclk/2 Schiebetakt
out SPCR, temp          ;Enable SPI Slave, Interrupt
sbi SPSR, SPI2X

Ist der Kommentar bezgl des Interupts falsch?
Weil ja für SPI Interupt garkein Vektor exitiert!

Also, wenn ich mir das Bild noch einmal anschaue, glaube ich eher, dass
irgendwie deine TV-Karte nicht richtig mit dem Signal zurechtkommt. Hast
Du denn nicht irgendwo ein echtes Fernsehgerät?

Habs wie gesagt mal am Videorecorder gehabt --> selbes resultat, nur
damit kann ich nicht so leicht ne Bildschirmphoto machen ;)
Björn Wieck hat ja das selbe Problem etwas weiter oben festgestellt, ein
"echtes" Fernsehgerät besitze ich lieder nicht.

Ob das Signal durch den Videorekorder durch geht oder nicht, ist (fast)
völlig irrelevant. Der macht nichts mit dem Signal. Vielleicht stimmen
auch deine Pegel nicht. Bist Du sicher, dass deine Widerstände stimmen?
Schalte mal in einem kleinen Testprogramm einfach einen Port ein und
miss dann die Spannungen. Dabei sollte natürlich das Gerät noch
angeschlossen sein.

Dann schalte deine TV-Karte fest auf PAL.

Ich kann mir eigentlich nur vorstellen das es am Timing des Mega16
liegt.
Ich habe mit exakt den gleichen Widerständen am Mega8 direkt auf einem
Videomonitor (alter C64 Monitor) ein glasklares Bild...
Die Ausgangspegel sind ja eh bei beiden AVR´s gleich.

Desweiteren läuft mit dem Mega16 bei mir das Bild neben den Verzerrungen
durch was direkt auf einen falschen VSync hinweist.

Könnte es was mit dem JTAG-Interface zu tun haben ?


Grüße
Björn

JTAG muss aus sein, sollte aber trozdem nicht das Shiftregsiter
beinflussen, das liegt ja alles auf  PortB.
Und der Videorecorder Sezt das Signal doch um auf Antenne also ich glaub
nicht das der das PAL Signal direkt auf den Antenneausgang schleift.
Und wie björn doch shcon erwähnte Mega8 --> Geht, Mega16 --> geht nicht.
Frage ist halt warum! Und die WIderstände hab ich so wie oben im
Schaltplan angegeben gewählt.

Ich werde heute abend mal mit dem Oszilloskop nachschauen wie das Timing
zwischen den beiden Megas aussieht. Die Ergebnisse mit Bildern stelle
ich dann allerdings in den "µC & Elektronik" Bereich. Dort passt es
besser.

Grüße
Björn

Super! Ich schau dan da mal rein, werde auch nochmal ein bsichen mit dem
Programm rumspielen ob sich was tut.

Hallo Läubi,

Ich bin noch nicht dazu gekommen zu messen, allerdings habe ich mal auf
die schnelle was anderes probiert:

Ich habe mal von PortB auf PortD umgeschwenkt weil wie bei Mega8 dann
DOUT und SYNC an OC1A und OC1B liegen. MOSI kann ich so natürlich nicht
benutzen und das hat dann zur Folge das ich keine Zeichenausgabe mehr
habe weil die Pixeldaten für die Zeichengenerierung aus dem SPI
Schieberegister kommen.
Benedikt möge hier was dazu sagen wenn ich falsch liege.

Aber was ich damit erreicht habe: Das Bild ist absolut Stabil und die
Füllpixel werden richtig angezeigt. Das sollte Beleg genug sein um zu
behaupten das das Timing am PortB des Mega16 anders ist.
Jetzt muss ich eigentlich nur noch einen Weg finden um MOSI wieder mit
ins Boot zu bekommen und dabei die IRQ-Routine von Benedikt nicht
allzusehr zu verbiegen (sonst passt das Timing auch nicht mehr).

Grüße
Björn

Hallo Björn,

Danke für deine Mühen. Vieleicht weiß Bendikt ja auch wo man das Timing
auf die Mega16 werte anpassen kann?
Ich hatte auch shcon etwas rumgepielt aber nur mit dem Ergebniss das es
garnichtmehr ging :(
Oder man versucht deine Konfiguration und nimmt nur noch das MISO dazu?
Merkwürdig find ichs allerdings schon irgenwie...

Was ich jetzt eigentlich ganz naiv immer noch nicht verstehe. Wozu sind
die Füllpixel gut? Wäre es denn nicht einfacher einfach dunkle Zeichen
auf hellem Grund darzustellen und den SPI in den leeren Bildbereichen
einfach auszuschalten?

Wenn ich dazukomme probiere ich das ganze heute mal mit einem mega16
aus.

Die Ausgabe von schwarzen auf weisen Zeichen wäre einfacher. Mir gefällt
das aber nicht, und es ist nicht allzu schonend für den TV wenn er die
ganze Zeit volles weiß darstellen soll.

Dem Fernsehgerät ist es ziemlich egal, wie Du die Zeichen darstellst,
nur bewegen sollte sich halt was :)

Björn Wieck wrote:

> Ich habe mal von PortB auf PortD umgeschwenkt weil wie bei Mega8 dann

> Aber was ich damit erreicht habe: Das Bild ist absolut Stabil und die
> Füllpixel werden richtig angezeigt. Das sollte Beleg genug sein um zu
> behaupten das das Timing am PortB des Mega16 anders ist.

Moment, wenn das Fernsehgerät nicht richtig synchronisiert bedeutet dass
noch längst nicht, dass da irgendwelches Timing von Ports falsch ist.
Ich meine ein Port ist ein ziemlich einfaches Gebilde, das nicht einfach
so Pulse zeitlich verschieben kann. Nach Deiner Beschreibung erscheint
es mir viel wahrscheinlicher, dass Du deinen Port B einfach geschossen
hast. Das geht ziemlich schnell und ist mir auch schon passiert.
Seltsamerweise war das bei mir auch Port B.

Christian Berger wrote:
> Dem Fernsehgerät ist es ziemlich egal, wie Du die Zeichen darstellst,
> nur bewegen sollte sich halt was :)

Und genau das ist das Problem: Die Füllpixel sind immer an der selben
Stelle und brennen daher ein !


So, hier die Software für mega16 und mega 8 (define ganz oben).
Das Problem lag am Sync Signal. Ich hatte nicht mehr daran gedacht, dass
ich dieses per Hardware mittels OCR1B erzeuge. Beim mega16 muss man Sync
daher an PD4 abholen.

Benedikt K. wrote:

> Und genau das ist das Problem: Die Füllpixel sind immer an der selben
> Stelle und brennen daher ein !

Theoretisch ja, aber in der Praxis sind die Bildröhren jedoch so
ungenau, dass diese Füllpixel immer an anderen Stellen sind. Schau Dir
nur mal einen Fernsehsender mit Logo an. Das Logo bewegt sich mit
wechselnder Bildhelligkeit. Nebenbei ist das Einbrennen heute kaum mehr
ein Problem. Es wird nur dann ein Problem, wenn Du über Tage hinweg ohne
Unterbrechung präzise das gleiche Bild darstellst.

> So, hier die Software für mega16 und mega 8 (define ganz oben).
> Das Problem lag am Sync Signal. Ich hatte nicht mehr daran gedacht, dass
> ich dieses per Hardware mittels OCR1B erzeuge. Beim mega16 muss man Sync
> daher an PD4 abholen.

Ohh, an das habe ich auch schon gedacht, der Fehler erschien mir aber zu
simpel. :)

Benedikt K. wrote:

> So, hier die Software für mega16 und mega 8 (define ganz oben).
> Das Problem lag am Sync Signal. Ich hatte nicht mehr daran gedacht, dass
> ich dieses per Hardware mittels OCR1B erzeuge. Beim mega16 muss man Sync
> daher an PD4 abholen.


Jaa, genau sowas habe ich auch schon vermutet und deswegen mal testweise
PortD (eben wegen OCR1) benutzt...

Danke für den Code.

Grüße
Björn

SUPER! Probier ich gleich nachm Einkaufen mal aus :)

ES GEHT!!! Super danke für die Mühen, das rockt echt :)
Sieht zwra auf dem capture etwas verauscht aus, aber das ist wohl weil
ich nur ein halbbild digitalisieren.
Aufjedenfall ist das Bild stabil und lesbar.

Läubi Mail@laeubi.de wrote:
> Sieht zwra auf dem capture etwas verauscht aus, aber das ist wohl weil
> ich nur ein halbbild digitalisieren.

Nein, das liegt daran, dass dein Computer meint, da sei ein Farbsignal
und somit versucht ein nicht-existentes Farbsignal zu demodulieren. Ich
tippe mal darauf, dass Deine Karte auf SECAM steht. Stell die auf PAL
und probier es erneut.

Hallo zusammen,
  erstmal ein RIESEN Lob an alle aktiven Programmierer. Die Bilder sehen
ja echt super aus... ich hoffe das Programm bald selbst testen zu
können.
Was ich echt unglaublich finde ist die geringe Codemenge... der meiste
Speicher wird ja vom CGROM belegt. Nun zu meiner Frage (ich traue mich
kaum zu fragen):
  Wäre es denkbar, daß der interne 8MHz Taktgeber vom Tiny2313 genau
genug für das Programm ist? Wenn ich das richtig gesehen habe (ich hab
nur kurz in die Datenblätter geschaut) dann sind die Timer1 bei beiden
Controllern identisch, oder?
Wenn ich also das CGROM etwas kürzen würde, dann sollte mit anpassung
des Timings das Programm doch auch mit einem Tiny2313 mit internem Takt
laufen.
Leider kenn ich mich mit Videosignalen nicht gut aus und hoffe ihr könnt
mir ein paar kurze Tipps geben, wo ich einen Denkfehler habe... oder ob
das eventuell doch geht.
Schonmal Vielen Dank und


Gruß,
  SIGINT

Sigint 112 wrote:

> Wenn ich also das CGROM etwas kürzen würde, dann sollte mit anpassung
> des Timings das Programm doch auch mit einem Tiny2313 mit internem Takt
> laufen.

Hmm, erstmal gingen da nur 20 Zeichen pro Zeile bei 8 MHz. Die sollte
man aber machen können. Der Tiny2313 hat aber leider keinen SPI.
http://www.atmel.com/dyn/products/product_card.asp...
Allerdings sollte man den USI auch so nutzen können. Das größere Problem
ist, dass Du nur 128 Bytes an RAM hast. Das kannst du aber mit
geschickteren Befehlen prinzipiell auch noch machen.

Übrigens ich habe vor mal etwas mit dem ATtiny 11 zu spielen. Das ist
ein kleines Teil. :)

Ich würde den tiny11 nicht verwenden: Der tiny25/45/85 ist der größe
8pinner mit vielen Features. Der tiny11 dagegen hat nichtmal ISP...

Mit dem tiny85 mit 512Bytes RAM und PLL (also 16MHz internem Takt) kann
man mit ein paar Tricks sicher auch was schönes machen. Zumindest für
30x15 Zeichen sollte der reichen. Allerdings bringt eine Textdarstellung
nicht wirklich viel, da es kein Inteface gibt mit dem man den Text da
reinbekommt. Nur der ADC wäre als Eingang brauchbar. Aber das wär doch
mal was: Ein TV-Oszilloskop das nur aus einem 8Pin AVR und ein paar
Widerständen besteht.

Die Timer sind übrigends nicht wirklich gleich: Selbst zwischen mega8
und mega16 gibt es Unterschiede bei den Timern: Laut Datenblatt wird
beim einen bei PWM der Pin beim maximalen Wert gesetzt, beim anderen
dagegen beim minimalen. Bemerkbar macht sich der eine Takt aber nicht.

Ja, aber die sind relativ teuer. Der Tiny11 kostet halt nur 60 cent. Das
kann ich mir selbst als Student noch leisten. Ich habe es gerade
durchgespielt für 2x4 "7-Segment"-Anzeigen auf dem Bildschirm sollte der
völlig reichen.

Und so etwas wie serielle Schnittstellen kann man auch so nebenher
emulieren. :)

Auf dem 85ger geht wahrscheinlich dein Trick mit der PWM nicht so
elegant. Der hat nur 2 8Bit Timer.

Um ein Osziloskopbild auszugeben bräuchte man wohl etwa 7 Taktzyklen pro
Pixel. (wenn man das Bild nicht um 90 Grad dreht) Der Code wäre etwa so:

LD r1,X+  ;Wert für aktuelle Spalte holen 2
CP r1,r2  ;Mit Wert für Zeile vergleichen
LD r3,r4  ;r4 enthält Farbe für ungleich
Skip_if_equal  ;Zu faul Befehl zu suchen, evtl breq oder sowas
LD r3,r5  ;Farbe für gleich
OUT ,r3

Das schreibst du dann entweder 100 mal rein, oder benutzt eine Schleife.

@Christian:
   Uiii, hab ganz übersehen, daß der Tiny kein SPI hat... aber laut
AVR319 kann man den USI als SPI nutzen. (könnte also gehen)
Das der Tiny etwas wenig RAM hat ist klar... ich wollte auch nur 4
Zeilen a 20 Zeichen darstellen. Ich werd mich dann irgendwann mal mit
dem Code auseinandersetzen und schauen,ob ich das irgendwie abgeändert
bekomme.
Bei Fragen weiss ich ja, wo ich mich melden kann ;)

@Benedikt:
  Das mit dem Oszilloskop mit nem 8pin AVR würde mir echt gefallen... da
könnte man echt schöne Spielerreien mit machen :)))

Gruß,
  SIGINT

Ich hab das Oszi mal programmiert. In der kurzen Version besteht es aus
etwa 100Befehlen (200Bytes) und hat 80x256 Pixel Auflösung.
In der schnellen Version sind 120x256 Pixel Auflösung möglich, der
tiny25 ist  nahezu voll.
Das ganze funktioniert eigentlich wunderbar, Samplerate ist 15,625kHz,
allerdings werden eben nur die Samplepunkte dargestellt, aber nicht die
Linien dazwischen, was bei Frequenzen >1kHz etwas komisch aussieht.

Benedikt K. wrote:
> Das ganze funktioniert eigentlich wunderbar, Samplerate ist 15,625kHz,
> allerdings werden eben nur die Samplepunkte dargestellt, aber nicht die
> Linien dazwischen, was bei Frequenzen >1kHz etwas komisch aussieht.

Also zumindest mit den ATMegas sollte man locker die vollen 666 kHz
Abtastrate schaffen. Eventuell kannst Du einfach mehr Abtasten als Du
benötigst und dann darin den Triggerwert finden.

Christian Berger wrote:
> Also zumindest mit den ATMegas sollte man locker die vollen 666 kHz
> Abtastrate schaffen.

666kHz Samplerate und gleichzeitig ein TV Bild erzeugen ?
Wie das ?

Benedikt K. wrote:
> 666kHz Samplerate und gleichzeitig ein TV Bild erzeugen ?
> Wie das ?

Du tastest einfach während der Bereiche des Bildes ab, in denen Du kein
Bild ausgibst. Die Synchronimpulse werden sowieso durch die PWM
generiert, nur die aktuelle Zeile müsstest Du anders zählen. (z.Bsp. 2.
Timer)

Alternativ kannst Du auch etwas weniger Abtastrate erreichen, wenn Du
bei deinen NOPs im Bildaufbau abtastest.

Aber wie willst mit dem ADC vom AVR 666kS/s erreichen ?

Benedikt K. wrote:
> Aber wie willst mit dem ADC vom AVR 666kS/s erreichen ?

Das ist, soweit wie ich gehört habe, die maximale Samplingrate, die er
kann. Allerdings wird er dabei ungenau, so dass Du die 10 Bit nicht mehr
nutzen kannst.

Bei 666kHz kann man die Messwerte eigentlich wegwerfen. 8bit sind bis
etwa 50kHz möglich.

Hmm, ich hab vor das eventuell mal auszuprobieren. Ein Videoeingang für
den Rechner wäre schon geil. :)

Ein Videosignal digitalisieren wird nicht so ganz funktionieren. Mit
einem ADS830 (recht günstig bei Reichelt) ist das ganze aber möglich.
Die Schwachstelle ist nur die Verarbeitung der 15Mbyte/s.

Den ADC eines AVRs nutzte ich meist nur bis etwa 30-40kHz. Darüber nimmt
die Qualität schnell ab. Bei >100kHz Samplerate sieht ein Sinus schon
stark verzerrt aus.

Ich will ja keine perfekten QCIF Bilder haben. Mir würde schon das
reichen, was der SPI gleichzeitig mit der Bildausgabe einlesen kann.

Mal ne Frage angenommen man hätte nen AVR mit "unendlich" viel SRAM
welche Grafikauflösung könnte man da ereichen mit diesem AUfbau hat da
jemand ne ungefähre übersicht? Also das man halt richtige Pixelgrafiken
darstellen würde anstelle nur Characters, soweit ich das mitbekommen hab
ist das ja aufgrund des geringen SRAMS des Mega8/16 nicht anders möglich
(aber der mega32 hätte ja bspw schonmal 2k SRAM)

Also ohne Tricks wie dass Du direkt eine Leitung vom RAM zum DA-Wandler
legst kannst Du etwa 320 Pixel pro Zeile darstellen, maximal. Mit
externen Schieberegister gingen bis hin zu 1704, da wäre aber auch ein
VGA-Ausgang mit etwa 800 Pixeln möglich. Das alles sind natürlich nur
grobe Richtwerte.

Ich mein die einfach version mit den drei Widerständen und dem internem
SPI

In der einfachen Version sind 320 Pixel pro Zeile möglich. Da hast Du
aber kleine Zwischenräume nach allen 8 Pixeln. Mit etwas mehr Aufwand
kann man die aber auch rausbekommen. An Zeilen kannst Du so viel machen,
wie dein Monitor kann. Das sind 288 sichtbare Zeilen in der Gerber Norm,
doppelt so viel wenn Du die Zeilenverflechtung ausnutzt.

Christian Berger wrote:
> In der einfachen Version sind 320 Pixel pro Zeile möglich.
Nein:
Es sind 8MHz Schiebetakt möglich. Bei 54µs pro Zeile macht das 432 Pixel
pro Zeile. Den 9. Pixel müsste man per Software nachliefern, das müsste
auch funktionieren, wenn man für 9Pixel 2Bytes reserviert.
Wenn man ein volles Interlaced Bild erstellt, macht das 432x576 Pixel
die theoretisch mit einem mega8515 und externem SRAM möglich sind.
Wenn man den AVR übertaktet natürlich mehr.

In diesem Fall würde ich aber zu einem ARM mit 32kByte internem RAM
greifen.

Naja, theoretisch könnte man auch mehr als die 54 µs nehmen. So genau
sind die ja nicht definiert, bzw es hält sich sowieso niemand daran. :)
Mit den 8MHz Schiebetakt hast Du natürlich recht.

Aber, und jetzt kommts, man muss ja die Zeichen nicht unbedingt durch
Schieben darstellen. :) In Spezialfällen kann man tadsächlich einen
Pixel pro Taktzyklus machen.

Frage ist halt wieviel so ein ARM kostet und ob er noch lötfreundlich
verfügbar ist (SOIC o.ä) bei ARM kenn ich mich leider so überhauptnicht
aus.
Meine "Idee" war halt einfach das man eine AVR+Externes SRAM hernimmt
der sich nur um die Darstellung auf dem TVMonitor kümmert, und halt wie
bei dir per UART oder I²C neue Daten erhält. Halt im Prinzip eine "TV
Grafikkarte" für µC ;)

@Läubi:
  Ich hab mich noch nicht mit ARMs beschäfftigt... aber schon mal ein
paar Unterlagen durchgeschaut. Preislich sind die ARM7 meiner Meinung
nach schwer zu schlagen: Bei Reichelt gibts die für ein paar Euronen.
(LPC2119 für etwas mehr als 10Euronen) Was soll man zum Thema Leistung
sagen: 60MHz, 128kiB Flash, 16kiB SRAM, mehr als genug IO, jede Menge
Features... das einzige Problem ist bei den ARM immer das Gehäuse:
LQFP-64 ... dafür muss man erstmal die Platine herstellen können. Löten
dürfte mit einem SMD-Lötkolben noch gerade so gehen. Wenn es den ARM7
Kern im DIL gehäuse gäbe wäre ich schon längst zum ARM gewechselt.
Immerhin gibts dafür auch Linux ;)

@Benedikt:
  Mir wären 320x288 schon ausreichend... leider scheitert es bei kleinen
AVRs immer am Speicher. Leider besitzen nur bestimmte AVR ein externes
Speicherinterface.
Noch ne andere Frage: Hast du ein paar Screenshots von deinem
AVR-TV-Oszilloskop... mich würde es interessieren, inwiefern das Teil
brauchbar für Audio-Visualisierung ist.
Und noch eine Idee:  Wäre es nicht auch machbar eine FFT mit deinen
Routinen zu verknüpfen und ein einfaches Audio-Spektrum
darzustellen?!?!?
Eine FFT hat ja schon jemand mit dem ATmega8 realsisiert:
http://elm-chan.org/works/akilcd/report_e.html

Gruß,
  SIGINT

Christian Berger wrote:
> Naja, theoretisch könnte man auch mehr als die 54 µs nehmen. So genau
> sind die ja nicht definiert, bzw es hält sich sowieso niemand daran. :)

Doch: Die sind definiert. Und zwar als sichtbarer Bildbereich. Wenn man
die Zeit vergrößert, dann sieht man nichts mehr. Wobei aufgrund von
Overscan die meisten TVs nur etwa 45-50µs darstellen.


Zum Thema ARM: Ich habe schonmal damit gespielt. Als DSP Ersatz taugen
die nicht wirklich, und für IO Ansteuerung sind die auch gerade mal 2-3x
schneller als AVRs, obwohl die mit 70MHz laufen. Aber als CPU für
komplexere Aufgaben sind die wunderbar zu gebrauchen. Dank dem Sendefifo
bei der SPI Schnittstelle kann man wunderbar hochauflösende TV Bilder
erzeugen. Das 0,5mm Raster läst sich noch einigermaßen löten und ätzen.
Mit etwas Übung ist das zu schaffen.

@sigint
Mit 2x mega8 habe ich das ganze schon gemacht:
Ein mega8 arbeitet als TV Controller und erzeugt 40 Balken mit 0-256
Pixel Höhe, der zweite macht die FFT und schiebt die 40Bytes pro Paket
an den anderen AVR rüber.
Als Audioscope ist das ganze nur für Frequenzen <1kHz brauchbar,
ansonsten kann man aufgrund der vielen verstreuten Punke die Linie nicht
mehr erkennen.

Benedikt K. wrote:
> pro Zeile. Den 9. Pixel müsste man per Software nachliefern, das müsste
> auch funktionieren, wenn man für 9Pixel 2Bytes reserviert.
Also meinst du das man zwei bytes per SPI rauschiebt, aber beim zweiten
byte nur das erste bit sezt?

Nicht ganz:
Das erste Byte ganz normal per SPI raus, vom zweiten das erste Bit per
Software an einen anderen Pin und dann umschalten. Eben so wie ich es
bisher mache, nur dass das 9.Bit dann eben einen sinnvollen Inhalt hat
(statt schwarz bisher). Das 9.Bit dient nur dazu, um das Problem mit den
18 Takten pro Byte von der SPI Schnittstelle zu umgehen.

ah okay :)
Wenn ich im März mal wieder nen bischen Zeit hab wollt ich nämlich mal
mit dem mega8515 und externem SRAM rumspielen, mal gucken ob ich das
hinkriege ohne das alles explodiert :P

Hi!

Wollte mich nur mal bedanken für diese niedliche Schaltung. Funktioniert
hier perfekt an einem widescreen LCD mit CVBS Eingang. Mit geänderten
Parametern laufen nun 45x29 Zeichen über den Bildschirm. Basis ist ein
Mega32.

Aber an der Ausgangsstufe muss ich noch feilen. Ich denke, dass ein
OpAmp da nicht schaden kann. Eine Schwebung von 1.5V auf einem Signal,
dass nur ca. 1Vss haben sollte gefällt mir noch nicht so ganz. Aber ich
habe auch nicht alle Widerstände passend da. Werde das mal noch
optimnieren.

Gruß, Ulrich

Schwebung ?

Schwebung?

Bist Du sicher, dass Du die Masse korrekt angeschlossen hast und dass
dein Oszi auf DC steht?

Hihi...

Also, damit ihr mie glauibt, was ich sage und damit Ihr auch wisst, dass
ich mit einem Oszi umgehen kann, hier mal ein Dump vom Oszi...

Aber ich habe auch das Problem, dass das LCD eine recht große Last am
CVBS Ausgang ist. Ich kann nicht mit 75R oder 100R terminieren, da ich
dann kein Bild mehr habe. Ein TV habe ich aber nicht getestet.

Aber ich mach mal weiter, ich muss das ganze nämlich auf eine andere
Bildquelle aufsynchronisieren und dann beide Signale mischen. Ein
Mischerbaustein kommt aber nicht in Frage, da diese alle nacheinander
abgekündigt werden.

Gruß, Ulrich

So, hier mal ein Nachtrag.

Das LCD ist der Verursacher aller Probleme. Ich werde da wohl einen
Buffer OP einsetzen müssen, wenn ich damit weiter machen möchte. An 47R
( passende 75 oder 100R hatte ich gerade nicht zur Hand) und kein
Monitor drann, dann sieht das Ganze erheblich besser aus.

Gruß, Ulrich

Kann es sein, dass du Offset meinst ???

Wenn der LCD TV meint, dass er unbedingt ein Offset braucht ist das
egal. Ein kleines DC Offset am Videoanschluss ist zulässig. Immerhin
erzeugt der TV den Offset.
Die Terminierung ist übrigends OK. Wenn du nachrechnest, dann kommst du
auf etwa 71Ohm, was nahe genug 75Ohm liegt (mit dem Innenwiderstand der
Ports kommt man auf ziemlich genau 75Ohm.)

Ulrich P. wrote:

> Aber ich habe auch das Problem, dass das LCD eine recht große Last am
> CVBS Ausgang ist. Ich kann nicht mit 75R oder 100R terminieren, da ich
> dann kein Bild mehr habe. Ein TV habe ich aber nicht getestet.

75 Ohm sind ganz normal, die hat auch jedes (korrekte) Fernsehgerät.
Einen Bufferverstärker brauchst Du da noch lange nicht.

Hallo zusammen,

ich habe den AVR-Videogenerator aufgebaut und mich würde interessieren
warum die Baudrate-Variable 250000 hat? Ich habe sie auf 9600 erniedrigt
dann habe ich erst eine Verbindung via RS232 bekommen. Gibt es bei der
Software spezielle Steuerzeichen für z.B. Bildschirmlöschen, neue Zeile
beginnen, etc.?
Und wie ist die RS232-Schnittstelle eingestellt in bezug auf Parity,
...?

Gruß Thomas

Hi!

Also die Baudrate hat bei mir in allen Bereichen funktioniert. Nur an
einem USB-Seriell Dongle ging 250kB nicht. Habe es aus
Kompatibilitätsgründen mit anderen Entwicklungskits auf 57600 Baud
laufen. Schau mal, ob Deine Quarzeinstellungen, also die Fuses korrekt
gesetzt sind.

Ich bin mir nicht mehr sicher, da ich einige dieser Zeichengeneratoren
ausprobiert habe, aber ich glaube dieser hier hatte noch keine
speziellen Steuerzeichen. Hatte da selber mal angefangen, das zu
implementieren.

Leider auf einen anderen AVR, und an einem 16:9 LCD und ohne Kommentare,
also wenn Du das haben willst, dann kann ich das hier hochladen.

Gruß, Ulrich

Hallo,
Achso dann hätte ich da noch lange probieren können... Die
RS232-Verbindung war nach der Baudrate-Änderung kein Problem, ich wollte
einfach mal den Bildschirm löschen usw. wie ich das bei anderen gesehen
Programme habe und habe mich gewundert warum nichts passiert.

Wenn das ein Programm für den Mega16 ist, wäre das super dann müßte ich
nichts am Quellcode ändern und könnts gleich ausprobieren. Wenn du's
hochladen könntest wäre ich dir dankbar.

Gruß Thomas

Hi!

Ist nur ein Anfang, habe ein paar ESCape-Sequenzen eingefügt. Sollt mal
ANSII Standard werden. Ist leider nicht viel dokumentiert, da aus
Zeitmangel auf Pause gesetzt. Im Übrigen habe ich es auf einem ATmega32
laufen, solltest das aber mit wenigen Handgriffen für einen ATmega16 zum
laufen bringen.

Gruß, Ulrich

Hi!

Ich habe momentan leider überhaupt keine Zeit und die Änderungen waren
nur eine kleine Studie um herauszufinden, ob es sich für ein Amateurfunk
TV-Relay als Text-Einblendung in ein vorhandenes Video-Signal eignet. In
einigen Wochen kann ich mich damit noch einmal beschäftigen.

As I think that your question was software-translated I'll answer in
english too...
Actually I don't have any time at all for that. Initially it was only a
trial to find out if the given solution can be used for an amateur radio
tv relay for text overlay on a given video signal. I need a few weeks to
get back to this project again.

Grüße / regards
Ulrich

Die Software muss/sollte in Assembler geschrieben werden, da das Timing
für das Video-Signal in Software realisiert ist. Natürlich kann man den
logistischen Teil, also Zeichensteuerung, ESC-Sequenz-Erkennung u.s.w.
in C oder einer anderen Sprache gemacht werden. Aber das ATmega ist mit
dem Video-Timing schon sehr ausgelastet und jeder Overhead, und sei er
noch so klein, der durch eine Hochsprache dazu kommen kann, ist störend.

Ich habe die einfachen Sequenzen aber hier auch in C gemacht. Es war nur
ein Test auf Verwendbarkeit und scheiterte an nicht vorhandener Zeit. In
meinem Fall ist es nämlich so, dass das Video-Signal auf das einer
Camera synchronisiert werden muss, in das der Text das eingeblendet
wird. Fällt die Camera aus, muss das Modul das Signal eigenständig
erzeugen.

Gängige TV-Text Chips laufen leider aus oder sind jetzt schon nur noch
als Altware zu bekommen. Einige noch lieferbare Chips können nicht aktiv
ein Videosignal erzeugen, andere nur RGB aber kein CVBS. Es ist auch
kein Wunder, da diese Funktion in die restlichen Bausteine eines
TV-Chipsets hineingewandert ist. Die Zeiten als TV-Text noch als teures
Zusatzmodul verkauft wurde sind vorbei.

Zielsetzung war ein TV-Text-Modul, dass nicht aus speziellen Chips
besteht und daher leicht nachgebaut und auch modifiziert werden kann.
Eine Lösung auf Basis eines ATmegas wäre da ideal gewesen. Ich hatte
aber noch keine Zeit einen Sync auf ein bestehendes CVBS Signal
hinzuzufügen.

Gruß, Ulrich

Naja, wenn Du "hochauflösenden Text", sprich 40x25 machen willst, musst
Du den Controller per Genlock an das Videosignal anpassen.

Dazu erzeugst Du aus dem horizontalen Synchronsignal 16 MHz, in dem Du
es um den Faktor 1024 erhöhst. Ein PLL macht das relativ einfach.
Dadurch ist sichergestellt, dass jede Zeile genau 1024 Taktzyklen
dauert. Dein Controller läuft dann phasenstarr mit dem Videosignal.
Der Fehler des Zeitablaufes ist dann fest und verändert sich nicht mehr.
Dein Bild wäre schon stabil, nur auf der falschen Stelle.

Mit einem Chip wie dem LM1881 kannst Du relativ einfach die Komponenten
des Synchronsignals trennen. Ein Signal, welches einmal pro Zeile
auftritt (z.Bsp  'Burst'-Ausgang des LM1881) führst Du dann an den
Controller. Hat dieser die Möglichkeit einen Timerwert bei einem
Ereigniss auf einem externen Pin festzuhalten so nutze die. Du wirst
dann feststellen, wo, im Verhältniss zu deinem Timer, der Sync-Puls des
externen Videosignals ist. Somit kannst Du gelegentlich deinen
Zeitablauf abgleichen.

Zu guter Letzt kannst Du noch ein V-Sync Signal bei jedem Bildwechsel in
den Controller einspeisen, so dass er auch weiß, wann er ein neues Bild
anfangen soll.

Prinzipiell kannst Du auch den PLL softwaregestützt machen, aber ich
weiß nicht, wie gut das geht.

Wenn Du nur grobe Einblendungen machen möchtest, so kannst Du auch den
PLL komplett weglassen und einfach einmal pro Zeile einen externen
Interrupt einspeisen. Dann hast Du jedoch bis zu 5 Taktzyklen Jitter.
(etwa 2 Pixel)

Willst Du Farbe machen, so müsstest Du einen zweiten PLL bauen, welcher
unabhängig läuft und sich auf den Farbburst einklinkt. Dann kannst Du
das Ausgangssignal Phasenschieben und AM-Modulieren und ganz einfach
reinschalten. Das ist jedoch nochmal eine Runde schwieriger.

Well the main problem is how to connect the keyboard to the device. I
have done experiments with my own code and it works over the serial port
with an interrupt handler.

Probably the best way would be to use the otherwise unused I2C Port
(also called Two Wire Interface or something) for the keyboard and check
the keyboard buffer after every line. This way the display would not be
disturbed by another interrupt handler.
Obviously the main problem is implementing a state machine for all the
keyboard states. I am not yet sure how to do that efficiently.

That might be, althought I somehow doubt it's the ATMega8.

OK, OK. So it might be an ATMega8.

Still we could do it better :)

Vielleicht schreibst Du zu früh in den SPI. Wenn Du einen Befehl
rauslöschst musst Du natürlich entsprechend viele NOPs einfügen.

Und Debugger sind sowieso nur was für Weicheier. :)

Schön :)

Ich hab mir schon mal überlegt, ob ich nicht mal was mit einem externen
Schieberegister mache. Dadurch würde das noch einmal doppelt so schnell
werden. 80 Zeichen pro Zeile wären dann möglich.

Dann benötigt man aber einen größeren µC mit mehr Pins und mehr RAM. Mit
einem etwas größeren ARM µC mit 32kByte RAM sind lückenlose 512x256
Pixel möglich...
Das einzige Problem: Den kann man nicht mal schnell auf Lochraster
aufbauen.

Naja, ein ATMega32 würde schon reichen.

ARMs sind da natürlich die Königsklasse. Man müsste nur für die mal eine
Art DOS schreiben. So als eine Art Minimalbetriebssystem bei dem man
auch zur Laufzeit Programme nachladen kann.

Ein DOS auf den ARM...

Wenn man das zu Ende spinnt, dann könnte man in den ARM doch einen 6502
Emulator programmieren und käme dann Schritt für Schritt zu einem
'Single-Chip' XT oder Apple ][. Fügt man doch noch ein wenig externe
Logik hinzu, sollte auch ein C64 kein Problem sein, oder?

Gruß, Ulrich

Ulrich P. wrote:
> Ein DOS auf den ARM...
>
> Wenn man das zu Ende spinnt, dann könnte man in den ARM doch einen 6502
> Emulator programmieren und käme dann Schritt für Schritt zu einem
> 'Single-Chip' XT oder Apple ][. Fügt man doch noch ein wenig externe
> Logik hinzu, sollte auch ein C64 kein Problem sein, oder?

Gibt es den C64-Nachbau nicht schon für'n Appel und'n Ei in einem
Joystick integriert? Ich denke, ich habe mal sowas für um die 30 Taler
gesehen.


Zurück zum Thema des Threads:
Benedikt, ich danke Dir für Deine Vorlage!!

Ich konnte danach sehr preiswert einen OSD-Generator für Amateur-TV
bauen, der Ident-Text in das laufende Videobild einblendet. Im Sinne der
Lesbarkeit habe ich die Textmenge auf 10 Zeilen zu 32 Zeichen reduziert
und die Zeichenhöhe, sowie die Zeichen- und Zeilenabstände erhöht. Es
wird in einer Außenstation des ATV-Relais DB0WTB zum Einsatz kommen,
wobei die Texte von einem DTMF-gesteuerten Quellenumschalter (Tiny2313)
geliefert werden (das hätte in den Mega8 auch noch mit reingepasst, war
aber bereits vor der OSD-Idee fertig aufgebaut und in Betrieb genommen).

...

Was hat eigentlich der Code für eine Lizenz? Ich würde den gerne mit
GPL-Code mischen.

Hallo Leute,

das Projekt gefällt mir, insbesondere wegen seiner Einfachheit, sehr
gut. Allerdings kann ich es nicht 1:1 übernehmen, deswegen habe ich
versucht zu verstehen, wie das alles gemacht wird. An einem Punkt
scheitere ich aber: Der Erzeugung der vertikalen Synchronisierung.

handle_VSync:
  inc Y_Cnt        ;Zeilenzähler erhöhen
  cpi Y_Cnt, VSStart    ;Beginn VSync ?
  breq VSyncstart  
  cpi Y_Cnt, BPStart    ;Ende VSync ?
  breq VSyncende  
  cpi Y_Cnt, BildStart  ;Bildende ?
  brsh Bildbeginn  
  rjmp exit_int

VSyncstart:
  ldi tempi, (1<<COM1B1)|(0<<COM1B0)|(1<<WGM11)|(1<<WGM10)
  out TCCR1A, tempi    ;VSync Start: Sync Impulse High aktiv
  rjmp exit_int

VSyncende:
  ldi tempi, (1<<COM1B1)|(1<<COM1B0)|(1<<WGM11)|(1<<WGM10)
  out TCCR1A, tempi    ;VSync Ende: Sync Impulse Low aktiv
  rjmp exit_int

Bildbeginn:
  clr Y_Cnt
  ldi XL, low(DDRAM)
  ldi XH, high(DDRAM)
  rjmp exit_int

Bei VSyncstart und VSyncende werden aus meiner Sicht der gleiche Wert in
TCCR1A geschrieben, der zudem identisch mit dem Wert ist, der schon seit
der Initialisierung dort steht. Wo und wie wird die vertikale
Synchronisation da überhaupt ausgelöst? Wo sind die Vor- und
Nachtrabanten, wo die Unterscheidung von erstem und zweitem Halbbild?

Kann mir da jemand bitte die Tomaten von den Augen nehmen? Danke.

Gruß, DetlevT

Während des VSYNC wird die Polarität des HSYNC über das COM1B0 Bit
geändert. Die beiden Halbbilder sind identisch, Trabanten werden nicht
generiert. Der TV kommt aber trotzdem damit klar.

Jörg

Hallo Joerg,

stimmt, diese "komische" Null (0<<COM1B0) hatte ich übersehen.

Danke, DetlevT

Ich habe noch eine (blöde?) Frage. In der Initialisierung wird das Input
Capture Register mit 1024 geladen:

ldi temp, high(1024)      ;Timer Reloadwert
out ICR1H, temp
ldi temp, low(1024)      ;Timer Reloadwert
out ICR1L, temp

Ich vermute, das wurde einmal genutzt, um den TOP-Wert von TIMER1 zu
definieren. Das scheint mir aber gar nicht (mehr) nötig, weil allein
schon durch das Setzen von WGM13-WGM10 = 0111 der TOP-Wert auf 0x03ff
gesetzt wird. (10-Bit PWM)

Ich will das ICR für einen anderen Zweck nutzen, das kann ich dann doch
wohl machen, oder?

Danke schon einmal für die Antwort,

DetlevT

Ich kenne den restlichen Code nicht, aber wenn 10Bit PWM eingestellt ist
braucht man das ICR Register nicht. Allerdings lässt es sich nur dann
beschreiben, wenn es über WGM13-WGM10 als TOP-Value definiert ist,
ansonsten lässt es sich nur lesen.

Jörg

Hallo Joerg Wolfram,

danke für deine Antworten. Jetzt habe ich das Gefühl, das Ganze zu
durchschauen. Eigentlich müsste es auch möglich sein, ein ordentliches
PAL-Signal zu generieren. Es gibt ja auch ein 9-Bit-PWM-Modus für die
halbe Zeilenlänge und die negative Flanke ist bei PAL immer an der
gleichen Stelle (Bei TCNT=0). Man müsste dann also "nur" noch OCR1B
passend manipulieren (statt simpler Invertierung, die das Signal zudem
verschiebt) um der Norm zu entsprechen.

Ich muss dazu noch einmal genau das Datenblatt lesen. Mal sehen, wann
ich Zeit dafür finde. ;)

Gruß, DetlevT

Wäre es auch möglich, ein schon vorhandenes SYNC-Signal zu nutzen, um
die Zeichen über ein anderes Bild drüberzulegen?

Und nach welchem Prinzip sind eigentlich die Zeichen im Zeichenarray
definiert? Also, welches Byte beeinflusst da welchen Teil von welchem
Zeichen?

a) Ja, Du müsstest das Synchronsignal, zum Beispiel, mit einem LM1881
abtrennen und dann an jedem Zeilenanfang einen Interrupt auslösen. Du
müsstest dann beispielsweise per "Capture Compare" den genauen Zeitpunkt
bestimmen.

b) Das Format ist grob gesagt so: Die Zeichen sind 8x8 Pixel groß. Alle
Pixel in einer Zeile sind in einem Byte. Jedes Zeichen hat 8 Bytes, und
die werden zweckmäßig im Speicher angeordnet.

Nils ‫‪ schrieb:
> Wäre es auch möglich, ein schon vorhandenes SYNC-Signal zu nutzen, um
> die Zeichen über ein anderes Bild drüberzulegen?

Beitrag "Re: Texteinblendung in ein FBAS Signal"
Beitrag "Re: Texteinblendung in ein FBAS Signal"
Beitrag "Re: Texteinblendung in ein FBAS Signal"
Beitrag "Re: LM1881 BASCOM"

>
> Und nach welchem Prinzip sind eigentlich die Zeichen im Zeichenarray
> definiert?

Jedes Zeichen besteht ja aus 8 Bytes zu 8 Pixel.
Der Zeichensatz hat 256 Zeichen.
Da man das Bild zeilenweise braucht, enthält jede der 8 Flash-Pages eine
Pixelzeile für alle 256 Zeichen.

> Also, welches Byte beeinflusst da welchen Teil von welchem
> Zeichen?

In ZH steht die Pixelzeile der Schrift (+ Offset, da der Zeichensatz ja
nicht ab Adresse 0 beginnen kann).
Über ZL adressiert man das Bitmuster zum Zeichen.

Dies hat den Vorteil, dass man mit ZH die Pixelzeile adressiert und mit
ZL das Zeichen.

Wenn z.B. die Pixelzeile 2 (Zählweise 0-7) der Schrift dran ist,
adressiert man ZL auf Zeichensatzbeginn + 2. Dann liest man das
darzustellende Zeichen (ASCII-Code) aus dem RAM direkt in das Register
ZL, und kann mit LPM sofort das Bitmuster der Pixelzeile 2 des Zeichens
auslesen und an SPI zum bitweisen Herausschieben übergeben.

Mit jeder anderen Anordnung des Zeichensatzes wäre der Zugriff
komplizierter.

...

Benedikt K. schrieb:
> Das SPI Interface braucht leider 18 Takte. Schreibt man das Byte zu
> früh, wird es ignoriert.

Mir ist in einem Datenblatt da etwas aufgefallen, was mir persönlich
leider zwar gar nichts nützt, aber vielleicht ja einem anderen.

Die neuen "großen" ATMEGAs (164A und folgende) haben zwei USARTs, die
sich auch im SPI-(Master-)-Mode betreiben lassen. Mit UBRRn=0 laufen sie
ebenfalls mit halbem Systemtakt. Wenn ich da nicht etwas grundsätzlich
missverstanden habe, sind diese auch im SPI-Mode "double buffered". Das
heißt, man kann schon das nächste Byte schreiben wenn das vorhergehende
noch gesendet wird. Damit müsste man die Ausgabe eines Bytes in 16
Takten ohne irgendwelche Klimmzüge machen können.

Außerdem sind diese Controller bis 20MHz spezifiziert, so dass man noch
mehr Zeichen auf eine Zeile quetschen könnte.

Gruß, DetlevT

Man kann auch einfach den SPI abschalten und wieder einschalten, dann
gehen auch weniger Pixel pro Zeichen. Mit 5 Pixeln pro Zeichen könnte
man sogar 80 Zeichen pro Zeile machen.

Hallo Christian,

80 Zeichen auf einem Fernseher mit seiner geringen Bandbreite wären wohl
doch zu viel.

Die Diskussion mit dem An- und Ab-Schalten hatten wir weiter oben ja
schon. Das ändert nichts an dem Problemen, dass man nicht die volle
Kontrolle über alle Pixel hat und dass der Ausgang zwischen zwei Bytes
auf high geht.  Das könnte mit der USART als SPI eben anders sein.

Ich habe noch folgende Ideen zur Erweiterung/Weiterentwicklung für
dieses doch sehr gute Konzept:

1.) Man könnte den Controller mit 25.175MHz (notfalls auch 25MHz)
übertakten. Das sind 25%, das müssten die meisten Exemplare (bei 25°C)
mitmachen. Wenn die USART-Lösung funktioniert bekommt man damit 320
Pixel und damit auch 40 Zeichen auf einen Standard-VGA-Monitor.

2.) Mit einem 74HC157 (4-fach 2 zu 1 Multiplexer) und einem 8-Bit Port
(z.B. PORTC) kann man Farbe ins Spiel bringen. Der 74HC157 schaltet -
gesteuert von MOSI - jeweils vier Bits um (Vorder- und
Hintergrundfarbe). Definiert man MOSI=high als "Hintergrund" entfällt
auch das Problem mit dem High-Signal zwischen den zwei Bytes und man
muss da nichts mehr mit dem zweiten Pin korrigieren. Im (doppelt so
großen) Bildschirmspeicher wären dann nacheinander immer zwei Bytes pro
Zeichen. Eins für Farbe und eins für das Zeichen selbst. Mit einem
zusätzlichen Register color für die Farbe könnte der Code dann IMO so
aussehen:

.equ XSize    =80  ;Bildgröße in X Richtung in Nibbles

hloop:          ;Loop für 1 Zeile
  ld ZL, X+      ;ASCII aus RAM lesen  2
  lpm tempi, Z      ;Byte aus CGROM lesen  3
  ld  color, X+             ;Farbe lesen            1
  out SPDR, tempi      ;Byte ausgeben    1
  out PORTC, color    ;Farbe ausgeben   1

Am Ende der Zeile muss man dann noch 0x00 in PORTC schreiben, damit man
den Schwarz-Pegel erhält. Die Beschaltung für einen Farb-"DAC" findet
man bei Jörgs Chipbasic-Projekt,

Gruß, DetlevT

Detlev T. schrieb:
> Hallo Christian,
>
> 80 Zeichen auf einem Fernseher mit seiner geringen Bandbreite wären wohl
> doch zu viel.

Ein berühmter niederländischer Unterhaltungselektronikhersteller wirbt
schon seit den frühen 1990ger Jahren damit, 2000 Zeichen darstellen zu
können.

> Die Diskussion mit dem An- und Ab-Schalten hatten wir weiter oben ja
> schon. Das ändert nichts an dem Problemen, dass man nicht die volle
> Kontrolle über alle Pixel hat und dass der Ausgang zwischen zwei Bytes
> auf high geht.  Das könnte mit der USART als SPI eben anders sein.

Kann die mit 0 Start und 0 Stoppbit arbeiten? Das wäre der springende
Punkt. An sonsten lässt ja ein ausgeschaleter SPI ja die Normalbelegung
des Ports durch. Und die kann man steuern.

Christian Berger schrieb:
> Kann die mit 0 Start und 0 Stoppbit arbeiten? Das wäre der springende
> Punkt. An sonsten lässt ja ein ausgeschaleter SPI ja die Normalbelegung
> des Ports durch. Und die kann man steuern.

Das verstehst du falsch. In dieser Konfiguration ist die Hardware kein
UART, sondern eine ganz normale SPI-Schnittstelle. Also nix, was Start-
oder Stopp-Bits hätte.

Detlev T. schrieb:

> Also nix, was Start-
> oder Stopp-Bits hätte.

Ahh, grad auch im Datenblatt gesehen.

Die Idee mit der Farbe finde ich persönlich eher merkwürdig und
umständlich.
Ich würde den Controller auf der 6-fachen Farbunterträgerfrequenz
(26,60171250 MHz) laufen lassen, und dann einfach den SPI-Ausgang
verwenden.

Du hättest dann Pixeltrippel für die Farbe. Das ist zwar nicht RGB,
sollte aber trotzdem brauchbar sein.
Will man eher gute Farbe haben, so speichert man im RAM für jedes
Pixeltrippel einen Wert. Man schlägt diesen Wert im Flash-ROM nach und
gewinnt 3 Bits für die Ausgabe. Im Flash-ROM wären dann 2 kleine
Tabellen die den Farbpalettenwert für gerade und ungerade Zeilen
enthalten. Da hätte man dann ungefähr 160 Pixel pro Zeile.

Hat man 3840 Bytes zur Verfügung, so könnte man beispielsweise 5 Pixel
in einem Byte kodieren. Dabei bestimmen die 5 niederwertigsten Bits den
Eintrag der Tabelle, und die 3 hochwertigsten Bits welche Tabelle
verwendet wird. Die Tabelle hätte dann 8*2 Einträge und würde noch in
das RAM passen. Dann hätte man 8 Kombinationen von 2 Farben für jeweils
8 Pixel bei 160*120

Im Prinzip kann man auch mit Einzelpixeln arbeiten, dann wird das mit
den Tabellen aber komplizierter.

Man könnte das sogar noch weiter spinnen und die Taktfrequenz noch
extern verdoppeln und als Träger für das Bildsignal nutzen. Das wäre
dann etwas unter Kanal 3. :)

Hallo Christian,

so auf Anhieb verstehe ich nicht, was du da vorschlägst. Ich sehe aber,
dass du viel mehr RAM und ein stark übertakteten Controller brauchst um
einmal gerade 160x120 Pixel zu erreichen.

Grafik finde ich für diesen Zweck ohnehin nicht für zweckmäßig. Warum
soll man mit viel Mühe (und RAM) ein grafisches Display programmieren,
dass man dann im Hauptprogramm wieder mit viel Mühe mit den Pixeln für
Buchstaben füllen muss? Da finde ich die Idee von Benedikt viel besser:
einfach ein Byte ins RAM schreiben - und schwupps ist das Zeichen auf
dem Bildschirm.

Mit meiner Idee könnte man dann noch jedem Zeichen eine Vorder- und
Hintergrundfarbe aus insgesamt 16 möglichen Farben zuordnen. Man muss
dann aber über SCART gehen, via BAS gibt es natürlich nur grau in grau.

Na mal schauen, wann ich Zeit und Lust habe, das umzusetzen.

Gruß, DetlevT

Naja, ein Textmodus geht da natürlich auch. Du hättest dann 20 Zeichen
pro Zeile mit 8 Vorder- und Hintergrundfarben. (mehr mit Tricks) Der
große Vorteil ist halt, dass man direkt ein FBAS Signal bekommt und
keine aufwändige externe Hardware mehr braucht. (Dein Multiplexer
benötigt mindestens 9 Verbindungen zur MCU! Da muss man schon sehr
motiviert sein, so viel zu löten)

Kann man den SPI um einen Taktzyklus verschieben, so könnte man auf 40
Zeichen pro Zeile damit machen, allerdings mit eingeschränkten Farben.
Das muss ich mir aber noch weiter überlegen.

Hypothetisch könnte man auch "Sub-Nyquist" Abtastung verwenden. Dann
würde auch eine niedrigere Taktfrequenz reichen.

Es ist faszinierend, welch hohe Bildqualität und Stabilität mit dieser
Software erreicht wird. Vielen Dank an Benedikt dafür.

Um auch weniger Zeichen Bildschirmfüllend darzustellen, habe ich das
Programm etwas erweitert. Es gibt jetzt auch die Möglichkeit der
Grafikdarstellung.

Hier eine Übersicht der Erweiterungen:

* Zeilenumruch mit EOL-Zeichen ermöglicht die speichersparende
Textdarstellung (siehe Screenshot vmode0 mit 44x34 Zeichen, die sonst
nicht mehr in die 1KB des ATmega8 passen.)

* Variabler Zeilenabstand zur Verbesserung der Lesbarkeit (Screenshot
vmode4 mit 40x20 Zeichen).

* Abstand zwischen den Zeichen (Screenshot vmode7 mit
bildschirmfüllenden 32x24 Zeichen)

* Doppelt breite Zeichen (Screenshot vmode9 mit 20x16 Zeichen)

* Grafik mit 80*64 Punkten ohne/mit Raster. Das Raster erzeugt eine
LCD-Matrix ähnliche Darstellung (Screenshot gfxmode1 und 2).

* Grafik mit 88x72 und 96x80 Punkten (Screenshot gfxmode6).

* Speicherung der im Interrupt genutzten Register im RAM. Das
Hauptprogramm kann alle Register frei nutzen.

Zur Demonstration habe ich einige Parametersätze definiert (vmode,
gfxmode), die leicht erweitert werden können.

Ich hoffe, das Programm enthält keine Fehler mehr. Getestet habe ich mit
einem ATmega8. Die Screenshots wurden mit einem Video-Grabber erstellt,
zeigen also das echte Videosignal.

Hinweis zum Bildformat: Das verwendete JPG belegt nur etwa 50% Speicher
gegenüber dem PNG-Format.

funker schrieb:
> Wie stelle ich eine hex her oder ein bin?

Ich verwende ebenfalls AVR Studio und gehe so vor:

Neues Projekt anlegen.
Project Type: Atmel AVR Assembler
Debug platform: AVR Simulator
Device: ATmega8

Nach dem Assemblieren (F7) liegt im Projektverzeichnis eine hex-Datei
mit dem Projektnamen, also z.B. Testprojekt.hex.

Grüße.

Es gibt einige neue Erweiterungen.

Optimierung für kleine LCD Monitore mit 234 Bildzeilen:
Insbesondere für den Betrieb mit kleinen 7" LCD Monitoren wurde eine
Option zur doppelten Zeilenausgabe eingebaut, da die Monitore aufgrund
der niedrigen Auflösung einige Zeilen des Bildes verschlucken können.

Neu ist auch ein doppelt hoher Zeichensatz (8x16 Pixel), von dem es auch
eine Version mit invertierten Zeichen gibt. Dann ist der Zeichenvorrat
allerdings auf 128 Zeichen beschränkt.

Die Video-Modes vmode_12 - vmode_18 demonstrieren die neuen
Möglichkeiten.

Der Modus mit 20x8 Zeichen eignet sich für Anzeigen, die aus größerer
Entfernung noch lesbar sein sollen.

Eine Anmerkung zu den Screenshots:

vmode12:
 40x16 Zeichen mit neuem 8x16 Pixel Zeichensatz

vmode12i:
 40x16 Zeichen mit neuem 8x16 Pixel Zeichensatz, der inverse Darstellung
unterstützt.

vmode14 und vmode16:
 20x12 Zeichen Darstellung, einmal mit 8x16 Zeichensatz, einmal mit 8x8
Zeichensatz und doppelter Zeilenausgabe

vmode17:
 20x8 Zeichen, gute Lesbarkeit auf Entfernung.