mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik VGA-Signal digitalisieren


Autor: Julian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Ich versuche mit einem ATMEGA16 ein VGA Signal, z.B. den roten Kanal,
mit dem internen A/D - Wandler zu digitalisieren.
Am Ausgang hab ich ein Oszilloskop drangehängt um zu sehen was
rauskommt, aber das Signal sieht überhaupt nicht digitalisiert aus.(Es
sollte ja ständig zeile für zeile ausgegeben werden) Wenn man z.B. den
Computerbildschirm schwarz macht (mit Paint) dann sollte doch ständig
eine 0 ausgegeben werden, bei Rot eine 1 und z.B. bei dunkelrot sowas
wie 0011 (128), bei 4 bit auflösung.
Möglicherweise hab ich ein Fehler im Programm.

Mein Code:
-------------------------------------------
#include <inttypes.h>
#include <avr/io.h>
#include <stdlib.h>


uint16_t ReadChannel(uint8_t mux)
{
  uint8_t i;
  uint16_t result;

  ADCSRA = (1<<ADEN) | (1<<ADPS1) | (1<<ADPS0);
  ADMUX = mux;
  ADMUX |= (1<<REFS1) | (1<<REFS0);

  ADCSRA |= (1<<ADSC);
  while ( ADCSRA & (1<<ADSC) ) {
     ;
  }

  result = ADCW;

  ADCSRA &= ~(1<<ADEN);   // deaktivieren

  return result;
}




int main(){


DDRB |= (1 << PB3);

uint16_t adcval;

  adcval = ReadChannel(0);                 /* MUX-Bits auf 0b0000 ->
Channel 0 */


    PORTB = 0; // Pull up ausschalten

  if(adcval == 1)
  PORTB |= (1 << PB3);
  else
  PORTB &= ~(1 << PB3);

return 0;
}

-------------------------------------------

Bin um jede Hilfe dankbar.

Julian

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist jetzt ein Scherz, oder?
Mal überlegt, wie schnell sich ein VGA-Signal ändert und wie schnell der 
ADC im AVR ist?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Problem könnte u.a. sein, dass die Signale meist AC gekoppelt sind, 
und irgendwo um den Sync herum auf Schwarzwert geklemmt werden.
Wenn man es also richtig machen möchte:
- Signal über einen Kondensator an den ADC legen.
- Sobald der Sync erkannt wird: ADC Pin kurz auf Low schalten, damit 
sich der Kondensator entsprechen läd.
Danach sollte man mit dem Bereich 0-1V sauber die Pegel einlesen können.

Wiso schaltest du den ADC eigentlich immer aus ? Das kostet nur unnötige 
Zeit (25 statt 13 Takte)

Autor: Julian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Meinst du den V-Sync, also das der Kondensator nach jeder Zeile gelöscht 
wird. Dann kann ich den ADC Pin mittels Pull up einfach auf low ziehen, 
dass muss ich wahrscheinlich mit Interrupts machen.
Funktioniert, dass dann auch wenn z.B. eine Zeile zuerst etwas dunkel, 
dann heller und wieder etwas dunkler wird. Wird der Kondensator dann 
nicht die ganze Zeit aufgeladen?

Vielleicht ist es besser wenn z. B. n (z.B. 8) Pixel zusammengefasst 
werden also nur jedes n-te Pixel gewandelt wird.


julian

Autor: Fred S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Julian,

ich bin nicht so sicher, dass Du das Timing des VGA-Signals richtig 
verstehst, wie Ernst schon schrieb. VGA kann ich mir leicht so merken: 
Pixelfrequenz etwa 25 MHz, Zeilendauer etwa 25us. Mal nachrechnen, ob 
das stimmt:

Zeitdauer pro Pixel bei 640 Pix/Zeile = 25us/640 ~ 0,04us, also 
identisch mit 1/25MHz=0,04us.

Bei den AVRs läuft der ADC normalerweise mit 50-200kHz (Du hast ja den 
Vorteiler gesetzt), und eine Konversion dauert optimal 13 Zyklen, also 
65us bei 200kHz....

Viele Grüße

Fred

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Julian wrote:

> Meinst du den V-Sync, also das der Kondensator nach jeder Zeile gelöscht
> wird.

Nach jeder Zeile, also H-Sync.

> Dann kann ich den ADC Pin mittels Pull up einfach auf low ziehen,

????????

