Forum: Mikrocontroller und Digitale Elektronik VGA-Signal digitalisieren


von Julian (Gast)


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

von Εrnst B. (ernst)


Lesenswert?

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

von Benedikt K. (benedikt)


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)

von Julian (Gast)


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

von Fred S. (Gast)


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

von Benedikt K. (benedikt)


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.

von Michael G. (linuxgeek) Benutzerseite


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 ;)

von Benedikt K. (benedikt)


Angehängte Dateien:

Lesenswert?

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

von Benedikt K. (benedikt)


Angehängte Dateien:

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.

von Benedikt K. (benedikt)


Angehängte Dateien:

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.

von 6639 (Gast)


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.

von Matthias L. (Gast)


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..

von Benedikt K. (benedikt)


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.

von Matthias L. (Gast)


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?

von Fred S. (Gast)


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

von Michael G. (linuxgeek) Benutzerseite


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.

von robotik (Gast)


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

von Benedikt K. (benedikt)


Angehängte Dateien:

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/adc_mega48.jpg
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.)

von Jojo S. (Gast)


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.

von Rufus Τ. F. (rufus) Benutzerseite


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 
...

von Michael G. (linuxgeek) Benutzerseite


Lesenswert?

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

von Axel R. (Gast)


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:)

von Kai G. (runtimeterror)


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...

von Axel R. (Gast)


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.

von RENE (Gast)


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
1
  clr   temph
2
loop1:      sbic  PinB,1                               ; warte bis Hsync low
3
      rjmp  loop1
4
loop2:      sbis  PinB,1               ;warte bis Hsync high  
5
      rjmp  loop2
6
      out   TCNT0,temph         ; Timer zurücksetzten                                                  
7
      ldi   tempH, (1<<TOIE0)
8
      out   TIMSK,temph
9
      ldi   tempH, (0<<CS02)|(0<<CS01)|(1<<CS00) ; Systemtakt Timer0 interner Takt vorteiler 1
10
      out   TCCR0, tempH 
11
      clr   temph
12
loop3:      sbic  PinB,1               ; warte bis Hsync wieder Low
13
      rjmp  loop3
14
      in    templ, TCNT0
15
      sts   VTimeL,templ 
16
      sts   VTimeH,temph 
17
      ldi   tempH, (0<<CS02)|(0<<CS01)|(0<<CS00) ; Systemtakt Timer0 interner Takt vorteiler 1
18
      out   TCCR0, tempH 
19
      ldi   tempH, (0<<TOIE0)
20
       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.

von Benedikt K. (benedikt)


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.

von René (Gast)


Lesenswert?

und Wie stelle ich eine Impulszählung an?

Gib mir mal ungefär die Richtung.

von Benedikt K. (benedikt)


Lesenswert?

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

von René (Gast)


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

von Benedikt K. (benedikt)


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.

von Jochen M. (taschenbuch)


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

von René (Gast)


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

von Benedikt K. (benedikt)


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).

von Rufus Τ. F. (rufus) Benutzerseite


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.

von René (Gast)


Lesenswert?

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

von René (Gast)


Lesenswert?

Sorry

Formuliert

von Benedikt K. (benedikt)


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.

von René (Gast)


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.

von Michael U. (amiga)


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

von R--- S. (rene66)


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

von Axel R. (Gast)


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)

von Benedikt K. (benedikt)


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.

von R--- S. (rene66)


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.

von R--- S. (rene66)


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.

von Benedikt K. (benedikt)


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.

von R--- S. (rene66)


Lesenswert?

Sorry 0.5 cm - 1cm

von Axel R. (Gast)


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...

von Benedikt K. (benedikt)


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.

von Axel R. (Gast)


Lesenswert?

Naja, wie bei der Propellerclock für ein stehendes Bild;-))

von Christian C. (Gast)


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.

von Benedikt K. (benedikt)


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).

von Christian C. (Gast)


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.

von Kai G. (runtimeterror)


Lesenswert?

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

von Christian C. (Gast)


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

von Wegstaben V. (wegstabenverbuchsler)


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 ;-)

von Christian C. (Gast)


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. :-)

von Wegstaben V. (wegstabenverbuchsler)


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)

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.