www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik 8 bit .bmp - Farbpalette bei 8 Bit Ausgabe notwendig?


Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ich fang gerade an ein Projekt zu planen welches ein Farbbild
(bmp) auf dem TV ausgeben soll (FBAS) ich werde dazu 3x 8bit Flash oder
eeprom benutzen - an deren Ausgang ein 8bit D/A wandler angeschlossen
ist. Die Werte errechnet eine Software, welche vorerst auf nem PC
laufen soll. die 3 analogwerte werden dann von einem RGB/PAL converter
in FBAS gewandelt. Die syncronisationssignale werden ebenfalls im
eeprom abgelegt, und über logische verknüpfungen erkannt (0V)

Nun ist meine Überlegung ob ich die Palette im 8bit Bitmap-file nicht
einfach ignorieren sollte, da der D/A wandler eh nicht mehr auflösen
kann...

BTW: für tolle ideen bin ich gerne zu haben

Autor: Christoph Kessler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das Flash schnell genug, um die Bildpunkte in Echtzeit auszugeben?
Ich habe schon mal einen PAL-Farbbildspeicher mit Eprom gebaut und im
"TV-Amateur" (www.agaf.de) veröffentlicht. Der hatte allerdings nur 8
Bit insgesamt, also je drei für Rot und Grün und 2 für Blau. als
3Bit-DAC hatte ich R/2R/4R Widerstände. Als PAL-Coder benutzte ich den
fremdsynchronisierbaren TDA8501. Die Eagle-Files könnte ich hier mal
uploaden.

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du 3x8bit verwendest, dann hast du 24bit...
Wieso nimmst du also nicht gleich 24bit BMPs ?

Autor: Christoph Kessler (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Eagle-light kompatibel 80*100mm

Autor: Christoph Kessler (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So sieht ein Testbildgenerator mit drei Flash aus

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
250€ ist aber heftig.
Da kann man sich gleich einen PC mit Grafikkarte und TVOut hinstellen.
Der hat dann nicht nur 2 Bilder, sondern bis zu 25 verschiedene pro
Sekunde...

Autor: Christoph Kessler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So ein Testbild läuft beispielsweise auf der Amateur-Relaisfunkstelle
Hornisgrinde im Schwarzwald auf 1278 MHz. Als zweiter
Farb-Testbildgeber mit Wetterstations-Einblendungen ist ein alter ZX
Spektrum am Werk. Außerdem gibts noch eine Außenkamera, die derzeit den
Blick auf eine verschneite Winterlandschaft zeigt.

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sorry! ICH HABE MICH VERTAN! natürlich bei 3x8bit=24bit wie blöd! da
kann ich ja dann echt n 24bit bmp nehmen. Such grad noch nach ner
einfachen basic-umgebung für blödis. PC-Programmierung mach ich nur
wenns unbedingt sein muss :-))

zum testen kann man ja erstmal nen scart-tv nehmen, oder?

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, aber nicht jeder TV kann RGB...

Wenn du 3x 512kByte verwendest, solltest du mit 13,1072MHz Taktfrequenz
auf (sichtbare) 680x576 Pixel Auflösung kommen.

Woher nimmst du diesen Takt ? Ich hatte bei meiner SW Version ziemliche
Probleme, einen geeigneten Quarz dafür zu finden.

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mmmhhh - syncronisation ist ja, wenn ichs richtig verstanden habe kommen
die sync impule ja immer am anfang der zeile, bzw in zwischenzeilen die
nicht angezeigt werden. eine zeile dauert dann immer 64µSec? bei
320x240 würde also dann ein pixel 52µSec/320pixel= 0,1625µSec dauern -
da bräuchte man nen 6,1538 mhz takt. der einzig gängige quarz wäre dann
aber 6,14 - also können wir nur 319 pixel darstellen, damit kann man
leben, oder?

Oder mach ich da jetzt nen denkfehler?

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beschreib doch mal genau was du vorhast, ich habe in der Richtung schon
einiges gemacht, vielleicht kann ich ja bei der Schaltungsentwicklung
etwas mithelfen.

Generell gibt es zwei Möglichkeiten, um aus einem Speicher ein Bild zu
erzeugen:
a) Man speichert das Bild mitsamt Sync Signalen im Speicher. Dadurch
geht zwar einiges an Speicherplatz verloren, aber man benötigt nur noch
einen Adresszähler und hat am Ausgang schon das fertige Videosignal als
Digitalsignal.
b) Man speichert nur das Bild. Dadurch spart man einiges an Speicher,
benötigt aber eine zusätzliche Logik (z.B. uC) der die Sync Signale
erzeugt, solange die Datenausgabe vom Speicher stoppt und zu Beginn der
nächsten Zeile wieder startet.

Welches von beiden Verfahren möchtest du verwenden ?

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hatte an 1) gedacht. Zeitkritisches Programmieren ist mit bascom
immer so ein kleines problem :-))