> Funktioniert, dass dann auch wenn z.B. eine Zeile zuerst etwas dunkel,
> dann heller und wieder etwas dunkler wird. Wird der Kondensator dann
> nicht die ganze Zeit aufgeladen?

Der ADC ist vergleichsweise hochohmig, so dass nahezu kein Strom fließt. 
Dadurch funktioniert das. Das ganze stellt dann quasi einen Hochpass da, 
da aber die niedrigste vorkommende Frequenz die Horizontalfrequenz mit 
>30kHz ist, braucht der Kondensator auch nicht übertrieben groß zu sein.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ne ADC-Wandlung bei nem AVR (sagt man dann jetzt "classic"?) dauert im 
Mittel um die 100us... vielleicht auch schneller, aber nicht wesentlich, 
es wird ein approximatives Verfahrn verwendet.  Da kommste also nich so 
ganz hin mit so nem schnellen Signal ;)

Autor: Benedikt K. (benedikt) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal ein paar Bilder für die "Ist doch mit einem AVR nicht möglich" 
Fraktion.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Diese Bilder habe ich gerade mit einem mega48 @ 24MHz gemacht, der am 
VGA Ausgang hängt. Von der Software her könnte man noch höher gehen, die 
Hardware ist die Grenze. Eine höhere Taktfrequenz würde aber keinen Sinn 
machen, denn das Problem ist die Analogbandbreite des AVRs, die wohl 
irgendwo um die 1MHz liegt.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Diese niedrige Bandbreite begrenzt die mögliche Auflösung auf <640x480. 
800x600 sieht bereits so aus.
Das Abtasten von einem 640x480 Bild dauert übrigends etwa 30s.

Autor: 6639 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man koennte das Resultat mit einem externen Sample und Hold verbesseren, 
und jeweils nur einen Punkt pro Zeile oder zwei aufs Mal digitalisieren. 
Fuer stehende Bilder sollte es demnach reichen.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jetzt muss ich mal ganz dumm fragen:

Der Atmel ist an einem VGA-Ausgang einer Grafikkarte angeschlossen? 
ODer?
Was macht er dort?

Weil das obige Programm sampled einen Wert, weil eine Endlosschleife 
gibt es nicht..

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Matthias Lipinsky wrote:

> Der Atmel ist an einem VGA-Ausgang einer Grafikkarte angeschlossen?

Ja, HSync, VSync gehen an Interrupt Pins, RGB an 3 ADC Pins.

> Was macht er dort?

Er sampled Pixel für Pixel, erst R dann G, dann B

> Weil das obige Programm sampled einen Wert, weil eine Endlosschleife
> gibt es nicht..

Dass die Software von Julian noch nicht ganz das macht, was er möchte 
dürfte klar sein. Aber das kann man noch hinbekommen.

Ich wollte damit jetzt nurmal zeigen, dass es doch prinzipiell geht. Die 
Software ist quick&dirty, es sind noch einige kleinere Fehler drin. 
Etwas links von der Bildmitte sieht man z.B. dass das Bild um eine Zeile 
einen Sprung macht.

Autor: Matthias Lipinsky (lippy)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Er sampled Pixel für Pixel, erst R dann G, dann B

Und dann? Was soll dann mit den Daten passieren?

Welche Sinn hat das?

Autor: Fred S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

nach den obigen Beiträgen ist klar, wie Ihr vorgeht. Ich gehöre zur 
"geht nicht mit 'nem AVR"-Fraktion und bleibe dabei, denn unter 
"Digitalisieren eines VGA Signals" stelle ich mir eben nicht vor, dass 
Randbedingungen vorliegen müssen wie VGA<640 Pixel/Zeile, 
Abtastszeit=30s und "Bild muss während des Abtastzeit von einem Frame 
zum nächsten unverändert sein". Das alles ist für mich wie 
"Digitalisieren eine Sprachsignals", ohne dass erwähnt wird, dass das 
Sprachsignal durch einen 30 Hz Tiefpass gegangen ist!

Gruß

Fred

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Benedikt K. wrote:
> Hier mal ein paar Bilder für die "Ist doch mit einem AVR nicht möglich"
> Fraktion.

Dementsprechend bescheidend sieht es aus. Und Du hast die CPU stark 
uebertaktet, was nicht gerade einen stabilen Betrieb gewaehrleistet. 
Aber nett zu wissen, was im Grenzfall so moeglich ist.

