Hallo, an einen Arduino mega 2560 will ich einen Monitor anschliessen, er hat HDMI/VGA/AV Eingänge. Wie kann ich das Signal per Controller erzeugen?
Und wozu soll das gut sein ? Wahrscheinlich würde das Treibermanagement für die Montitore schon über 70% der Kapazität des Megas beanspruchen, sofern es überhaupt klappt. Besorg dir nen Raspberry Pi mit entsprechender HDMI / microHDMI Schnittstelle. Ansonsten steht dir für eine Datenübertragung RS232/ I2C etc. Zur Verfügung, natürlich mit entsprechendem "Rechner" am anderen Ende.
R. F. schrieb: > Hallo, > > an einen Arduino mega 2560 will ich einen Monitor anschliessen, er hat > HDMI/VGA/AV Eingänge. Wie kann ich das Signal per Controller erzeugen? Indem du einen Grafikcontroller ansprichst, der seinerseits HDMI/VGA/AV ausgeben kann. Alternativ kannst man VGA/AV auch (sehr eingeschränkt) mit einem M2560 direkt erzeugen. Aber du kannst das nicht. Soviel dürfte sicher sein... Es gibt aber in "Projekte & Code" funktionierende Beispiele für AVR8, wie sowas zu lösen wäre. Vielleicht reicht deine Kompetenz ja, diese Lösungen für deine Zwecke zu assimilieren... Vermutlich ist aber auch dies nicht der Fall... Die Frage hört sich einfach schon viel zu sehr nach Arduidiot an...
Ich will eine Art Tischrechner entwerfen. Eine tastatur dient als Eingabe, der Monitor als Ausgabe. Das Gerät soll rechnen können, PWM ausgeben, I²C und SPI ausgeben und lesen können, Ports lesen und schreiben können und den ADC auslesen. Der Einsatz erfolgt als universelles Laborgerät,welches z.B. durch bestimmte Ereignisse Signale ausgibt oder messungen vornimmt. Ich habe zunächst an ein Display eines alten Handys gedacht, in Zusammenhang mit der tastatur sind Funktionen einfach aufzurufen und deren Ergebnisse darstellbar. Nachteil ist, dass es nicht ohne weiteres möglich ist, eine Verbindung zum PC aufzubauen, wo Messwerte weiter verarbeitet werden können. Die USB-Schnittstelle des handys ist idR nicht als Master geeignet. An Monitoren finde ich aber nur welche mit den og. Protokollen. Das ist das Problem. Als Software denke ich derzeit an ein Forthsystem, welches verfügbar ist. Any comments??
R. F. schrieb: > Als Software denke ich derzeit an ein Forthsystem, > welches verfügbar ist. Sowas? Beitrag "Forth-Computer mit ATMega 32 und Videoausgabe"
R. F. schrieb: > Ich will eine Art Tischrechner entwerfen. Eine tastatur dient als > Eingabe, der Monitor als Ausgabe. Das Gerät soll rechnen können, PWM > ausgeben, I²C und SPI ausgeben und lesen können, Ports lesen und > schreiben können und den ADC auslesen. Der Einsatz erfolgt als > universelles Laborgerät So ein Gerät gibt es bereits. Es heißt PC. Warum willst du das in schlecht neu erfinden?
Ein Interpreter mit Monitorausgabe und Editor a la Mmbasic passt in den Kontext.
Viele "Display-OSD Controller" kann man per I2C auch "direkt" am AVR verwenden. Der dient bereits als Mini-Grafikkarte (für Text) und ist schon im Anzeigegerät drin. Oft über den VGA-Anschluss angreifbar. Schau mal in die PDFs der ICs und ob des schon so bei dir Verdrahtet ist.
:
Bearbeitet durch User
Für VGA: der ColorMaximite (https://geoffg.net/OriginalColourMaximite.html) kann das, der benutzt einen PIC32MX795. Seine Nachfolger (Color Maximite 2) nimmt einen STM32 und kann dann auch 800x600 Pixel. Man kann das natürlich alles selber erfinden, aber warum sollte man? Wobei bei den Anforderungen des TE (Tastatur, HDMI-Monitor, frei wählbare Aktionen) ein RPi als die bessere Wahl erscheint. Der kann bestimmt auch Forth.
Raspis haben aner keine ADWandler, keine PWM-Ausgabe, keine komparatoren, keine Triggereingänge. Nur GPIOs. Für die Auswahl war mir die Peripherie wichtig.
R. F. schrieb: > Raspis haben aner keine ADWandler, keine PWM-Ausgabe, keine > komparatoren, keine Triggereingänge. Nur GPIOs. Für diese Teilaufgaben nimmt man einen passenden µC und läßt ihn per I²C mit einem Raspi kommunizieren, der dann die Verarbeitung/Darstellung/Datenweitergabe etc. übernimmt. Dir fehlen jedoch offensichtlich elementare Grundlagen, sonst hättest du die Eingangsfrage gar nicht gestellt. Mit diesem Wissensstand wird es schwierig, die eigentlichen Aufgaben zu lösen.
>an einen Arduino mega 2560 will ich einen Monitor anschliessen, er hat >HDMI/VGA/AV Eingänge. Wie kann ich das Signal per Controller erzeugen? Mit einem VGA-Shield eventuell: https://www.electronics-lab.com/vgaduino-ii-graphic-shield-for-arduino/
R. F. schrieb: > Ich will eine Art Tischrechner entwerfen. Eine tastatur dient als > Eingabe, der Monitor als Ausgabe. Das Gerät soll rechnen können, PWM > ausgeben, I²C und SPI ausgeben und lesen können, Ports lesen und > schreiben können und den ADC auslesen. Der Einsatz erfolgt als > universelles Laborgerät,welches z.B. durch bestimmte Ereignisse Signale > ausgibt oder messungen vie vornimmt. Und wie viele Jahre Programmiererfahrung hast du schon? Falls du Anfänger bist: Rechne mit einigen Jahren Lernzeit, bis du so etwas hinbekommst.
ATMEGA (oder ESP32) + TFT per SPI Einfach mal gurgeln nach den Begriffen, gibt tausende Tutorials.
Wenn eh ein PC geplant ist, dann soll der gefälligst auch die Hauptarbeit machen. Den MC für die IO-Zugriffe schließt man über USB oder RS-232 an. Die Kommunikation erfolgt über Textkommandos, damit man einfach mitlesen kann. Vorzugsweise nimmt man einen Standard, z.B. SCPI. https://de.wikipedia.org/wiki/Standard_Commands_for_Programmable_Instruments
Angehängte Dateien:
Etwas einfacher geht Video, also (F)BAS. Statt 480Zeilen nur etwa 250 (sichtbare, ohne Zeilensprung) und statt 36 kHz nur 15kHz Zeilenfrequenz, also zusammen etwa 1/4 der Datenrate. Hier ein nie fertig gewordenes Projekt "Panoramaempfang mit RFM12"
Gameduino kann VGA. Ähnliches aber Richtung DVI/HDMI kenne ich nicht. Natürlich kann man den VGA umwandeln. Kurz gesagt, VGA ist nicht worauf man ein langlebiges Projekt bauen soll. Hobbymäsig ist ok :)
R. F. schrieb: > Raspis haben aner keine ADWandler, keine PWM-Ausgabe, keine > komparatoren, keine Triggereingänge. Nur GPIOs. Aber man kann sie anschließen. Wobei sich dann natürlich die Frage stellt, warum man sie nicht gleich an den PC anschließt. Z.B. per USB. Und wenn du dann so ein Kästchen hast, das per USB am PC hängt und am anderen Ende ADC und I²C und PWM und was du sonst noch alles brauchst hat - warum sollte man da dran dann noch einen extra Monitor und eine extra Tastatur anschließen? Der PC hat ja schon Tastatur und Monitor. Und ein Betriebssystem. Festplatte, Netzwerk. Tonnenweise Infrastruktur, die du früher oder später haben willst. Warum willst du das selber nochmal (und sicher schlechter) nachbauen? Solche Kästchen muß man auch nicht selber bauen, die kann man fertig kaufen. Aber es ist natürlich lehrreich, das selber zu bauen. Insofern: nur zu!
R. F. schrieb: > Ich will eine Art Tischrechner entwerfen. Eine tastatur dient als > Eingabe, der Monitor als Ausgabe. Das Gerät soll rechnen können, PWM > ausgeben, I²C und SPI ausgeben und lesen können, Ports lesen und > schreiben können und den ADC auslesen. Der Einsatz erfolgt als > universelles Laborgerät... Jedesmal wenn ich jemanden von einem "universellen Laborgerät" habe reden hören, wußte ich schon nach 1..3 Gegenfragen, daß das eine vergebliche Sache sein wird. Bedenke mal, daß all die Gedanken über Universalität immer nur aus der Vergangenheit herrühren und keineswegs in die Zukunft hineinreichen. Deshalb bin ich mir sehr sicher, daß du schon beim dritten Versuch, sowas einzusetzen, feststellen mußt, daß es genau dafür grad nicht so recht geeignet ist und deine Idee von der Universalität ne Bauchlandung gemacht hat. Was du hingegen schon eher machen kannst, ist etwas leicht abgewandeltes: 1. Besorge dir ein nettes kleines Gehäuse, wo ein LCD und ein Drehgeber und einige wenige Tasten dran passen. 2. Suche dir dann einen µC aus, der ausreichend leistungsfähig ist und den du leicht und OFT umprogrammieren kannst. 3. Wenn du ein simples Alpha-LCD hast, reicht ein ATMega o.ä. aus, wenn es ein Grafik-LCD ist, dann solltest du eher einen 32 Bitter vorsehen. Für derartige Zwecke reichen die üblichen 128x64 oder ähnliche Größen aus. 4. Suche dir ein Sortiment an sinnvollen Steckverbindern aus, mit denen du die diversen Pins des µC, die nicht von Display+Bedienelementen verbraucht sind, nach außen führen kannst und/oder irgendwelche sonstige Peripherie antreiben können. Beispiel für UART: GND+5V+RxD+TxD, für SPI: GND+5V+MISO+MOSI+SSEL na und so weiter. 5. Freunde dich mit dem Gedanken an, daß du für verschiedene Zwecke das Ding alle nase lang umprogrammieren wirst, um genau das drin zu haben, was du gerade brauchst. Die Alternative ist tatsächlich der PC plus irgend ein passendes µC-Minimal-Board und dort eben eine Firmware drauf, die bereits die Kommunikation mit dem PC beinhaltet und wo du passend zu deinem jeweiligen Meßproblem den Kommando-Interpreter in der Firmware leicht um ein paar Kommandos erweitern kannst. Das wäre die Version, die noch am ehesten universell und leicht umzustricken genannt werden kann. W.S.
Angehängte Dateien:
-
P1080461.JPG
310 KB -
P1080463.JPG
240 KB -
P1080462.JPG
360 KB -
P1080464.JPG
370 KB -
P1080465.JPG
240 KB -
P1080466.JPG
300 KB -
P1080467.JPG
300 KB
Das wäre mein Vorschlag. Weil ich es schon seit Jahren so mache. Hier sind ein paar Beispiele, meist mit PSoC5LP Controller (Cypress, gehört jetzt zu Infineon), oder Arduino. Die USB- Tastatur passt auch in der Größe gut zu einem kleinen System. Brauchst Du das für Lehrzwecke oder um selbst zu lernen? Bei Bedarf kann ich die Baugruppen auch abgeben, zum Selbstkostenpreis. Das letzte Display ist seriell, es braucht weniger Anschlüsse. Mit ePaper bin ich selbst noch am Üben...
Zuerst habe ich auf das Datum geschaut. Die Frage ist tatsächlich von 2020..... Aber falls der TE wirklich so etwas machen will: ich habe noch einen Röhrenfernseher mit Antennenanschluss günstig zu verkaufen. Und bei meinem ersten Rechner (ZX81) hat die CPU ja auch ganz alleine das Bild erzeugt und an einen Fernseher gegeben. Irgendwo gibt es bestimmt noch den Z80-Code für die TV-Ausgabe. z.B.: https://cdn.hackaday.io/files/289631239152992/ZX81_dual_2018-02-09.htm
R. F. schrieb: > An Monitoren finde ich aber nur welche mit den og. Protokollen. Mit UART, SPI und I2C (und viel handlicher): https://www.lcd-module.com/produkte/ediptft.html
PittyJ schrieb: > Aber falls der TE wirklich so etwas machen will: ich habe noch einen > Röhrenfernseher mit Antennenanschluss günstig zu verkaufen. Besser ist natürlich RGB-fähiges SCART. Das haben noch viele im Umlauf befindliche TV-Geräte. Aber für Neuentwicklungen ist es trotzdem nicht mehr zu empfehlen, denn das Aussterben dieser Schnittstelle ist sehr absehbar. Das sieht für VGA aber noch besser aus. Das gibt es immerhin auch an vielen aktuell kaufbaren Monitoren noch. Allerdings auch hier: die fallende Tendenz ist unübersehbar. > Und bei meinem ersten Rechner (ZX81) hat die CPU ja auch ganz alleine > das Bild erzeugt und an einen Fernseher gegeben. Also: erstens stimmt das nicht, sie brauchte einen Helfer-Chip dazu. Und zweitens erfolgte selbst mit diesem Helfer-Chip die Ausgabe nicht annähernd mit der Auflösung und Farbtiefe, die der TV erlaubt hätte. Da kommt man mit einem ATmega2560 schon deutlich weiter.
> Ich will eine Art Tischrechner entwerfen. Musst du nicht. Gibt es schon: > Eine tastatur dient als Eingabe, PS/2 oder Terminalprogramm und integrierter serieller USB-Adapter. > der Monitor als Ausgabe. Wahlweise (SW-) VGA 480x432, PAL 304x216, NTSC 480x234 oder natuerlich wieder das Terminalprogramm. VGA, PAL und/oder NTSC erzeugt die CPU nebenbei mit. NTSC 480x234 kann sehr gut formatfuellend mit handelsueblichen Rueckfahrmonitoren dargestellt werden. > Das Gerät soll rechnen können, Na sicher. Etwa 10x so schnell wie der alte C64. Wenn das nicht reicht, kann man seine Funktionen auch in C/Assembler schreiben, und dann im Programm aufrufen. Mit 32 bit und 80 MHz. > PWM ausgeben Ja. > I²C und SPI Man kann auf fast beliebigen Pins I²C und SPI > ausgeben und lesen > Ports lesen und schreiben können Geht natuerlich. > und den ADC auslesen. Kann man auf 6 Pins. 0 - 3.33 V. Daneben kann es auch noch Frequenzen und Periodendauern messen oder einfach Impulse zaehlen. Oder mit Geraeten auf einem CAN-Bus reden. Massenspeicher ist eine SD-Card. Einige GB sind also kein Problem. Stromversorgung extern von 9 V - 30 V, per LiO-Akku der auch vom/im Geraet aufgeladen werden kann, oder per USB. Programmiert wird das Dingens im guten BASIC. Das kann auch Interrupts und eine Systemuhr bedienen. Der Interpreter steht als Quelle fuer eigene Erweitungen zur Verfuegung. Wenn z.B. die Eingabegeschwindigkeit der AD-Wandler per BASIC zu gering ist, schreibt man sich diesen Teil dann einfach selber, in C und/oder Assembler. Man muss eigentlich "nur" das Platinchen in eine Box versenken, und die IO-Pins zugaenglich machen... Also vergiss deinen uralten Mega2560 mal schnell wieder.
Irgendwo schlummer noch ein Beitrag zur Erzeugung eines Testbildes für den Video-Eingang von Fernsehern und Monitoren mit so einem Prozessor. Vielleicht erinnert sich noch Jemand daran. Gefunden auf die Schnelle habe ich etwas, aber in Erinnerung hatte ich noch was anderes. https://www.elektormagazine.de/magazine/elektor-200310/1755 https://www.roboternetz.de/community/threads/26427-Atmega%288%29-Testbildgenerator Beitrag "VGA Testbildgenerator"
Nun ja, ein Testbild ist als Ausgabe doch etwas duerftig. Testbilder koennen ja schon uralte (8 bit-)PICs. Wuenschenswerterweise sollte man aber schon einzelne Bits in einer Grafik ein- und ausschalten koennen. Geruechteweise kann man damit dann sogar frei skalierbaren Text ausgeben.
Entweder, wie schon vorgeschlagen, einen Raspi mit geignetem Terminalprogramm. Ein Raspi Zero sollte als Terminal reichen. Die damit verfügbare Netzwerk-Schnittstelle macht die Datenübergabe an einen PC zur Weiterverarbeitung recht einfach. Alternativ einen Raspi Zero als "Bare Metal Pi Zero ANSI Terminal", das auch einige einfache Grafik-Elemente beherrscht: - support for USB or Ps2 keyboard - some graphics primitives like lines - more graphics primitives (circles, rectangles etc.) - resolution being configurable without recompiling - Load configuration from SD card - some kind of sprite handling with collision detection https://github.com/fbergama/pigfx
ein interessantes Thema, das mich auch schon ewig interessiert. Wenn jetzt nicht all die dämlichen Kommentare dazwischen wären wozu das gut sein soll, nimm Raspi etc. pp wäre die Diskussion sicher auch interessant. Mein Interesse liegt auch eher an einer "Grafikkarte" für AVR/ARM. Das Signal mit dem AVR sirekt zu erzeugen fände ich eher ungünstig und würde viel zu viele Nachteile gerade für Anfänger bringen Und zur Frage was das sol..kann ich nur sagen traurig. Es gibt unendlich viele Einsatzgebiete für solch Systeme, streng deinen Kopf mal an
Am Raspi lassen sich ggf. auch Displays anschliessen, die ab 5" Größe aufwärts mit HDMI-Eingang in vielen Varianten günstig zu haben sind. Damit lassen sich auch kleine portable Komplettsysteme bauen, die falls erforderlich in ein LAN/WLAN eingebunden werden können.
und ja, eine alte ISA Grafikkarte hatte ich auch schon mal angedacht
Tim Schnurz schrieb: > Wenn jetzt nicht all die dämlichen Kommentare dazwischen wären wozu das > gut sein soll, nimm Raspi etc. pp wäre die Diskussion sicher auch > interessant. Von vorneherein eine der einfachsten Lösungen auszuschliessen, zeugt indes auch nicht von Niveau. Man kann solch eine Aufgabe zwar auch mit scheinbar weniger Aufwand lösen, also AVR statt ARM, kByte statt GByte etc. Wird dann aber feststellen, dass der Aufwand effektiv grösser ist - und das Ergebnis weniger flexibel.
:
Bearbeitet durch User
Tim Schnurz schrieb: > Mein Interesse liegt auch eher an einer "Grafikkarte" für AVR/ARM. Der Raspi Zero IST DIE GRAFIKKARTE, die von VGA bis FullHD jedes Display, jeden Monitor mit HDMI bedienen kann. > Alternativ einen Raspi Zero als "Bare Metal Pi Zero ANSI Terminal", das > https://github.com/fbergama/pigfx Damit bleibt vom Raspi eigentlich nur die Hardware übrig, Beschäftigung mit dem Raspi Betriebsystem nicht nötig, keine nennenswerte Zeit zum Booten.
Raspi-Fan schrieb: > Tim Schnurz schrieb: >> Mein Interesse liegt auch eher an einer "Grafikkarte" für AVR/ARM. > > Der Raspi Zero IST DIE GRAFIKKARTE, die von VGA bis FullHD jedes > Display, jeden Monitor mit HDMI bedienen kann. Hatte ich vergessen: https://hackaday.io/project/9567-5-graphics-card-for-homebrew-z80 https://hackaday.io/project/9567-5-graphics-card-for-homebrew-z80/log/37351-bare-metal-pi-zero-ansi-terminal
Technisch gesehen sind die Broadcom-Chips, die den Kern der Raspis darstellen, Videosysteme mit ARM als Coprozessor.
A. K. schrieb: > Technisch gesehen sind die Broadcom-Chips, die den Kern der Raspis > darstellen, Videosysteme mit ARM als Coprozessor. Das ist böse, aber wahr.
nein, der Raspi ist keine Graikkarte, er bekommt lediglich diese Aufgabe zugeteilt. Aber rein vom Bastlerischen ist es die bescheuertste Lösung. Dann kann man wie bereits gesagt, auch gleich nur den Raspi nehmen. Und wenn ich solch Konstruke baue brauche ich auch kein Raspi, dann nehme ich gleich den PC und kaufe eine fertige Software... Ich frage mich manchmal in was für einem Forum ich hier gelandet bin. Sind hier nur noch die Malen nach Zahlen Kids unterwegs?
und Textausgabe über Composite ist sowieso kacke, VGA oder RGB muss es schon sein
Tim Schnurz schrieb: > Sind hier nur noch die Malen nach Zahlen Kids unterwegs? Kannst es auch lösungsorientiertes Denken nennen. Gehts darum, mit Technik aus dem letzten Jahrhundert zu arbeiten, oder mit heutiger? Nix gegen beides, aber man sollte vorher klären, ob es um Retro geht, oder um die Lösung eines realen Problems.
:
Bearbeitet durch User
Tim Schnurz schrieb: > nein, der Raspi ist keine Graikkarte, er bekommt lediglich diese > Aufgabe zugeteilt. Nein. tatsächlich ist der Raspi de facto eine recht performante Graka mit angehängter ARM-MCU. Das ist einfach so. > Aber rein vom Bastlerischen ist es die bescheuertste Lösung. Nicht unter Kostenaspekten. Es gibt keine kostengünstigere Lösung, eine attraktive Grafik über neuzeitliche Schnittstellen für schmalbrüstige µC bereitzustellen, als einen Raspi (Zero oder CM) als Graka zu benutzen. > Dann kann man wie bereits gesagt, auch gleich nur den Raspi nehmen. Nein. Dann musst du den ARM-Teil davon selber programmieren, bare metal. Das ist ein ganz andere Klasse als einen primitiven AVR8 zu programmieren. Und viel der verfügbaren Peripherie ist leider schlicht unbrauchbare Scheiße. Da kann sogar ein oller Mega2560 noch punkten...
OT RPi: Ist eigentlich der X-Server (oder das was man heute dafuer haelt) mittlerweile hardwaremaessig auf irgendeine Weise 2D-beschleunigt? Oder malt man da immer noch im Framebuffer rum?
Beitrag #6392927 wurde von einem Moderator gelöscht.
Larry schrieb: > Ist eigentlich der X-Server (oder das was man heute dafuer haelt) > mittlerweile hardwaremaessig auf irgendeine Weise 2D-beschleunigt? Youtube im Browser geht auch in Linux, und braucht dazu keine superdicke CPU. Reicht das als Antwort? Der Videoprozessor vom Raspi ist kein einfacher Framebuffer und wird auch nicht nur als solcher genutzt.
:
Bearbeitet durch User
R. F. schrieb: > Ich habe zunächst an ein Display eines alten Handys gedacht, in > Zusammenhang mit der tastatur sind Funktionen einfach aufzurufen und > deren Ergebnisse darstellbar. Nachteil ist, dass es nicht ohne weiteres > möglich ist, eine Verbindung zum PC aufzubauen, wo Messwerte weiter > verarbeitet werden können. Die USB-Schnittstelle des handys ist idR > nicht als Master geeignet. Das war bisher dein bester Gedanke und ist auch relativ einfach zu realisieren. Es gibt gute kleine Displays mit SPI-Schnittstelle. Kosten so ca. 50-100 Euro je nach Leistung. Die haben ein eigenen Controller der über SPI angesteuert wird. Einige sogar Touch-Screen. Die Kommunikation mit den PC ist noch einfacher. Variante 1 : Ein USB-Kabel und dann via Serial, das reicht locker zum Daten übertragen. Nachteil : Du hast ne Stripe da liegen Variante 2 : Funk im irgend einer Form. Nachteil : Du brauchst ein Empfänger. Das alles ist für den lahmen Arduino ohne Probleme zu bewältigen. Die Ansteuerung einer VIDEO-Schnittstelle ist Schwachsinn.Das schafft das lahme Teil nicht. Akzeptiere das einfach. Mach dich mal über so Sachen wie Bildaufbau Auflösung Wiederholfrequenzen und bei HDMI DRM-Rechte + Verschlüsselung vertraut. Ich bin mutig aber daran traue ich mich nicht mal im Traum. Die Idee mit den Raspberry ist machbar aber sehr aufwendig. Und eigentlich nur dafür da den Bildschirm etwas schöner zu gestalten. Ich würde folgendes machen. (Variante 2). Ein schönen Programm schreiben (in VB weil das meine Lieblingssprache ist). Dann ein kleinen Arduino nehmen mit 433 MHZ-Sender/Empfänger drauf. Den an einen USB-Port hängen. Via VB eine Serial-Verbindung zu den Teil aufbauen. Das Teil übernimmt den Funk zum MEGA und das war's. In VB baue ich mir eine schöne Anzeige und füttere Sie mit den Daten die der kleine Arduino-NANO vom großen Mega bekommt. Fertig. Ach und noch was : Der Mega heißt Mega weil er viel mehr Speicher und Anschlüsse hat, nicht weil er Mega-Schnell ist. ;)
> Youtube im Browser geht auch in Linux, und braucht dazu keine superdicke > CPU. Reicht das als Antwort? Utube ist fuer mich nicht relevant. > Der Videoprozessor vom Raspi ist kein > einfacher Framebuffer und wird auch nicht nur als solcher genutzt. Ja das der Videoprozessor kein einfacher Framebuffer ist, dass weiss ich schon. Nur mangelte es wohl bislang am fehlenden Support und Dokumentation um: kann er z.B. Flaechen mit HW-Support fuellen? Oder Grafiken per HW blitten? Daher die Frage ob sich das vom Niveau jetzt real ueber dem einfachen Framebuffer befindet. Wie der Browser seine Videos beschleunigt, ist da ja eine ganz andere Schiene, und hat mit der generischen 2D-Beschleunigung u.U. nicht viel oder gar nichts zu tun. Insoweit reicht das nicht als Antwort.
Larry schrieb: > kann er z.B. Flaechen mit HW-Support fuellen? > Oder Grafiken per HW blitten? OpenGL kann all das und noch viel mehr. Der RasPi kann OpenGL. Reicht das als Antwort? Und ja, OpenGL kann man auch außerhalb von 3D-Spielen nutzen, z.B. für 2D-Desktops. Für reine 2D-Blitts etc gabs/gibts schon X11-Befehle, die dann hardwarebeschleunigt ausgeführt werden (sollten). Wichtig z.B. für X11 über Netzwerk/SSH-Tunnel, damit das Bitgeschiebe eben nah am Display läuft und nicht über's Netzwerk muss. Verwenden moderne Toolkits so gut wie garnicht mehr. Es ist einfach inzwischen schneller über einem Memory-Mapped Buffer selber ein paar 100 Bytes im Grafik-RAM hin und herzu schieben anstatt einen X11-Call durch x Abstraktionsebenen zu schieben.
R. F. schrieb: > Ich habe zunächst an ein Display eines alten Handys gedacht Oder du lässt das Display im Handy und gönnst dem Controller ein Bluetooth-Modul. Darstellung und Interaktion macht dann das Handy in Absprache mit dem Controller. So habe ich das einstmals gemacht.
:
Bearbeitet durch User
R. F. schrieb: > Hallo, > an einen Arduino mega 2560 will ich einen Monitor anschliessen, er hat > HDMI/VGA/AV Eingänge. Wie kann ich das Signal per Controller erzeugen? mit einem TFT Shield zum Aufstecken und mit dem Raspi per Cammodul oder USB webcam auf HDMI ausgeben!
:
Bearbeitet durch User
R. F. schrieb: > Raspis haben aner keine ADWandler, keine PWM-Ausgabe, keine > komparatoren, keine Triggereingänge. Nur GPIOs. > > Für die Auswahl war mir die Peripherie wichtig. Der PCDDuino wäre dafür die geeignetere Wahl. Der Cubietruck hätte auch ein paar solche Ausgänge. Für VGA oder Video-Eingang kann der Testsignalgenerator durchaus verwendet werden. Für einfarbigen Text sei aber angemerkt, dass jedes Pixel dann einem Bit im Ram zugeordnet werden muss. 1K reicht dann für 100x80 Bildpunkte oder Textausgabe von 12 Zeichen je Zeile und 10 Zeilen. Unter DVI/HDMI/Videoport ließe sich auch nur der Wiederholspeicher eines Monitors direkt beschicken. Das habe ich noch nirgends realisiert gesehen und auch nichts bisher von einem Beispiel dazu gelesen.
c-hater schrieb: > Besser ist natürlich RGB-fähiges SCART. Das haben noch viele im Umlauf > befindliche TV-Geräte. Aber für Neuentwicklungen ist es trotzdem nicht > mehr zu empfehlen, denn das Aussterben dieser Schnittstelle ist sehr > absehbar. Für text-basierte Anzeigen hatte ich irgendwo im I-Net einen Video-Text Coder gesehen. Der Video-Text wird auch noch in modernen, flachen, digitalen Fernsehern unterstützt...
> hardwarebeschleunigt ausgeführt werden (sollten). Ja werden sie nun oder nicht? > Es ist einfach > inzwischen schneller über einem Memory-Mapped Buffer selber ein paar 100 > Bytes im Grafik-RAM hin und herzu schieben anstatt einen X11-Call durch > x Abstraktionsebenen zu schieben. Nun, bei heutigen Aufloesungen sind es eben nicht nur "ein paar 100 Bytes". Und fuer ein Blit reicht im Regelfall auch kein blankes Kopieren. Und "Fill" und "Blit" sind Grafikgrundoperationen die keineswegs hinter "x Abstraktionsebenen" versteckt liegen. > OpenGL kann man auch außerhalb von 3D-Spielen nutzen, z.B. für > 2D-Desktops. Welche "normale" Desktopumgebung benutzt denn OpenGL fuer ihre Darstellung? Ist der OpenGL Port in allen Teilen fuer den RPi als Quelle verfuegbar? Was haben Programme die native Methoden von X, wie "Fill" und "Blit" benutzen wollen, von OpenGL? Mein bisheriger Eindruck beim RPi ist, dass sich alles was elementare Grafikoperation angeht, immer irgendwie "schneckig langsam" aka "unbeschleunigt" angefuehlt hat. Das das an der Hardware liegt glaube ich nicht, eher an mangelnder Kooperation von Brotkom.
Larry schrieb: > Nun, bei heutigen Aufloesungen sind es eben nicht nur > "ein paar 100 Bytes". > Und fuer ein Blit reicht im Regelfall auch kein blankes Kopieren. > Und "Fill" und "Blit" sind Grafikgrundoperationen die > keineswegs hinter "x Abstraktionsebenen" versteckt liegen. Trotzdem haben sich (fast?) alle GUI-Toolkits dazu entschlossen, das selber, per lokalem Speicherzugriff und per CPU, zu machen. Genau wie das Font-Rendering, das macht auch so gut wie kein Programm mehr am X-Server. Ist jetzt schon viele viele Jahre so, die Umstellung war damals ein großes Ding, weil es eben die Verwendung von X11-Programmen über's Netzwerk benachteiligt. Font-Antialiasing und schick designte Buttons waren damals eben wichtiger. Ansonsten schau dir "Glamor" an, ist eine X11-Extension um alle beschleunigungswürdigen 2D-Operationen transparent auf entsprechende OpenGL-Funktionen zu mappen. Larry schrieb: > Welche "normale" Desktopumgebung benutzt denn OpenGL > fuer ihre Darstellung? Zählt "KDE" als normale Desktopumgebung? KDE macht das, wenn man es lässt.
Route_66 H. schrieb: > Für text-basierte Anzeigen hatte ich irgendwo im I-Net einen Video-Text > Coder gesehen. Naja, es kommt darauf an, was der ausgibt. Wenn das auch bloß analoges RGB mit Video-Timing ist: das kann ein Mega2560 selber leisten. > Der Video-Text wird auch noch in modernen, flachen, digitalen Fernsehern > unterstützt... Ja, aber wenn die halt keine analoge Schnittstelle haben, muß der Videotext in digitaler Form in den Datenstrom einer modernen Schnittstelle reingehäkelt werden. Und das ist etwas, was ein Mega2560 halt nicht kann, nichtmal näherungsweise.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.