Announcement: there is an English version of this forum on 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
Das ist jetzt ein Scherz, oder? Mal überlegt, wie schnell sich ein VGA-Signal ändert und wie schnell der ADC im AVR ist?
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)
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
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
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.
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 ;)
Angehängte Dateien:
-
vga1.jpg
68 KB
Hier mal ein paar Bilder für die "Ist doch mit einem AVR nicht möglich" Fraktion.
Angehängte Dateien:
-
vga2.jpg
76 KB
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.
Angehängte Dateien:
-
vga3.jpg
61 KB
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.
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.
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..
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.
>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?
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
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.
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
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.)
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.
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 ...
Genau, bei Standbildern kann man das Signal ja mehrfach ueberabtasten... aber dennoch wuerde ich sagen ein AVR ist damit etwas ueberfordert.
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:)
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...
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.
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.
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.
und Wie stelle ich eine Impulszählung an? Gib mir mal ungefär die Richtung.
Den Timer kann auf externen Takt schalten. In der Prescaler Tabelle sind das meist die untersten beiden Werte.
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
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.
@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
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
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).
> 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.
Ich hab vielleicht auch etwas Dumm formoliert. Ich Brauche die Zeit einer Zeile die Auflösung ist nebensache. egal welche Bildwiederholfreuenz usw.
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.
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.
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
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
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)
@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.
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.
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.
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.
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...
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.
@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.
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).
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.
Wenn das eine Linux/Unix-Maschine ist, kannst du dann die Boot-Ausgaben nicht einfach über den COM-Port beziehen?
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
> 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 ;-)
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. :-)
> 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)
Thread beobachten
Seitenaufteilung abschalten
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.