Autor: robotik (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dann wäre doch ein abtasten des fbas-signal noch besser möglich, es 
braucht doch 64µs ..oder? da könnte man doch schon was mit 16mhz machen?

wer kann so etwas mal vorstellen mit dem atmega644 oder kleiner und dem 
adc.

mfg

Autor: Benedikt K. (benedikt) (Moderator)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hier mal die Software die ich verwende um TV und VGA zu digitalisieren.
Bei einem TV Signal sieht das dann etwa so aus:
http://www.mikrocontroller.net/attachment/29452/ad...
Die Daten werden per UART über einen FT232 gesendet, denn die Datenrate 
liegt bei einigen 10kByte/s was per RS232 direkt nicht so schnell geht.
Die Software ist weder gut, noch fertig, noch fehlerfrei. Beides sind 
Quick&dirty Versionen die ich schnell aus anderen Sachen zusammenkopiert 
habe.
Das Grundlegende ist, dass der ADC vom OCR1B getriggert wird. OCR1B wird 
wiederum vom ICR1 Wert bestimmt, der durch HSync geladen wird und einem 
Offset das die abzutastete Spalte angibt.
Wenn man diesen Trick einmal verstanden hat, kann man kontinuierliche 
Signale mit bis zu CPU Takt digitalisieren.
Die Messung wird jeweils duch den Befehl 65 per UART gestartet. Der 
Befehl 1 bei der VGA Version misst die Bildgröße und die Sync Polarität 
(könnte man besser und schöner machen, war gestern abend nur schnell 
hingepfuscht.)

Autor: Jojo S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
solche Digitizer gab es schon für Apple ][ und C64, da sollte der ATMega 
das auch locker schaffen. Aber mehr als den Lerneffekt bringt das heute 
nicht mehr glaube ich.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Digitizer-Lösung ist halt nur für Standbilder zu gebrauchen.

Um einzelne Frames oder gar einen Strom von Frames zu erfassen, bedarf 
es doch bedeutend schnellerer Hardware und auch bedeutend mehr Speicher 
...

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Genau, bei Standbildern kann man das Signal ja mehrfach ueberabtasten... 
aber dennoch wuerde ich sagen ein AVR ist damit etwas ueberfordert.

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Warum nicht unterabtasten?
Wieso überfordert?

Ich bin von der Fraktion "geht mit AVR" ;-)))

Axelr.

EDIT:
kommt ja auch immer auf den Zweck an.
Meine SCART-LAMPE geht jedenfalls:)

Autor: Kai G. (runtimeterror)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also für einen Ambilight-Nachbauer sollte ein Random-Sampling per AVR 
vollkommen ausreichen... Hauptsache der AVR weiß, an welcher Stelle die 
Messung stattgefunden hat.

Das sollte auch problemlos mit Bewegtbilder gehen.

Ob da andere Methoden sinnvoller sind sei mal dahingestellt.

Ist die initiale Frage des Openers eigentlich schon beantwortet? Mich 
würde interessieren, welcher Datenstrom jetzt letztendlich ankommt...

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt, Kai hat Recht.

@Julian,
Du initialisierst deinen ADC einmalig im Freerunmode und lässt im ADC 
interrupt das Ergbnis auf mPort ausgeben. ADLAR(?) gesetzt macht ja 
8Bit.

Dann nimmst Du Dir einen Sack voll 10K Widerstände und baust einen R2R 
am Port und hängst da dein Oszi drann. So habe ich das jedenfalls 
gemacht.

Und dann sieht man erstmal, wie langsam das alles ist. Dann kann man 
noch versuchen, den ADC-Takt hochzusetzen und feststellen, das es jetzt 
etwas schneller geworden ist, aber immer noch erst 2,3 Samples pro Zeile 
gehen.

---------
Hatten wir das mit dem 100pF und dem Portpin schon als Debugausgabe auf 
dem Monitor? Möchte mich nur ungern wiederholen und auf der anderen 
Seite niemanden langweilen.
---------

Also wenn Du das R2R-Signal mit auf die ursprünliche Farbe mit drauf 
legst, kannst Du gut erkennen, wann und wieviel der ADC gesampelt hat.

Jedenfalls schon recht interessant - bei RGB bestimmt noch zu 
beherrschen.

Beim "gelben Chinch" wirds dann richtig spassig.