Weiss ned obs vielleicht Sinn macht, nen Flash zu verwenden und dort
dann 3 "Images" abzulegen, welche dann einmal beim starten von nem
µCOM in 3xSram gespeichert werden? - Dann könnte man den Flash über
seriell mit hilfe des µcom bequemer programmieren

Autor: Christoph Kessler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1/13,1072MHz = 76,3 nsec das wird für Flash schon etwas schnell, Eproms
mit 70nsec Zugriffszeit sind jedenfalls selten

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also die Idee mit dem SRAM scheint nicht allzuschlecht zu sein, oder?

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du das so machst, dann wird das nichts mit 240 Zeilen:
Wenn man die Zeilenanzahl verändern will, muss man eine Zeile doppelt
ausgeben, was dann wieder eine größere Menge an Logik erfordert, wenn
man nicht 256 oder 512 Pixel pro Zeile verwendet.

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christoph Kessler
Die Angabe in den Datenblättern lautet maximal 70ns.
Ein 70ns Flash schafft in der Praxis die 13,1MHz also ohne Probleme.
Auch mit 90ns geht es bei den üblichen Raumtemperaturen.

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mmhh also mit 680x576 hast du es schonmal ans rennen gebracht? hast du
die sync - signale mit einer logik erzeugt oder auch in dem
eeprom/flash abgelegt? ich will den schaltungsaufwand so gering wie
möglich halten...

Autor: Benedikt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich finde leider den Schaltplan nicht, aber mir mal ein Foto vom
Aufbau:
Links oben ein LC OSzillator als Quarzersatz für die 13,1MHz, darunter
der Synchronzähler für die 19bit Adresse. In der Mitte der 512kB Flash
Speicher, daneben ein Latch für die Daten und der DAC.
Darüber noch ein Videodetektor und darunter ein Videotreiber mit
Umschalter der automatisch auf den Videoeingang umschaltet, sobald ein
Videosignal anliegt. Ansonsten kommt ein nettes Testbild.

Das ganze war als FBAS gedacht, funktioniert aber aufgrund der
mangelnden Samplerate nur als superscharfes BAS Signal.
In dem Flash ist ein Vollbild des Videosignals mitsamt aller
notwendigen Infos (Sync, Farbburst usw.) enthalten.

Für ein Farbbild müsste man entweder die Samplerate erhöhen, oder man
verwendet 2-3Flash Speicher. Den Sync könnte man als 1 bit ausführen,
so dass immer noch 15 oder 23bit für die Farben bleiben. Die RGB Infos
und das Sync Signal kommt dann in einen RGB-FBAS Converter.
Da die Horizontalauflösung eines TVs nicht so gut ist, könnte man 256kB
Speicher verwenden und hätte so 340x576 was immer noch ein gutes TV
ergibt.

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich denke die variante mit 2-3 flash-speicher ist echt okay. wenn die
spannungsversorgung einigermaßen stabil ist, kann man sicher ein
widerstandsnetzwerk als d/a wandler nehmen. du hast einen cpld als
binärzähler programmiert.. mhh das spart ne menge platz. und man könnte
damit aus einem viel höheren takt mit einigen zählern etc den geeigneten
takt auszählen, oder?

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, genau das war der Grund warum ich den CPLD genommen habe:
Den Takt hätte ich eventuell teilen können, falls ich einen Quarz
gefunden hätte, der irgendein Vielfaches von 13,1 bzw. 6,55MHz hat.

Außerdem hätte ich für 19bit 3x 8bit Zähler HC590 o.ä. gebraucht die
dazu eventuell nicht ganz synchron sind usw.
Also einiges mehr an Aufwand und nicht so flexibel.

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mit cpld hab ich mich noch gar nicht auseinandergesetzt.... das werde
ich mir wohl erst noch aneignen dürfen... gibts da software wo man
éinfach logische verknüpfungen zusammenfügen kann? Ist schon halbwegs
wichtig, dass man ein bauteil hat, was ne höhere frequenz abkann... und
cplds sollen das wohl...

wenn wir 3x8 bit machen, kann ich ja einfach die bytes direkt auslesen
aus dem bitmap.. hab mir mal ne qbasic besorgt und mach grad n bisschen
mit datei lesen rum...

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So. Habe mir mal ein testbild gemacht. Die Pixelfarbenreihenfolge
scheint B G R zu sein. Jetzt schau ich mir mal die Sync. an...

