Hi, welchen Weg empfehlt ihr zur Implementierung eines Graphikdisplays, am besten mit Touchscreen für einfache aber schicke graphische Benutzeroberflächen, die man als Bedienfeld auf einen Mikrocontroller setzen kann. Programmierung der graphischen Oberfläche (1 Dialog zur Zeit) auf einem Controller, der die GUI steuert, meinetwegen z.B. mit Qt, Echtzeitanwendung z.B. im AVR, der mit dem GUI-Sytem über SPI oder so kommuniziert. Vielleicht gibt sowas mit Java? Im Prinzip wie ein Android-Handy mit entsprechender Schnittstelle zum Controller. Habe mal Gadgeteer gesehen, fand ich auch schick, aber noch zu proprietär. Hat jemand einen Tipp? Grüße - Jan
> der die GUI steuert, meinetwegen z.B. mit > Qt, Echtzeitanwendung z.B. im AVR, Das bedeutet dann, dass der GUI-Rechner dem eigentlichen Arbeitspferd um mindestens einem Faktor 1000 überlegen ist. Hmm.......
Jan Schirrmacher schrieb: > Hat jemand einen Tipp? > ...da gab es dieser Tage einen Beitrag auf hackaday.com, schaue doch mal nach, ob es das ist was du suchst...
Karl Heinz Buchegger schrieb: > Das bedeutet dann, dass der GUI-Rechner dem eigentlichen Arbeitspferd um > mindestens einem Faktor 1000 überlegen ist. > Hmm....... Es gibt oft genug Projekte, die dem Strom, den sie fressen, nicht würdig sind. Hautpsache Bling-Bling.
Jan Schirrmacher schrieb: > Hat jemand einen Tipp? Ja, druecke dich mal verstaendlich aus. Findest du wirklich aus Saetzen wie... "Habe mal Gadgeteer gesehen, fand ich auch schick, aber noch zu proprietär." ...kann man verwertbare Informationen gewinnen?
Was erwartest du von jemandem, der einen Atmega an ein Android-Handy anschließen will, um das Ganze dann mit Java zu programmieren?
Es gibt grafische Displays mit serieller Schnittstelle (RS232, SPI oder I2C) und integriertem Grafik_Controller und Speicher. Da kannst Du per Befehl Text und einfache grafische Formen ausgeben, zum Beispiel Linien und Kreise, die vom Display selbst gerendert werden. Diese Displays haben auch Flash Speicher, in den man Bilder und Videosclips ablegen kann, um sie später per Befehl einzublenden.
>Das bedeutet dann, dass der GUI-Rechner dem eigentlichen Arbeitspferd um
mindestens einem Faktor 1000 überlegen ist.
Hmm.......
Ja. Das war schon immer so. Der GUI Rechner kriegt eben kein gescheites
Timing hin, und die Zuverlaessigkeit ist auch nicht vorhanden.
Kan asta schrieb: > > Es gibt oft genug Projekte, die dem Strom, den sie fressen, nicht würdig > sind. Hautpsache Bling-Bling. Amen. Und dennoch - Hausautomation mit einem 20x2 LCD ist fürchterlich, mit 320x240 Monchrom ok und 640x480 in Farbe toll. Was solls, wenn dann am CANbus alle etliche 100ms ein Temperaturwert herumflutscht.... Grüße MiWi
> Hausautomation mit einem 20x2 LCD ist fürchterlich, Läuft mit einer Batteri ewig. > mit 320x240 Monchrom ok braucht Netzanschluss > und 640x480 in Farbe toll. zieht 24 Stunden 365 Tate mindestens 10 Watt, kostet also 20 EUR im Jahr - pro Bedienteil.
Da hatte ich grade vor kurzem eine Mail zu bekommen. http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en560014
MiWi schrieb:
Hausautomation mit einem 20x2 LCD ist fürchterlich,
Ja da muss ich zustimmen. Aber wenn der Controller (ich) im Hause ist,
dann läuft auch ein Rechner, und der hat eine hübsche Konsole...
Hast du schonmal über nen Raspberry Pi nachgedacht? Da hast du nen HDMI ausgang und es leuft nen Linux drauf. Denn so wie es sich anhört, hast du wenig Ahnung von Controllern im allgemeinen. Das ist nicht böse gemeint, aber die Ansteuerung eines grafischen Displays ist kein Einsteigerprojekt, da es viel Rechenleistung und Knowhow vorraussetzt. Ein Controller der mir da spontan einfällt ist das STM32 Board. Ich weiß zwar grad nicht wie das Interface heißt, aber da kannst du dein Bild in den Speicher legen und der Controller schriebt das automatisch an den Bildschirm raus. Wird aber auch in C programmiert
Kan asta schrieb: > Was erwartest du von jemandem, der einen Atmega an ein Android-Handy > anschließen will, um das Ganze dann mit Java zu programmieren? So oder so aehnlich wird das haeufig gemacht. Das ist bei der Frage nun wirklich nicht das Problem.
Sorry aber ein Rasperry Gay kommt mir nicht ins Haus. Weshalb auch? Ich habe schon 2 Embedded-Linux-Systeme als Router, und noch eins in der Tasche... Das STM32 ist ein brauchbares Board. Ansonsten ging es ja ursprünglich um eine GUI, und wie gesagt, wenn etwas per Hand eingestellt werden muss mach ich das dann doch am liebsten per PC.
Moment hab ich da jetzt nen Verständnissfehler drin? Ist die Gui jetzt auf dem PC oder dem Controller und von wo nach wo gehen nun die Signale und was genau willst du damit steuern?
So wie ich das verstanden habe - auf dem Controller. Also eigentlich auf einem eigenen GUI-Controller. Also im Grunde ein 'graphisches Terminal'. Qt finde ich trotzdem mit Kanonen auf Spatzen. Für eine Hausautomation braucht man ja nicht wahnsinnig viel an GUI Fähigkeiten. Ein Menüsystem, mit dem man in Sub-Seiten verzweigen kann, auf dem dann Werte angezeigt werden und dazu noch je nach Wert eine Einstellungssache (Slider bzw. Ein/Aus Knopf) sollte es ja für ein Hausautomationssystem fürs erste tun. Das ganze mit einem netten Hintergrundbild, welches zb als PNG auf den Montor geworfen wird, Wert-Ausgabefelder, eine stilisierte LED, noch ein paar Controls mehr. Die ganze Sache, die GUI kompliziert macht, mit mehreren Fenstern, die sich teilweise überlappen, Update-Listen, Message-Verteilung in diverse Subfenster, routen der 'Mausposition' an den richtigen Thread und dort ins richtige Subfenster und Capture Behandlung, ist ja so erst mal nicht notwendig bzw. kann ganz einfach gehalten werden. Ich würde mich da nicht auf Qt versteifen, sondern mir selbst was machen (wenn ich es nicht als fertiges Touch-LCD samt zugehöriger Lib kaufe). So aufwändig ist das auch wieder nicht, damit das einigermassen schön aussieht. Mit Rechtecken in verschiedenen Farben, Linien in verschiedenen Farben und Textausgabe kommt man schon sehr weit um sich seine eigenen Ausgabecontrols zu machen und damit eine 'Oberfläche' in Form eines Vollbildseite zu erzeugen.
Gute Idee. Viel Arbeit und am Ende sieht es aus wie in den 80ern. Sehr sinnvoll, aber nun ist mir klar, warum zum Beispiel meine nagelneue Gegensprechanlage zwar teuer ist, aber technisch die Rache des C64 zu sein scheint. Auch hier war der Griff in's Fertigregal des aktuellen Jahrtausends wohl nicht mit dem Stolz des Elektronikfroklers zu vereinbaren. Das sind dann die gleichen Leute die erklaeren, ein iPhone haette nichts innovatives - selbst sind sie aber zu diesem "uninnovativen Schritt" nicht in der Lage.
... smile ( Karl-Heinz absolut Recht gebe ) ! Und wenn das Display nicht riesengroß sein muß, tut es auch ein Handydisplay aus einem Siemens S65 (und hierfür finden sich genügend Informationen im Netz). Nur leider ist das dann kein Touch-Screen (allerdings kommt man hier auch mit 4 oder 5 Tasten sehr weit)
@Stefan: Erst lesen, dann mitreden. @Karl Heinz: Das mit den Kanonen und Spatzen sehe ich auch so, und würde mich persönlich auch etwas stören. Mein Vorschlag wären ein paar Status-Leds, aber ansonsten bestehende Interfaces bei der Hausautomation wiederzuverwenden.
ich schrieb: > ...da gab es dieser Tage einen Beitrag auf hackaday.com, schaue doch mal > nach, ob es das ist was du suchst... Zur Vollständigkeit halber :) : http://hackaday.com/2013/04/20/gui-window-manager-on-an-avr-chip/#more-97631
Marwin schrieb: > Gute Idee. Viel Arbeit und am Ende sieht es aus wie in den 80ern. Warum soll das aussehen, wie in den 80-ern? Letzten Endes sind alles nur ein paar bunte Pixel. Und einem Edit-Feld einen 3D-Effekt zu verpassen ist nun wirklich nicht Raketentechnik. Wie sinnvoll es ist, auf einem doch eher kleinen Touch-LCD 25 Fenster teilweise überlappend darzustellen, das überlasse ich der Fantasie des Lesers. > Viel Arbeit In Qt einarbeiten ist auch Arbeit. In der Zeit hat man die 5 Grafik Basisfunktionen, die man tatsächlich braucht, auch schon fertig geschrieben und implementiert die ersten Anzeigeelemente.
Ich glaube Marvin braucht den teuren Flair. Ein iPhone erkennt er sofort, wie ein Lötkolben aussieht muss er aber erstmal googlen ;)
> aber technisch die Rache des C64 zu sein scheint.
:-)
Die würde aber wenigstens funktionieren.
Nicht so wie unsere nagelneue Zeitstempelanlage mit einem Linux-Rechner
und Html-Oberfläche, die von der Bedienung einfach nur ein Graus ist und
alle paar Wochen abschmiert.
Ach Karl Heinz, lies den Eröffnungsbeitrag doch noch mal: Jan Schirrmacher schrieb: > welchen Weg empfehlt ihr zur Implementierung eines Graphikdisplays.. Wer so schreibt, ist - gelinde gesagt - meilenweit entfernt davon, einen uC tatsächlich mit einem bunten TFT versehen zu können. Ich schätze mal, das alles ist nur heiße Luft und sonst nix. Wenn der TO es denn überhaupt verstehen könnte, würde ich ihm zu einem LPC2478 oder seinen neueren Cortex-Pendants raten, dazu einen SDRAM und dann erstmal die Leiterplatte machen, bestücken und anwerfen. Alternativ ein anderer uC plus CPLD+RAM. Und dann alles weitere... Aber das hier zu skizzieren wäre vergeblich, siehe seine Bemerkung über "meinetwegen z.B. mit Qt, Echtzeitanwendung z.B. im AVR". W.S.
Wir verwenden ein noch günstiges Touch-LCD mit LPC1788 mit integriertem LCD-Controller. Demo-Software für Touch, Maus, Bitmap ist dabei und einfach erweiterbar. Zudem zwei Pinleisten auf denen alles rausgeführt ist (UART, SPI, I2C, PWM, CAN etc.): https://www.olimex.com/Products/Modules/LCD/MOD-LCD4.3%27%27
>welchen Weg empfehlt ihr zur Implementierung eines Graphikdisplays, am besten mit Touchscreen für einfache aber schicke graphische Benutzeroberflächen, die man als Bedienfeld auf einen Mikrocontroller setzen kann. Als abgesetzten Display koennt ich auch einen PIC Mediakit von mikroe empfehlen. zB http://www.mikroe.com/ http://www.mikroe.com/mikromedia/pic24ep/ http://www.mikroe.com/mikromedia/dspic33ep/
Du könntest bspw einen kleinen STM32-Controller verwenden, daran ein SPI Grafikdisplay. Als GUI-Framework empfehle ich dir dann ChibiOS/GFX: http://chibios-gfx.com/ http://www.youtube.com/results?search_query=chibios+gfx
Stefan S. schrieb: > Hast du schonmal über nen Raspberry Pi nachgedacht? Jo. Aber da ne graphische Oberfläche laufen zu lassen geht entweder über ein Webinterface im Browser - und da müsste schon HTML5 sein, damit man z.B. mit Dygraph mal einen graphen plotten kann. Oder mit X-Server und ner UNIX-GUI. Eben ziehmlich fett nur um ein parr Buttons und vielleicht ne Graphick laufen zu lassen. > Da hast du nen HDMI ausgang und es leuft nen Linux drauf. > > Denn so wie es sich anhört, hast du wenig Ahnung von Controllern im > allgemeinen. Das ist nicht böse gemeint, aber die Ansteuerung eines > grafischen Displays ist kein Einsteigerprojekt, da es viel Hab ich alles gemacht. Zeilendisplays und graphische. Habe auch ausführliche Erfahrung in der GUI-Programmierung mit allen möglichen IDEs. Bloß dazwischen ist irgendein Loch. Herrgott es kann doch nicht so schwierig sein eine einfache GUI laufen zu lassen und sie mit einem kleinen Echtzeitcontroller zusammenarbeiten zu lassen. Jedes Sch*-handy kann das. Aber da steckt immer eine große Industrie hinter die sich ein Entwicklerheer leisten kann. > Rechenleistung und Knowhow vorraussetzt. Ein Controller der mir da > spontan einfällt ist das STM32 Board. Ich weiß zwar grad nicht wie das > Interface heißt, aber da kannst du dein Bild in den Speicher legen und > der Controller schriebt das automatisch an den Bildschirm raus. > Wird aber auch in C programmiert Also irgendwas fehlt in unserer kleinen Controllerwelt noch...
Stefan S. schrieb: > Moment hab ich da jetzt nen Verständnissfehler drin? Ist die Gui jetzt > auf dem PC oder dem Controller und von wo nach wo gehen nun die Signale > und was genau willst du damit steuern? Das System dient dazu einer typischen Controller-Aufgaben des Heimbereiches (z.B. eine Lüftersteuerung für mein Haus) eine schicke graphische Oberfläche zu verpassen. Eine Lösung wäre es mit dem Handy über Bluetooth sich dranzuverbinden und eine Android-Anwendung zur Steuerung zu programmieren. Fein wäre es die Steuerung einzubauen. Wenn ich sie einbaue, ist es sicher sinnvoll einen leistungsfähigen Controller für das Touch-Display zu haben. Der müsste eine GDI und eine Fensterverwaltung haben, eigentlich irgendein sparsames GUI-Betriebssystem. Bloß das müsste fertig sein und kostengünstig und energiesparend (wie ein Handy).
Embedded Linux auf Router mit RS232 Port. Dann kannst du dir gleich nen Web-Interface machen zum steuern. Wenn du nen WLAN Router nimmst brauchst du auch kein kabel mehr von deinem PC aus. Kann man dann sogar auch vom SCHART-Phone aus benutzen.
Karl Heinz Buchegger schrieb: > So wie ich das verstanden habe - auf dem Controller. > Also eigentlich auf einem eigenen GUI-Controller. Also im Grunde ein > 'graphisches Terminal'. > > > Qt finde ich trotzdem mit Kanonen auf Spatzen. Für eine Hausautomation > braucht man ja nicht wahnsinnig viel an GUI Fähigkeiten. Ein Menüsystem, > mit dem man in Sub-Seiten verzweigen kann, auf dem dann Werte angezeigt > werden und dazu noch je nach Wert eine Einstellungssache (Slider bzw. > Ein/Aus Knopf) sollte es ja für ein Hausautomationssystem fürs erste > tun. Genau. Qt ist ja auch kein Betriebssystem, sondern "nur" eine Graphikbibliothek. > Das ganze mit einem netten Hintergrundbild, welches zb als PNG auf den > Montor geworfen wird, Wert-Ausgabefelder, eine stilisierte LED, noch ein > paar Controls mehr. > Die ganze Sache, die GUI kompliziert macht, mit mehreren Fenstern, die > sich teilweise überlappen, Update-Listen, Message-Verteilung in diverse > Subfenster, routen der 'Mausposition' an den richtigen Thread und dort > ins richtige Subfenster und Capture Behandlung, ist ja so erst mal nicht > notwendig bzw. kann ganz einfach gehalten werden. > > Ich würde mich da nicht auf Qt versteifen, sondern mir selbst was machen > (wenn ich es nicht als fertiges Touch-LCD samt zugehöriger Lib kaufe). > So aufwändig ist das auch wieder nicht, damit das einigermassen schön > aussieht. Mit Rechtecken in verschiedenen Farben, Linien in > verschiedenen Farben und Textausgabe kommt man schon sehr weit um sich > seine eigenen Ausgabecontrols zu machen und damit eine 'Oberfläche' in > Form eines Vollbildseite zu erzeugen. Das klingt reizvoll. Aber die Frage ist, ob es soeine "Mini-GUI" nicht schon irgendwie gibt.
Marwin schrieb: > Gute Idee. Viel Arbeit und am Ende sieht es aus wie in den 80ern. Sehr > sinnvoll, aber nun ist mir klar, warum zum Beispiel meine nagelneue > Gegensprechanlage zwar teuer ist, aber technisch die Rache des C64 zu > sein scheint. Auch hier war der Griff in's Fertigregal des aktuellen > Jahrtausends wohl nicht mit dem Stolz des Elektronikfroklers zu > vereinbaren. Das sind dann die gleichen Leute die erklaeren, ein iPhone > haette nichts innovatives - selbst sind sie aber zu diesem > "uninnovativen Schritt" nicht in der Lage. Gut getroffen. Merkt ihr? Da ist irgegendwie ein Loch zwischen der 80er-jahre selbstgestrickten Menüführung und der Graphischen Oberfläche moderner Smartphones. In diese Loch will ich rein. Man muss doch nicht immer gleich Linux mit dem X-Server laufen haben oder Android oder Windows um eine einfache aber schicke graphische Oberfläche zu haben. Sag ich mal. Bloß wie sonst?
Jan Schirrmacher schrieb: >> Ich würde mich da nicht auf Qt versteifen, sondern mir selbst was machen >> (wenn ich es nicht als fertiges Touch-LCD samt zugehöriger Lib kaufe). >> So aufwändig ist das auch wieder nicht, damit das einigermassen schön >> aussieht. Mit Rechtecken in verschiedenen Farben, Linien in >> verschiedenen Farben und Textausgabe kommt man schon sehr weit um sich >> seine eigenen Ausgabecontrols zu machen und damit eine 'Oberfläche' in >> Form eines Vollbildseite zu erzeugen. > > Das klingt reizvoll. Aber die Frage ist, ob es soeine "Mini-GUI" nicht > schon irgendwie gibt. Na, ja. Was du brauchst sind die Basisfunktionen für * gefülltes Rechteck * Linie * Text ein 'Button' an eine bestimmte Stelle zu malen, ist dann ja erst mal nicht wild
1 | void DrawButtonNormal( Rect position, const char* Text ) |
2 | {
|
3 | Rectangle( position, ButtonBackgroundColor ); |
4 | Line( position.leftBottom, position.leftTop, BottonHighlightColor ); |
5 | Line( position.leftTop, position.rightTop, ButtonHighlightColor ); |
6 | Line( position.rightTop, position.rightBottom, ButtonShadowColor ); |
7 | Line( position.rightBottom, position.leftBottom, ButtonShadowColor ); |
8 | Text( position, CENTER, Text, ButtonTextColor ); |
9 | }
|
10 | |
11 | void DrawButtonPressed( Rect position, const char* Text ) |
12 | {
|
13 | ...
|
14 | }
|
Alle Controls werden in einer Liste gesammelt und bei einem "Mausdruck" wird die Liste durchgeackert, ob der Mausdruck im Rechteck war oder nicht. Je nachdem wird beim Button Objekt vermerkt, dass es gedrückt ist und neu gezeichnet. Ich sage nicht, dass das kein Aufwand ist. Ganz sicher nicht. Aber es ist in der erforderlichen GUI-Komplexitätsstufe nicht sooo wild, wie es sich zunächst anhört. zb, wirst du dir einen Dialog oder Display definieren, das einfach nur eine LIste von Controls ist. Wenn du objektorientiert arbeiten gewohnt bist, dann greift dir hier OOP unter die Arme. Ein Display sieht halt dann in der C++ Beschreibung zb. so aus Display mainScreen; mainScreen.AddControl( Text( 10, 10, "Aussentemperatur" ) ); mainScreen.AddControl( Edit( 50, 10, Edit::ReadOnly ) ); mainScreen.AddControl( Text( 10, 20, "Innentemperatur" ) ); mainScreen.AddControl( Edit( 50, 20, Edit::ReadOnly ) ); etc. Ob dieser 'Schirmaufbau' jetzt erstmal direkt im Code steht, oder ob du das später mal von einem File zur Laufzeit einliest und dir einen schicken Editor dazu bastelst, ist ja für erst ziemlich egal. Ich würde zb auch folgendes machen. Ich würde mir sowas wie 'Variablen' auf GUI Ebene einführen. Edit Felder können zb auf diese 'Variablen' referenzieren. Edit( 50, 10, Edit::ReadOnly, "$OUT_TEMP" ) (mit der Bedeutung: dieses Edit Feld zeigt den Inhalt der Variablen OUT_TEMP an) Der Kommunikationsteil deines Frontendprogrammes horcht dir ganze Zeit zb an der Seriellen und wenn eine Benachrichtigung vom Messrechner kommt, dann isoliert sie den entsprechenden Wert von der Nachricht, und setzt der 'Variablen' in diesem Variablenpool einen neuen Wert. Der Vorgang des Wert-setzens triggert ein Neuzeichnen des gerade angezeigten Displays, woraufhin sich die Controls neu zeichnen und das Edit-Objekt welches die Aussentemperatur anzeigt dann eben den neuen Wert hinmalt. Wie gesagt: Ich sage nicht dass das alles in ein paar Stunden gemacht ist. Das ist es ganz sicher nicht. Aber es ist auch nicht die Raketentechnik, so ein einfaches GUI-System aus dem Boden zu stampfen, wenn man erst mal die Basis-Grafik-Funktionen hat. Für mich persönlich kann ich sagen: macht ja auch Spass.
Hiermit kann man ja auch mal spielen: http://www.ebay.de/itm/NXP-ARM-Cortex-M3-LPC1768-Development-board-2-8-16bit-parall-interface-TFT-LCD-/170959973072?pt=LH_DefaultDomain_0&hash=item27ce022ad0 Für 30€ recht günstig und braucht mit Sicherheit keine 10W. Gibt's auch als SPI-Variante. Die ist dann sicher langsamer. Mich würde mal interessieren wie groß die Unterschiede sind.
Benedikt K. schrieb: > ich schrieb: >> ...da gab es dieser Tage einen Beitrag auf hackaday.com, schaue doch mal >> nach, ob es das ist was du suchst... > > Zur Vollständigkeit halber :) : > http://hackaday.com/2013/04/20/gui-window-manager-on-an-avr-chip/#more-97631 Ja, das sieht doch toll aus. Es zeigt, dass eine einfache GUI (und die ist schon mehr als einfach) auch auf bescheidenen Systemen möglich ist. Es muss doch kein Alphablending und Fensterverschieben mit Inhalt dabei sein. Soetwas meinte ich. Es kann auch kein großer Unterschied sein, dass statt ner Maus der Finger auf einen Bildschirm tippt. Das geht dann zwar nicht mit VGA, aber die Rechnerleistung dahinter ist doch interessant.
> Da ist irgegendwie ein Loch zwischen der 80er-jahre selbstgestrickten > Menüführung und der Graphischen Oberfläche moderner Smartphones. > Wir verwenden ein noch günstiges Touch-LCD mit LPC1788 mit integriertem > LCD-Controller. Demo-Software für Touch, Maus, Bitmap ist dabei und > einfach erweiterbar. Zudem zwei Pinleisten auf denen alles rausgeführt > ist (UART, SPI, I2C, PWM, CAN etc.): > https://www.olimex.com/Products/Modules/LCD/MOD-LCD4.3%27%27 Was heisst hier selbstgestrickt? Notfalls kann man sich die Windows Buttons und Rahmen als Bitmaps speichern und dann auf dem LCD bedarfsgerecht laden (vielleicht nicht grade die von Win8 da ist Markenschutz). Ausserdem gibt es für den LPC1788 emWin kostenfrei: http://www.segger.com/emwin.html
Phantomix Ximotnahp schrieb: > Du könntest bspw einen kleinen STM32-Controller verwenden, daran ein SPI > Grafikdisplay. > > Als GUI-Framework empfehle ich dir dann ChibiOS/GFX: > http://chibios-gfx.com/ > http://www.youtube.com/results?search_query=chibios+gfx Ja verdammt! Sowas meine ich. Besten Dank.
Die beste Möglichkeit (Preis und technischer Aufwand vs. Möglichkeiten und Benutzerfreundlichkeit) für so ein Terminal dürfte heutzutage eine Smartphone-App sein. Die kommuniziert dann mit einem Server in deinem WLAN.
Jan Schirrmacher schrieb: > Man muss doch nicht immer gleich Linux mit dem X-Server laufen haben > oder Android oder Windows um eine einfache aber schicke graphische > Oberfläche zu haben. Sag ich mal. Bloß wie sonst? So wie früher auch: Komplett selbst schreiben (das ist je nach gewünschten Features kein großer Aufwand) Ansonsten mit Hilfe (FTDIs FT800, wenn er jetzt auf den Markt kommt oder bspw. die integrierten TFTs von Displaytech mit Touch+etwas Gfx-Controller 1) oder eine Lib... Von uCFLTK bis hin zum .NET Micro Framework oder Microchips GUI Bibliothek mit Designer 2) oder die von NXPs 3) 1) https://www.displaytech-us.com/integrated-tft-driver-boards 2) http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2680&dDocName=en544475 3) http://www.youtube.com/watch?v=4_67ZqjibHo > Das geht dann zwar nicht mit VGA, aber die Rechnerleistung dahinter ist > doch interessant. Selbst auf dem C64 mit je nach Variante knapp 1 MHz gab es GEOS http://www.zock.com/8-Bit/D_GEOS.HTML
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.