Gast
#4762950
Hallo, Wie funktioniert zum Beispiel die direkte Programmierung von einem Bildschirm oder anderer Hardware? PS: Wird dafür C und Assembler benutzt?
Bildschirm ist einfach, siehe Bild. Und zur zweiten Frage... Wenn du es bis auf die Hardwareebene runterziehst: 0 und 1 ! Ansonsten Assembler und danach jegliche Hochsprache. Für alles (bis auf 0 und 1) natürlich einen Compiler für die jeweilige Hardware vorausgesetzt. ;-)
Angehängte Dateien:
-
tipp-ex-2.jpg
(14 KB)
Gast
#4762961
Angenommen ich könnte Assembler, wie müsste ich vorgehen um zum Beispiel einen bestimmten Pixel eines Bildschirmes zu verändern?
Gast
#4762963
Du wirst den Spalten- und Zeilentreibern die Adressen geben und dann den Wert wohl irgendwo pralllel rauswerfen.
Ein bildschirm und andere Hardware besteht aus vielen komponenten. Ein programm kann Mechanich sein, z.B. bei Blinklämpchen bei dem der Kontakt ein Wärmeschalter bildet. Ein Programm kann als schaltung abgebildet sein, ein altmodisches radio braucht noch keinen Prozessor, keine uCs. Das ist natürlich erstmal nicht das, was man mit Programmierung meint. Heutige geräte sind komplex, und benötigen komponenten die eingehende Signale, haufig logiksignale (0 oder 1) interpretieren, in dem diese mit einer abfolge simpler Logikoperationen die gewünschten ausgehenden Signale berechnen, mit denen was an diese Komponente angeschlossen wurde angesteuert wird (können lampen, andere derartige kompinenten, etc. sein). Diese komponenten arbeiten mittels sehr kleinen logikbausteinen (und, nicht, oder, etc.). Das program darin kann entweder in der Schaltung, also der anordnung der Logikelemente, oder auf einem Datenträger gespeichert sein. Im ersten fall wird heute dafür entweder ein chip entwickelt, und/oder die schaltung auf z.B. einen fpega gefläscht. Sich die schaltung manuell auszudenken wäre zu kompliziert, deshalb gibt es Hardwarebeschreibungssprachen, wie vhdl oder verilog. Die 2te variante ist die verwendung eines Prozessors, der vorgegebene Instruktionen abarbeiten kann. Soetwas kann man mit fpegas und vhdl auch selbst bauen. Das Programm muss dann irgendwo gespeichert sein, und dem Prozessor zugefürt werden. Als datenspeicher gibt es heute z.B. flash und eeprom, früher gab es Magnetspeicher, lochkarten oder hartverdratung. Der datenspeicher enthält das Programm und Daten. Das Programm ist eine abfolge von Prozessorinstruktionen. Glücklicherweise giebt es schon fertige derartige chips. Man unterscheidet zwischen uPs (microprozessor) und uCs (mikrocontroller). Beim ersten muss man unter anderem die daten usw. selbst zuführen und braucht einen z.B. einen separaten flash chip. Ein uC hingegen enthält bereits Prozessor, Speicher, etc. und keine Zusatzteile um zu funktionieren. Prozessoren haben recht simple grundfunktionen, wie eine Instruktion des Programms laden, ausführen, das ergebnis zwischenspeichern, etc. Mit simplen logikoperationen können komplexe Berechnungen und Ablaufe erstellt werden. Alan turing hat unter anderem bewiesen, das mit einem gewissen satz an Instruktionen jede andere Instruktion simuliert werden kann. Soein Instruktionssatz ist dann turingkomplet. Prozessoren haben derartige Instruktionssets. Das hochladen eines Programms in einen uC wird Flashen genant. Das Program ist eine Abfolge von Instruktionen. Um ein programm für einen uC zu schreiben gibt es 3 möglichkeiten: 1) Mit einem hexeditor, man schreibt die zahlen, abfolgen von nullen und einsen, dieeine Prozessorinstruktion darstellen, manuell. Das macht niemand mehr. 2) Mit einem Assembler. Assembler, oder asm ist eine menschenlesbere Repräsentation des (Programms)/Maschienencode. Dort kan man dann dinge wie "add a, b" schreiben, und der Assembler macht daraus die instruktion, den Maschieben code welcher dem entspricht. 3) eine Programiersprache wie c. Der compiler erzeugt aus dem Quellcode den Maschienencode. In Programiersprachen beschreibt man nicht exakt was der prozessor tun soll, sondern was allgemein für schritte durchgeführt werden müssen. In c kanst du einfach schreiben "a=1+b" und der Compiler kümmert sich darum, die abfolge der Instruktionen die der jeweilige prozessor braucht zu generieren, diese sind bei jeder Prozessorarchitektur anders. Programmcode ist aber bei allen Architekturen identisch, abgesehen von der expliziten Ansteuerung spezifiser Funktionen des Prozessors. Der übliche ablauf ist also: Programmcode wird geschrieben, auf den/die uCs gefläscht, und diese(r) steuert dann das gerät.
Sehr schön ausführlich geschrieben! Ehrlich! Daniel A. schrieb: > Der übliche ablauf ist also: Programmcode wird geschrieben, auf den/die > uCs gefläscht, und diese(r) steuert dann das gerät. Hier fehlt aber ein wichtiger Punkt: "Der übliche ablauf ist also: Programmcode wird geschrieben, *der Programmcode wird in Maschinencode compiliert (0 und 1)*, auf den/die uCs gefläscht, und diese(r) steuert dann das gerät. Im übrigen, wie das bei FPGAs ist, da habe ich keine Erfahrung - ist dort der Programmcode auch als Hex hinterlegt?
Rene K. schrieb: > Im übrigen, wie das bei FPGAs ist, da habe ich keine Erfahrung - ist > dort der Programmcode auch als Hex hinterlegt? Bei FPGAs bezeichnet man den synthetisierten "Programmcode" als sog. Bitstream. Bei den meisten FPGAs wird dieser in Binärform in einem externen Flash mit SPI-artiger Schnittstelle abgelegt. Nur wenige FPGAs enthalten hierfür ein internes Flash. Im Gegensatz zu den meisten Microcontrollern sollte man aber nicht davon ausgehen, dass die Organisation des Bitstreams oktettweise geschieht, da für die zu konfigurierenden Elemente (CLB, LUT, Multiplexer, I/O-Elemente, Block-RAM) deutlich abweichende "Breiten" benötigt werden. Bei CPLDs ist der Bitstreamspeicher üblicherweise im Baustein integriert.
Gast
#4763372
Heutige Bildschirme mit HDMI Stecker sind so komplex geworden - das kann ein einzelner gar nicht mehr vollständig überblicken. Gibt aber im Netz noch vollständige Beispiele mit alter, einfacher Technologie. Z.B. HD44780 Displays. http://www.sprut.de/electronic/lcd/ http://www.sprut.de/electronic/pic/programm/lcd_cgram/lcdcgram.html Wenn du das durchgearbeitet hast, findest du auch umfangreichere Beispiele für graphische Displays. Für alte Homecomputer finden sich auch noch vollständige Beispiele. Bei modernen wird das aufgeteilt. Die einen schreiben das Anwendungsprogramm, die anderen das Betriebssystem, noch andere die Hardwaretreiber. Alle 3 Gruppen wissen selbst nicht, wie man den Prozessor über PCI, Grafikkarte und HDMI mit dem Pixel auf dem Bildschirm verbindet.
Gast
#4763375
Noch einer schrieb: > Heutige Bildschirme mit HDMI Stecker sind so komplex geworden - das kann > ein einzelner gar nicht mehr vollständig überblicken. Ach Gott, HDMI lernt ein ET-Ing. spätestens im 5. Semester..
Gast
#4763469
> HDMI lernt ein ET-Ing.
Genau da liegt das Problem.
Der Elektrotechnik-Ingenieur lernt, wie man Gigabit über so ein Kabel
schaufelt. Der eine Systemprogrammierer lernt, wie man Gigabit über PCI
schaufelt. Der andere, wie man aus Opengl schnell genug Gigabits an
Daten erzeugt. Der Anwendungsprogrammierer lernt, wie man aus einem
3D-Modell Opengl-Befehle macht. Und der Leveldesigner lernt, wie man aus
einer Skizze ein 3D-Modell macht.
Aber keiner kann mehr direkt in Assembler ein Pixel auf so einem
Bildschirm setzen.
Paule Panik schrieb: > HDMI lernt ein ET-Ing. spätestens im 5. Semester.. echt? Ich wette hier sind viele die das naturgemäß nicht im 5. Semester hatten :)
Gast
#4763484
Noch einer schrieb: > Aber keiner kann mehr direkt in Assembler ein Pixel auf so einem > Bildschirm setzen. Da musst du einfach mal die Leute fragen die die Firmware für die Monitore schreiben, die sollten sowas können. Der nächste mögliche Einstiegspunkt währe dann ein direkter zugriff auf den Videospeicher der Grafikkarte. So ähnlich wurde das auch bei den Homecomputern gemacht. Moderne Systeme sind aber eigentlich für solche Hacks am Betriebssystem vorbei nicht ausgelegt. Aber wer will sollte es doch hinbekommen sowas direkt auf einer RPI ohne Betriebssystem hinzubekommen. Wenn unbedingt nötig wohl auch in Assembler. Viel Spaß dabei!
Gast
#4763499
Poster schrieb: > Moderne Systeme sind aber eigentlich für solche Hacks am Betriebssystem > vorbei nicht ausgelegt. > Aber wer will sollte es doch hinbekommen sowas direkt auf einer RPI ohne > Betriebssystem hinzubekommen. bare metal, Siehe: http://www.valvers.com/open-software/raspberry-pi/step05-bare-metal-programming-in-c-pt5/ oder per Linux -framebuffer device: http://raspberrycompote.blogspot.de/2013/03/low-level-graphics-on-raspberry-pi-part.html Aber mit PEEK und POKE war alles einfacher ;-)
Gast
#4763572
Raspi ist da ein recht ungünstiges Beispiel. Broadcom gibt nicht genug Doku und Sourcecode heraus. Man kann zwar herausfinden, wie man ein Pixel im Framebuffer setzt. Aber nicht mal echte Hacker können den GPU Programmcode rekonstruieren, der das Pixel auf den Monitor bringt. Bein ZX80 waren Firmware, TTL-Logik und BAS-Signal noch so einfach, das konnte man unmittelbar nachvollziehen.
heute ist freitag?
ja
er sollte sich mal in der "demo szene" umsehen, daort wird sowas noch gmacht. er weiß aber warscheinlich nicht was ich mit der "demo szene" meine :)
Gast
#4763666
Danke für die vielen und umfangreichen Antworten!
Gast
#4765433
Der Threadersteller kann sich auch mal bei wiki.osdev.org und www.lowlevel.eu umsehen. Das sind zwar seiten für Betriebssystemprogrammierung, aber dort wird auch VGA von Softwareseite beschrieben - also Register der Grafikkarten die für VGA noch standardisiert sind. Jedenfalls gibt das einen ersten Anhaltspunkt und ist der beste Weg, wenn man den Monitor mit einem PC ansteuern möchte. Ich würde generell mit VGA anfangen, das lässt sich wahrscheinlich noch am einfachsten verstehen/nachbauen. Eine Suche nach "VGA Signal" und "VGA Timings" bringt viele Informationen über das Hardwareprotokoll darüber zu Tage. Das ist dann interessant, wenn man mit einem Mikrocontroller oder FPGA einen Monitor direkt ansteuern möchte. Einen Hinweis: Das ist wesentlich komplexer als man vermutet, wenn man noch keine Ahnung davon hat. Und wie der Bildschirm das Signal dann als Bild anzeigt... dazu müsstest du Monitore nachbauen. Und das geht echt zu weit, weil dazu die Technik fehlt. Oder kannst du zu Hause LCD-TFT Panels herstellen?
Gast
#4765475
Poster schrieb: > Noch einer schrieb: >> Aber keiner kann mehr direkt in Assembler ein Pixel auf so einem >> Bildschirm setzen. > > Da musst du einfach mal die Leute fragen die die Firmware für die > Monitore schreiben, die sollten sowas können. Einfach fragen? Wie viele gibt es denn davon weltweit? 100? 1000? Das sind ganz seltene, rare Tierchen. Wenn du einen gefunden hast, darf der vermutlich nicht mal mit dir reden. Alles Firmengeheimnisse.
Mirogon schrieb: > Angenommen ich könnte Assembler, wie müsste ich vorgehen um zum Beispiel > einen bestimmten Pixel eines Bildschirmes zu verändern? Wenn Du von VGA auf PC Sprichst müsstest Du zunächst den Farbwert den Du dem Pixel geben willst in die Farbwertetabelle des RAMDAC laden (oder der ist dort schon vorhanden)..... Danach müsstest Du die Position deines Pixels relativ zum Anfang des Graphikspeichers (0xA0000) bestimmen, einen Schreibzeiger mit dem Wert laden und die Farbcodenummer (das ist auch wieder ein Zeiger der auf den konkreten Farbwert im RAMDAC zielt) an diese Stelle im Graphikspeicher schreiben.
Gast
#4765550
Mirogon schrieb: > Angenommen ich könnte Assembler, wie müsste ich vorgehen um zum Beispiel > einen bestimmten Pixel eines Bildschirmes zu verändern? Nimm doch QBasic! Zum Beispiel: SCREEN 12 CLS PSET(200,100) Dann hast du auf einem schwarzen Bildschirm in Spalte 200 und Zeile 100 einen weißen Bildpunkt.
Schau evtl. mal hier: http://www.wagemakers.be/english/doc/vga
Günter Lenz schrieb: > Nimm doch QBasic! > Zum Beispiel: > > SCREEN 12 > CLS > PSET(200,100) > > Dann hast du auf einem schwarzen Bildschirm in Spalte > 200 und Zeile 100 einen weißen Bildpunkt. QBASIC ist von Hardwarenaher Programmierung genauso weit entfernt wie Facebook vom Datenschutz.
Gast
#4766764
Jack schrieb: > Einfach fragen? Wie viele gibt es denn davon weltweit? 100? 1000? Das > sind ganz seltene, rare Tierchen. Selbst 100 sind aber immer noch mehr als die behaupteten "niemand" :) Es werden ja wohl auch die wenigsten mal je in Lage kommen ein Displaypixel so direkt ansprechen zu müssen. Und wenn doch ist es eher ein Problem die passenden Datenblätter des Displays, des Schnittstellenprotokolls oder des verbauten Controller zu bekommen als die eigentliche Programmierung in Assembler.
Poster schrieb: > Es werden ja wohl auch die wenigsten mal je in Lage kommen ein > Displaypixel so direkt ansprechen zu müssen. was verstehst du unter direkt? nehme ich irgendein Grafikdisplay dann muss ich für ein 'A' jedes Pixel direkt programmieren wenn kein Fontgenerator im Displaycontroller ist oder ich kann auf eine LIB zugreifen.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.