Autor: Benedikt (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal mein BMP -> (F)BAS Konverter für QBasic.

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
so ähnlich habe ich jetzt auch angefangen....

wie denkst du machen wir das mit dem D/A? ganz normal an 5V und dann
mit nem 1/5 teiler auf 1V teilen? Meine nächste überlegung zielt auf
die sync - pulses... ein extra eeporm wär ein bisschen doof und außerst
übertrieben. ein - zwei bit dafür nehmen - reicht das aus? also haben
dann zwei farben nur 7 bit. das wäre denke ich am akzeptabelsten - weil
man dann nicht grossartig mit verknüpfungen arbeiten muss...

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es reicht sogar 1 bit, denn man braucht ja nur Composite Sync:
Composite Sync erhält man, wenn man V und HSync XOR verknüpft. Ist dann
zwar kein echtes BAS Signal, aber gut genug für 1 Halbbild.
Will man dagegen beide Halbbilder verwenden, muss das Sync Signal etwas
aufwendiger berechnen, so wie in meinem Programm.
Hier ist alles genau beschrieben:
http://www.2cool4u.ch/tv_signal_measurement/tv_sig...

Als DAC verwende ich einen TDA8702. Am Anfang hatte ich einen R2R DAC
mit Emitterfolger als Endstufe verwendet. Am Ausgang dann einen
Spannungsteiler um auf die 0,7Vss zu kommen.

Autor: Christoph Kessler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
der TDA8702 geht mit 75 Ohm intern nach +VccA, deshalb braucht man noch
einen großen Koppel-C und evtl. Klemmdiode.

Ja Qbasic war noch eine einfache Programmiersprache, da werden noch
keine Witwen und Waisen eliminiert und Töchter enterbt oder wie das
heutzutage objektorientiert heißt

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mit diesen sch**** sync signalen. ich les es mir grad zum 80sten mal
durch - aber es will ned in meinem kopp. h-sync ist mir klar
1,5µsec 0,3V dann 4,7µsec 0V dann 5,8µsec 0,3V dann gehts weiter..

Aber V-Sync? resignierendes kopfschütteln

also vor/nachtrabanten sind da, um jeweils die halbe zeile
auszugleichen?? und die hauptimpulse sind immer gleich. ODER BIN ICH ZU
BLÖD?

Autor: Christoph Kessler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Über Sync-Signale gibts die ausführlichen Informationen im Datenblatt
zum Philips Syncpulsgenerator SAA1101. Das sind "amtliche" Timings
für höchste Ansprüche:
http://www.semiconductors.philips.com/pip/SAA1101_CNV_2.html
Er wird nicht mehr produziert, aber das Datenbaltt gibts noch, ich
meine von  meinen Namensvettern www.kessler-electronic.de habe ich ihn
damals bezogen.

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den link. habe mal in der bücherecke gekramt... da habe ich
ein buch von 1955 gefunden - jedenfalls ist die auflage damals
erschienen. da ist es ähnlich erklärt...
Also geht das eigentliche bild erst ab der 7. Zeile los -bzw das 2te
halbbild in der 8ten zeile?

MMHH mal schauen ob ich da was mit nem AVR und BASCOM (nicht lachen)
anrichten kann..

wenn ich den austastimpuls für das erste halbbild nach 100zeilen
schicke, dürfte er ja nur ungefähr die erste hälfte des Bildschirms
beschreiben??

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
SO:

habe jetzt mal ein wenig geschmökert ;-))

ich habe mich fpr ein 4,9152Mhz Quarz entschieden, gibt es auch als
quarzoszillator. bei 52µsec bildinhalt hätte ich ca 254 bildpunkte pro
zeile.  D.H ein Bildpunkt würde 0,2034µsec. dauern - damit bekommt man
auch 1,5µsec für den horizontal - sync aufgelöst.


Zum testen werde ich ein S/W bild bauen, welches nur die hälfte der
Zeilen (ungerade) des Fernsehers nutzt. Da komme ich erstmal mit nem
128k eeprom klar... Wenn das läuft werde ich volle auflösung und dann
Farbe in angriff nehmen...

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie steuerst du den Speicher an ?
Wenn du nur einen einfachen Adresszähler dranbaust, dann wird das
Halbbild 416 Zeilen lang. Macht ziemlich genau 37,5fps, das ist etwas
zu wenig für einen TV...

Autor: Sebastian Heyn (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mmhh also binärzähler und dann reset durch &gatter bei zeile 313...
hatte ich gedacht. habe keine cpld-kenntnisse.

Autor: Sebastian Heyn (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo lang lang ists her...

Ich habe jetzt eine ähnliche software mit TP zum laufen gebracht, da
finde ich den Dateizugriff einfacher. nur mit den pixeln bin ich mir
noch nicht ganz einig geworden. ich will erstmal bei s/w bleiben, und
frage mich gerade ob ich bei 240 zeilen bleibe oder 576 wie das
eigentlich sollte vorziehe? also einen 29f040 hab ich bereits
bestellt... als zähler werden erstmal hc161 herhalten auf meinem
steckbrett..

Nun meine frage.. Ich erzeuge die signale im anhang als vsync.. danach
sende ich einfach 576 zeilen mit hsync am anfang? oder muss ich die
entsprechenden signale für das andere halbbild senden?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.