Autor: RENE (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Tag Gemeinde,

AVR Mega 16 16MHz

habe das Problem das ich mit Timer 0 ein Hsync signal erfassen will. 
Also habe ich Hsync mit Port B1 verbunden. Indem ich Port B1 dann mit
  clr   temph
loop1:      sbic  PinB,1                               ; warte bis Hsync low
      rjmp  loop1
loop2:      sbis  PinB,1               ;warte bis Hsync high  
      rjmp  loop2
      out   TCNT0,temph         ; Timer zurücksetzten                                                  
      ldi   tempH, (1<<TOIE0)
      out   TIMSK,temph
      ldi   tempH, (0<<CS02)|(0<<CS01)|(1<<CS00) ; Systemtakt Timer0 interner Takt vorteiler 1
      out   TCCR0, tempH 
      clr   temph
loop3:      sbic  PinB,1               ; warte bis Hsync wieder Low
      rjmp  loop3
      in    templ, TCNT0
      sts   VTimeL,templ 
      sts   VTimeH,temph 
      ldi   tempH, (0<<CS02)|(0<<CS01)|(0<<CS00) ; Systemtakt Timer0 interner Takt vorteiler 1
      out   TCCR0, tempH 
      ldi   tempH, (0<<TOIE0)
       out   TIMSK,temph

abfrage bekomme ich dann ein ergebniss aber das ist nicht sonderlich 
genau
gibt es da noch andere Methoden? Das nächste problem ist das sich das 
Hsync signal bei anderen Auflösungen "Drehen" kann. Alo Hi ist dann Low 
usw.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Frage ist: Wie genau brauchst du das ganze ?
Bei den HSync üblichen Frequenzen von 30-100kHz würde ich keine 
Periodendauermessung machen, sondern eine ganz normale Impulszählung 
über z.B. 1s. Damit hast du das Problem ob der Impuls positiv oder 
negativ ist gelöst, und die Auflösung ist auch mindestens um den Faktor 
50 höher.

Autor: René (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und Wie stelle ich eine Impulszählung an?

Gib mir mal ungefär die Richtung.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Den Timer kann auf externen Takt schalten. In der Prescaler Tabelle sind 
das meist die untersten beiden Werte.

Autor: René (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich will eigentlich nur die Auflösung ermitteln also 800x600 oder ....
um dann den Bildschirm aufteilen zu können ich brauche die Hsync Zeit 
von einem Impuls zum anderen.

Oder wie kan man das ausrechen?

Sorry ich steh im Wald

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die genaue Auflösung kannst du nicht messen, da der Pixeltakt unbekannt 
ist.
Man kann nur aus der Zeilenanzahl die Auflösung abschätzen.
Ich messe daher die Anzahl an Zeilen pro Bild, das reicht.
Dazu mache ich im Prinzig genau das was du im Code geschrieben hast, nur 
eben mit HSync als Takt für den Zähler und statt HSync frage ich VSync 
ab.

Autor: Jochen Müller (taschenbuch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@benedikt,
also ich finde deine Versuche da schon beeindruckend. muss ich sagen.
Mich interessiert aber noch, wie du die Daten nach dem abtasten 
weiterverarbeitet hast, bis diese hier als jpg.-bild auftauchen?

Was den OP angeht, so muss dieser sich -so glaube ich- erstmal von 
diesem unsäglichen C verabschieden. Das was er da vor hat ist eine 
Echtzeitanwendung reinsten Wassers, da kommt es auf JEDEN EINZELNEN 
Taktzyklus an, und zwar so extrem, dass sich das auszählen und 
optimieren jedes einzelnen Befehls lohnt. C ist da die schlechteste 
aller Möglichkeiten, alleine schon das aufrufen von subs mit dem damit 
verbundenen stack-zirkus kostet wertvolle und vor allem: unkalkulierbare 
Takte. Ok, bascom wäre noch schlimmer...
So etwas geht sinnvoll nur in Assembler und auch dann nur mit genug 
Erfahrung.

Jochen Müller

Autor: René (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ist das normal das sich bei VGA Karten das Sync signal je nach Auflösung 
negiert wird?

Ich Warte also auf Vsync zähle dann die Zeilen bis Vsync sich wieder 
ändert.
und Teile das ergebniss dann durch die Zeit von Vsync zu Vsync dann 
müsste ich die Zeit für eine Zeile haebn die ich ja brauche?
Hört sich nicht so einfach an

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
René wrote:
> Ist das normal das sich bei VGA Karten das Sync signal je nach Auflösung
> negiert wird?

Ja. Das diente früher zur Erkennung er Auflösung. Da es mittlerweile 
mehr als 4 Auflösungen gibt, ist diese Methode nur noch aus 
Kompatibilitätgründen vorhanden.


> Ich Warte also auf Vsync zähle dann die Zeilen bis Vsync sich wieder
> ändert.

Ja.

> und Teile das ergebniss dann durch die Zeit von Vsync zu Vsync dann
> müsste ich die Zeit für eine Zeile haebn die ich ja brauche?

Wobei die Zeit für eine Zeile für die Bestimmung der Auflösung 
uninterresant ist.


Jochen Müller wrote:
> Mich interessiert aber noch, wie du die Daten nach dem abtasten
> weiterverarbeitet hast, bis diese hier als jpg.-bild auftauchen?

Ich sende die Pixel per UART an den PC, dort schreibe ich die Pixel in 
eine BMP Datei und die wird dann per Bildverarbeitungsprogramm in ein 
jpg umgewandelt.

> Was den OP angeht, so muss dieser sich -so glaube ich- erstmal von
> diesem unsäglichen C verabschieden. Das was er da vor hat ist eine
> Echtzeitanwendung reinsten Wassers, da kommt es auf JEDEN EINZELNEN
> Taktzyklus an, und zwar so extrem, dass sich das auszählen und
> optimieren jedes einzelnen Befehls lohnt.

Nicht unbedingt. Ich habe auch alles in C gemacht. Das eigentliche 
Timing wird durch die Hardware vorgegeben (der Timer triggert direkt den 
ADC).

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ist das normal das sich bei VGA Karten das Sync signal je
> nach Auflösung negiert wird?

Ja. Damit haben frühe VGA-Monitore erkannt, welche Zeilenanzahl sie 
darstellen sollten. Bei gleicher Horizontalfrequenz konnten diese 
nämlich zwei unterschiedliche Vertikalfrequenzen darstellen.

Der "Text"-Modus mit 400 Bildzeilen, zu dem auch der (verdoppelte) 
CGA-Modus gezählt wurde, und der "Graphik"-Modus mit 480 Bildzeilen. In 
ersterem waren 70 Hz Bildwechselfrequenz möglich, in letzterem aber nur 
60.

Wie gesagt, das bei konstanter Horizontalfrequenz.

Die Unterscheidung war erforderlich, damit die Monitore die Zeilen 
unterschiedlich dicht auf der Bildröhre anordneten; der "Text"-Modus 
bekam etwas mehr Platz zwischen den Zeilen, um eine ähnliche Bildhöhe zu 
ergeben wie der "Graphik"-Modus.

Autor: René (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab vielleicht auch etwas Dumm formoliert.
Ich Brauche die Zeit einer Zeile die Auflösung ist nebensache.
egal welche Bildwiederholfreuenz usw.

Autor: René (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry

Formuliert

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, das ist dann natürlich was anderes. Auch hier wieder die Frage: Wie 
genau brauchst du das ?
Das genaueste dürfte die Messung der Frequenz mit dem Timer sein, die 
Dauer des Messintervals bestimmt die Auflösung.

Autor: René (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich möchte eigentlich den ADC immer an einer Besteimmten (selben) Stelle 
des Bildes Starten egal welche Auflösung und Wiederholfreuenz doch schon 
möglichst genau. Bevor ich den ADC Starten kann muß ich wissen welche 
Auflösung ich gerade anliegen habe habe.

Autor: Michael U. (amiga)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

die Auflösung muß Du dazu nicht wissen. Du mußt die Zeit für eine Zeile 
kennen (Abstand zwischen den HSync-Impulsen) und die Anzahl der Zeilen 
(Anzahl HSync-Impulse zwischen 2 VSync-Impulsen).

Die "Stelle" im Bild ist Zeilennummer nach VSync und Zeit nach HSync.

Problematisch wird, daß es ja ein Analogsignal mit hoher Frequenz 
(Pixeltakt) ist. Die S&H-Schaltung des AVR-ADC braucht eigentlich für 2 
ADC-Takte ein stabiles Signal am Eingang, das hast Du aber nicht.
Entscheidend ist also, wann Du den ADC startest, ich würde wohl kein 
FreeRunning nehmen, weil da der Zeitpunkt des S&H ziemlich zufällig zum 
Zeilenaufbau wäre.

Ansonsten vernmutlich Mittelwert über ein paar Bilder bilden?

Gruß aus Berlin
Michael

Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das ist auch nicht das Problem ich habe pro Farbe eine LF198 S&H Stufe 
vor dem
ADC sodass alles stabil gehalten wird.
Mein Problem ist eigentlich nur noch das Timing bzw. die Aufteilung der 
Abtastpunkte über das Bild je nach größe

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen

René Schink wrote:
> das ist auch nicht das Problem ich habe pro Farbe eine LF198 S&H Stufe


LF198 - Monolithic Sample and Hold Circuit

Features
•  Operates from ±5V to ±18V supplies
•  Less than 10 µs acquisition time
•  TTL, PMOS, CMOS compatible logic input

sind kleiner 10µsekunden nicht arg langsam?
Dann kannst Du auch die integrierte S&H Stufe im AVR verwenden, oder?

Viele Grüße
Axelr.

(ich bin auch noch nicht viel weiter mit meiner Schaltung)

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rene
Was soll das werden, wenn es fertig ist ? Ambilight ?
Die interne S&H Stufe des AVRs ist grob geschätzt etwa 1µs schnell.
Ich würde nicht eine externe S&H Stufe verwenden, sondern lieber eine 
Zeile später R, G und B messen.

Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ambilight ja fast aber für eine spezielle Anwendung.

es wird aber alles sehr langsam wenn ich RGB Nacheinander Messe so kann 
ich auf einmal Sampeln und in "Ruhe" auswerten wenn man z.B. Pro Frame 
vier Messstellen hat und dann nochmal pro Messstellen 16 Werte Mitteln 
will dann wird die Sache zu langsam und des wird unruhig und Flackert.

Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
das Problem ist noch immer ganz genau die selbe Stelle zu treffen.
Ich hab mit Zählen und nop versucht aber mann bekommt es nie ganz genau 
hin
Ich habe mal auf den Rot Kanal des Monitors einen 10p C gelötet und 
einen Pin im Moment des Sampelns ein und ausgeschalten. Auf dem Monitor 
ist der Punkt der auch den Messpunkt darstellt nie ganz zur Ruhe 
gekommen. Der Punkt flackert immer ca. 0,5mm auf dem Bildschirm 
horizontal hin und her.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, 0,5mm sind selbst bei "nur" VGA gerade mal ein Pixel. Genauer 
wirst du es nie hinbekommen, außer du erzeugst den CPU Takt per PLL aus 
dem HSync Signal.

Autor: R--- S--- (rene66)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry 0.5 cm - 1cm

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
René Schink wrote:
> Sorry 0.5 cm - 1cm

doch so viel?
na wenigstens taugt mein Debug"werkzeug" ;-)

einen Pinchangeinterrupt hat der Mega16 ja nicht - hmm...

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für was Pinchange ?
Machs doch so wie ich:
Bestimmt mit dem Input Capture den exakten Zeitpunkt des HSyncs, und 
benutze diesen Wert um über Ouptput Compare den ADC zu triggern. Damit 
erreichst du +/-1 CPU Takt, also +/-62,5ns Auflösung.

Autor: Axel R. (axelr) Flattr this
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, wie bei der Propellerclock für ein stehendes Bild;-))

Autor: Christian C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt K.

Meinst Du, es ließe sich mit so einer ATmega-Lösung eine Art "Poor Man's 
KVM Switch over IP" bauen?

Mir geht es dabei eigentlich nur um evtl. Bildschirmausgaben eines PC
zwischen dem Einschalten und dem Starten des Bootloaders (z.B. GRUB), 
also Ausgaben des BIOS oder irgendwelchen Controller-BIOS Ausgaben.
Ich fänd's prima, wenn man diese mit Hilfe des ATmega digitalisieren 
könnte, um sie dann per TCP/IP irgendwo verfügbar zu machen. Evtl. dann 
noch eine Keyboard PS/2 Emulation, um ein paar Tastendrücke abzusetzen.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Theoretisch ja, nur dauert das Abtasten eines Bildes aber sehr lange 
(30s oder sowas in der Richtung). Und solange wird das Bild aber eher 
selten still stehen. Außerdem muss man das Bild dann irgendwie übers 
Netz übertragen. Keine Ahnung wie schnell ein AVR + ENC28 ist, aber ich 
würde eher irgendwas schnelleres verwenden (ARM oder sowas).

Autor: Christian C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, danke für die Einschätzung. Ein ARM sollte auch okay sein.

30s ist natürlich wirklich schon recht lang. Mir geht es aber um den 
Notfall, dass bei einem Server irgendwo beim Booten was hängen bzw. 
stehen bleibt. Sei es der RAID-Controller oder sonst was. Dann hätte man 
immer noch diese absolute Notlösung. Ich weiß, es gibt spez. 
Server-Boards, die Fernwartung usw. unterstützen. Hier geht es aber um 
die "Poor Man" Variante. :-)

Einzelne Standbilder und ein Tastendruck könnten da oftmals schon recht 
hilfreich sein.

Autor: Kai G. (runtimeterror)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn das eine Linux/Unix-Maschine ist, kannst du dann die Boot-Ausgaben 
nicht einfach über den COM-Port beziehen?

Autor: Christian C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Kai,

es geht dabei um alles, was sich VOR einem Bootloader wie GRUB oder LILO 
abspielt und damit natürlich erst recht vor der Ausgabe irgendwelcher 
Kernel-Meldungen. Mir ist klar, dass der GRUB und der Kernel auch über 
einen COM-Port ausgeben können. Ein "normales" PC-BIOS allerdings nicht.

Gruss,
Christian

Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> es geht dabei um alles, was sich VOR einem Bootloader wie GRUB oder LILO
> abspielt und damit natürlich erst recht vor der Ausgabe irgendwelcher
> Kernel-Meldungen.

WENN der Rechner eh schon im BIOS (also vor "Anspringen" irgendeines 
Bootloaders) hängen bleibt, dann ist da eh was ziemlich im Argen. Das 
bekommst du höchstwahrscheinlich auch nicht mit Fernheilung hin. Also 
kann es ja "eigentlich" nur um die Diagnose gehen "Ist der Rechner so 
platt daß man rausfahren muß, und wie platt ist er eigentlich ?"

Für diesen Zweck wäre es aber wesentlich einfacher und hilfreicher, die 
auf dem Diagnoseport (war es 0x80 ?) ausgegebenenen Meldungen / Stati zu 
sampeln  und per TCPIP an den entfernten Kontrollrechner zu übertragen 
(wär ja mal ein nettes Projekt ;-)

Autor: Christian C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wegstaben Verbuchsler wrote:
> WENN der Rechner eh schon im BIOS (also vor "Anspringen" irgendeines
> Bootloaders) hängen bleibt, dann ist da eh was ziemlich im Argen. Das
> bekommst du höchstwahrscheinlich auch nicht mit Fernheilung hin. Also
> kann es ja "eigentlich" nur um die Diagnose gehen "Ist der Rechner so
> platt daß man rausfahren muß, und wie platt ist er eigentlich ?"

Klar. Da hast Du natürlich recht. Bei mir war es erst kürzlich der 
rumzickende RAID-Controllers meines selbst zusammengeschusterten 
Root-Servers im Rechenzentrum. Hatte mir zu dem Zeitpunkt gewünscht, 
einfach ein paar Screenshots der RAID-Controller-BIOS-Ausgaben sehen zu 
können und ein paar Tasten drücken zu können. Mehr nicht. "Remote-Hands" 
Dienstleistung der Techniker vor Ort kosten am Wochenende ein kleines 
Vermögen. ;-)

> Für diesen Zweck wäre es aber wesentlich einfacher und hilfreicher, die
> auf dem Diagnoseport (war es 0x80 ?) ausgegebenenen Meldungen / Stati zu
> sampeln  und per TCPIP an den entfernten Kontrollrechner zu übertragen
> (wär ja mal ein nettes Projekt ;-)

Stimme zu. Auch ein interessantes Projekt. :-)

Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Stimme zu. Auch ein interessantes Projekt. :-)

vor allen dingen relativ einfach: "chinesische" Diagnose-Ports (ISA, 
PCI) mit LED und 7-Segment-Ausgabe gibts für 10 EUR in der Bucht. Die 
diagnostizieren sogar noch die versorgungsspannungen

"man" braucht also nur noch diese per LED angezeigten Werte abzugreifen 
und in gescheite Form zu übersetzen (da kommt mir doch gleich Ulrich R.s 
Webserver in den Kopf, der könnte das gefällig aufbereiten)

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.